ついに我が家のBUFFALOルーターもEasyMesh対応更新、他社製品ともメッシュを組んでみた

我が家のWi-Fi環境はBUFFALOのWi-Fi6 (4803+1147Mbps)、有線WAN/LAN 10GbpsのWXR-5950AX12です。スペックだけは立派なもののとにかく不安定で突然の再起動などしょっちゅう。夏は外部冷却ファンでずっと風を当ててないとまともに使えないシロモノですが、なかなか同格スペック(特に有線LAN仕様)のものがないので買い換えられずにいます。最近ではせっかくのWAN 10Gbpsを無駄にすることになりますがルーターをYAMAHA RTX1210に戻し、本機はWi-Fiアクセスポイントのみと役割分担させることにしてだいぶマシになりました。熱負荷の問題なのか、ルーター部分に致命的なバグを抱えていたのか不明ですが、かなり再起動の頻度は減った気がします(ログをみても起動時の記録が出ないというハンパ仕様なので気付かないだけかもですが)。

ちなみに現在は消費電力値だけわずかに落ちたWXR-6000AX12が登場しています。

あまりに熱暴走がヒドいのでなんらかの省電力対策をした(だけな)んじゃないかと疑わしいモデルですが、少しはマシになってるんでしょうか。

また我が家は木造2階建てなんですが、こんな立派なアンテナでも全然電波が行き渡らず、(当時同型機のみしか中継機能が使えなかったため)なんとこれを2台も設置しています。それでもトイレや風呂場など微妙なところが多々あります。「3F建て対応」とはなんなのか。

■BUFFFALOのWi-Fi6モデルが全機種EasyMesh対応することになった

そんなこんなで騙し騙し使いつつ、良い代替機種が出たら思い切って買い換えかなぁなどと思っていた折り、BUFFALOから見出しのようなアナウンスがありました。EasyMeshとは業界標準方式でメッシュ(中継ネットワーク)を組む規格です。従来メッシュWi-Fiは各社独自規格でしたがEasyMesh対応を謳う機種同士ならばメーカーが違っても使えるようになるわけです。BUFFALOがWi-Fi6世代のモデルは既発売製品も含めすべてEasyMeshにアップデート対応するぞといいだしたわけです。ということは将来的に中継端末を増やす選択肢が増えたり、徐々に様子を見ながら入替をしていったりと自由度が高まることになります(メッシュモデルはまとめ買いすると高いので)。

WXR-5950AX12のファームウェア更新もしばらく途絶えており、「このまま不安定さの抜本的解決もなされないまま放置かー」などと諦めてましたが、少なくともあと1回は更新が確約されたことになり、もし貯まっていた修正などもあれば一緒に適用されるかも!などと期待は高まります。「よし、じゃぁその更新までは付き合って、それでダメなら買い換えだ!」と決意し、更新を待つことにしました。

■適用してみた

そしてそれは9月末の予定だったのが大幅に延期されて11月末となり、なんのアナウンスもないまま本当に11月末日ギリギリの配信となりました…。長かった。実はその発表を受けてほぼ即座にこちらの中継機も購入済みでした。

もともと同居人の仕事部屋で内蔵Wi-Fiが2.4GHzオンリーだったりWi-Fi6以前のプリンター類などを高速化するためのイーサネットコンバーターとしてTP-Linkの製品を使っていたんですが、こいつも「日に複数回電源を入れ直さないと通信が切れる」とクレームがあり、本機であれば将来的にEasyMeshに組み込めるのでよかろと思って先行して買い換えをしてありました(こちらはすでにEasyMesh対応済み)。TP-Linkよりは安定したもののやっぱりたまにつながらないと言われます。なんか他にもGoogle Nest MiniとかNature RemoとかEchoがつながらなくなるんですよね。なんか大元のアクセスポイント(AX12)がなんらかの理由で再起動した後に再接続できないでつながらないままになる端末がちらほらいる感じ。どいつが原因か不明なんですが仕方ないのでそういう端末を再起動してしのいでいる状態です。

さて、ということでWXR-5950AX12を2台と、WEX-1800AX4EAの3台でEasyMeshによるメッシュネットワークを構築。

・設定は簡単だが使い勝手は微妙…

設定は割と簡単でわかりやすいです。各機種の設定画面でEasyMeshを有効にし、一旦有線LANでつないで放置するだけという感じ(他にもWPSを使う方法もできるぽい)。注意点としてはEasyMeshを有効にした状態ではバンドステアリングなど従来機能の一部が使用不可になる点。例えばAX12の場合、バンドステアリング画面で端末毎に2.4GHz/5GHzのどちらに優先的に接続するか指定したりできたんですが、EasyMeshにするとそれができなくなります。まぁメッシュの考え方はそこら辺を難しく考えなくても最適な電波を使ってくれる、というシロモノなのでわからなくはないですがちょっと悔しい。

設定画面ではこんな感じで接続機器を一覧できます。上の表がコントローラー(メインの親機)とエージェント(メッシュ子機)で、1〜4の番号が振られています。

その下の「デバイス」が個々の端末で、「接続先」の列でどのコントローラー/エージェントにぶらさがっているかを判別できます(画面は途中で見切れてるので全て1ですが)。

EasyMeshの端末一覧画面

またバグなのか仕様なのか、従来のバンドステアリング画面で個別につけられた端末名が適用されず、すべて「Unkown」となります。しかもEashMesh画面側で新規に名前をつけることもできず、Unkownから変えようがない!IPアドレスもほとんどの端末で「不明」となり、どの端末がどのアクセスポイントにつながっているかを知るにはMACアドレスで照合するしかなく事実上役立たずです。バグだと思いたい、アップデートで直ると信じたい!

とりあえずブラウザ側でMACアドレスをもとに端末名を書き換えるJavaScriptを作ってしのいでいます(そのうち別記事で公開するかも)。

・本当に他社製のEashMesh製品を追加できるのか?

中継機のWEX-1800AX4シリーズはAX4なのでアンテナが4本ということですが、2.4GHzと5GHzでそれぞれ2本になるので、5GHzは1202MbpsとAX12の4803Mbpsに比べると抑えめ。その割に9,000円前後するのでやや割高感があります。どうせEasyMesh子機(エージェント)にしか使わないならルーター機能とかいらないんですが、量産効果なのか中継機よりルーターの方がお得ですね。これはほぼ同じ値段で2401Mbps。ちょっと失敗したかも。

ともあれすでに購入してしまった1800AX4はは階下のトイレやお風呂などの「多少遅くても2.4GHzでもいいから確実に届いてほしい場所」用にして、同居人の仕事部屋に確実に速度が出そうなメッシュ子機を導入してみることにしました。こういう柔軟性のある使い方ができるのはメッシュならではです。

同居人が「BUFFALOはなんとなく信用できない」というので、他社製品にすることに。しかし現在、国内市場でみるとBUFFALO以外ではEasyMesh対応機はそれほど多くありません。結局購入したのはこちら。

これまたWEX-1800AX4と変わらぬ値段で5GHzが4802Mbpsと高コスパです。(LinkSysもすべてEasyMesh対応済みというわけではなく、他のモデルでは独自規格採用だったりするのでご注意ください)。

結果としては一応つながりはしたものの、オススメはしづらいという感じです。なぜなら同じEasyMesh規格順序品のはずでも設定フローが統一されておらず、素直に画面指示に従って接続設定が完了しないからです。LynkSysは同製品をペアで使うことを想定しており、子機として設定を進めていくと「親機側で操作しろ」みたいな表示になって先へ進めなくなります。一方BUFFALOは(EasyMesh機能を有効にした上で)有線LANでつないで放置しろ、みたいな感じで噛み合いません。結果としてはBUFFALO側でWPS待機状態にした後、LinkSysもWPSボタンを押したり有線つないだりしているうちにいつのまにか登録されていた、という感じ。LinkSys側を何度もファクトリーリセットしましたし、接続後にLANアドレスを既存LANのセグメントにあわせるのは手動で管理画面に入ってIPアドレスを設定したりDHCPサーバーをOFFにするなど専門的な手順が必要でした(LynkSysの初期IPは192.168.79.1)。メッシュの規格としては統一を目指したものの、設定操作までは及んでない感じで、どちらのマニュアルをみても解決せず手探りで試行錯誤するはめになりました。ちなみに管理画面上で「Other」と表示されているエージェントが本機です。このあたりのデバイス名のやりとりも統一されていない感が伺えます。おそらくなにかあってもどちらからもサポートも受けられない予感。

増設子機としては素直にWSR-3200AX4Sか4800Mbpsにこだわるなら少し奮発してWSR-5400AX6S辺りがいいんじゃないでしょうか。

・で、安定性は?

LinkSysを含めた4台体制になってからまら2,3日ですが今のところ通信断はない気がします。ただ経路は全自動で”最適化”されてしまい、AX12同士が直接つながらないで、1202MbpsのAX4を経由してつながるなどもったいない感じのつながり方をすることがあります。あくまで途切れない(電波が強い)ことを基準に経路選択されているのかわかりませんし、実際速度的なロスがどれくらいあるかも定量的にわかるわけではないですが、気分的には悔しいw。この気持ちの同調できる人は、迂闊に低速端末を参加させない方がいいかも知れません。従来は同規格のメッシュ端末をセットで使うことが普通でしたが、今後色々な性能、メーカーの端末を混在させるようになってくるとこういう問題も気にかかってくるんだな、と思った次第です。

■まとめ

EasyMeshという業界標準(?)規格に準拠したメーカー、モデルを異にする端末でメッシュ環境を組んでみました。もともとバックホールの有線LANは引き回せない環境なので、とにかく電波が弱いなと思うところにメッシュ端末を自由に配置して試行錯誤をしている感じですが、こういう自由度はさすがだなと感じています。できれば「コイツとコイツは常に5GHzで直結」など任意で固定できる部分もあるといいなとは思いますが、それでつながらなくなったら元も子もないのでやはり規格上の「最適化」を信じるしかないんでしょうかね。それらが電波の強さ、バンド、速度などなにをもとに判断されているのか明示してくれると納得感も得られるんじゃないかなと思います。ユーザーがなにを優先したいか重み付けをすることができるとなお良いのですが。

ともあれもう少し様子をみつつ、位置やアンテナ向きをチューニングしていきたいと思います。

BUFFALOの不安定さにカッとなってTP-Linkの10Gbpsスイッチを買ってやった。後悔はしていない。

先週仕事でホテルに連泊した折、またも自宅のBUFFALOの10G/2.5Gbpsスイッチングハブが熱停止していて外から一部機器にアクセスできない事象が発生。冷めると自動復帰するのか、最近はあまり直面することはなかったけど、やはり自然に治るというものでもないんだなとw。下に12cmファンをおいて風を送り、上にも8cmのヒートシンクを置いてたんですけどね。

ネットワークは安定稼働してナンボということでいよいよリプレイスをすることに。

また使っているのはこちらで、10Gbpsが2、2.5Gbpsが4ポートの計6ポートの製品。以前にSynologyのDS1517+とメインのWindowsデスクトップを10Gbps化し、またWi-Fiアクセスポイントとして使っているBUFFALOのルーターも10Gbps。

すでに10Gbpsはポートが足りていませんでした。M1 MaxのMacBook Proも導入しこれからメインで使っていきたいと思っているので、そちらも(今は手頃な10Gbpsアダプタが見付からず未導入ですが)高速化していきたいと思うと、インフラとしてスイッチを強化するのはどのみち必須ということもあり。

■音がうるさいと評判のTP-Link TL-SX1008

購入したののはこちら。BUFFALOのが自分も含めて「不安定」というレビューで溢れているのに対し、こちらは「ファンがうるさい」「交換したった」という書き込みに溢れています。やはり現行の技術では10Gbpsは発熱がものすごいので、不安定になるかメチャクチャ冷やしてうるさくなる、筐体がデカくなる、高くなる、という運命ということでしょう。それでもこちらは「通信が切れる」レベルの不安定さの指摘は見当たらないので、「ファン交換してどうにかなるならマシ」ということでチョイス。

8ポートといっても下に見えるYAMAHAのルーターやスイッチと違い、1列に並んでいるので筐体の横幅は結構デカいです。台に載りきらず90度回転して設置することに。BUFFALOが背面ポートモデルだったので、そこまで来ていたケーブル長の都合も。まぁランプはよく見えるからヨシ。ステータスLEDの点灯ルールはちょっとややこしくて、1Gbpsまでは右側、2.5Gbps/5Gbps/10Gbpsでリンクすると左側が光ります。下のRTX1210とつながっている黄色いケーブルのポート1は1Gbpsなので右側がオレンジになっています。となりのポート2はBUFFALOのルーターと10Gbpsでリンクしているので左側がグリーンに光っているわけです。右と左、LEDの色の組み合わせでやや直観的とは言えないですが、一応見た目でリンク速度が細かく確認できるのは良いです。

問題の音ですが、起動直後は掃除機のような音がするものの、数十秒でスッと落ち着きます。デスクトップPCでBIOS/UEFI画面中はファンが全開になるような感じ。制御プログラムが起動すれば熱相応の回転数に落ち着くと。室温20度台の部屋で1人で使っている分にはそんなに回転数があがることも今のところはなさそう。デスクから(自分の耳)から1m位のところに設置していますが、アイドリング中の音は聞こえます。ただ思ってたよりはマシ。ちょっと高めの音が唸るようにフォォオォオンと微妙な変動をしつつ鳴るので気になるといえば気になりますが、他のサーバー機器などの音も元からしているので、こんなもんかといえばこんなもんと割りきることもできるかなーとか。例えば6/8畳くらいの部屋でも反対側とかに距離を離して設置すればそこまで気にならないんじゃないですかね(あくまでアイドリングレベルの話)。

初期不良チェックだけできたら速攻でファン交換/追加するつもりで既にファンや配線も購入済みなんですが、ちょっと面倒くさいからこの冬はこのままでもいっか、という気になってきています(笑)。しばらく使ってアイドリング以上の回転に上がることがどれくらいあるかで決めたいと思います。

ファン交換する時のためのメモ

(保証はなくなるでしょうから自己責任で)

kakaku.comのレビュ-に改造メモが色々出ています。本製品はサイド片側に4cmファンがついており一般的な3pinコネクタ(電源+回転制御)で置き換え可能なようです。静音ファンで名高いNoctuaにする人が圧倒的に多いみたい。まぁこういうのは誰かの実績に倣う方が無難ですしね。

別の人は、これだと静かになるけど温度としてはあまり下がって無いから不安ということで、メインボード上にある3つのヒートシンクにファンを追加した模様。その方が使ったというのがこちら。サイドファンが2cm厚タイプなのに対し、ヒートシンク用は1cmでいいみたいですね。

X-FAN 40mmファン RDL4010S

X-FAN 40mmファン RDL4010S

618円(01/30 21:23時点)
Amazonの情報を掲載しています

こちらの方が単価は安く3つと配線パーツ買ってもNoctuaより安くあがりそう。この方は電源をどうしたかまでは書いてないですが、サイドファン用のコネクタからとるなら分岐ですかね。あとはケースに穴をあけて外部からとるか、になりますが。まずは分岐でどうにかなるならケースに穴を開けずに済むので試すならそちらからかな。分岐ケーブルはこちらを購入しました。

Groovy FAN用電源ケーブル(二股)5cm GN-PW014F

Groovy FAN用電源ケーブル(二股)5cm GN-PW014F

236円(01/31 05:57時点)
Amazonの情報を掲載しています

サイドファンもあわせて4つ回そうとすると、多段でつなげると3つ必要になりますしケーブルやコネクタも体積も増えるので、自分で配線を繋ぎ直して4股にする方がよさそう。さて、これでしっかり回ってくるのか。

自分はまずはこれでヒートシンクに追加ファンをつけて、ケースファンが静かになれば高いNoctuaは保留でいいかなと思っています。

MonitでWebサーバー死活監視をする

数日前、CentOSサーバーをyum updateした辺りからWebサーバー(Apache)が日に数回に無反応になる現象がでました。プロセスは存在しているもの、ブラウザからアクセスしてもページが表示されず。telnet localhost 80はできるけど、リクエストに応答が返ってこない感じ。systemctl restart httpdすれば治るがまた数時間経つと再発する、という感じ。ログをみてもこれといった情報はつかめず。

そもそもこのサーバーはConoHaのKUSANAGIイメージから構築していて、Apacheの裏にphp7-fpmがいたりしてちょっと構成や設定ファイルの関係が理解しきれていないところがあり、数日粘ったもののお手上げ。

とりあえずsite24x7.comの無料プランで10分おきの死活チェックをしていてサイトが死んでいたらメールやアプリ通知でわかるようにしておき、気づきしだいsshしてhttpd再起動ということをしてましたが、さすがに面倒だし寝ている間に発生すると数時間落ちたままになり、同居している他サイトにも迷惑になるので、とりあえず自動再起動の仕組みを用意することにしました。

■Monitが最初から入ってた

ググったところMonitというオープンソースの死活監視ツールが手軽そうだと思い、インストールしようとしたらKUSANAGIイメージには最初から入っているようでした。/etc/monit.d/下にはKUSANAGIで作成したWordPressの数だけ設定ファイルがありました。しかし現時点で役に立っていないので一旦全部削除(正確には退避)。新規で設定しなおしてみました。

/etc/monitrc

メインの共通設定ファイル。これはとくにいじっていません。監視周期(デフォルト30秒)やログをどこに吐くかなどが指定できます。

/etc/monit.d/alert

メールの設定。/etc/monitrc上で/etc/monit.d/下のファイルをすべて読み込む指定になっているので、別にファイル名はこれでなくても構わないと思います。KUSANAGIイメージではこうなっていましたというだけ。

今回のホストではメールサーバーは運用していないのでgmailを使います。一番上が送信したいアドレス(gmailアドレスでなくてOK)。usernameとpasswordで自分のgmailアカウントを使って認証します。二段階認証を設定している場合、パスワードはアプリパスワードを作成して使います。というかこんなところにGoogleアカウントの本パスワードを書くのも不用心なので必ずそうしましょう。

fromのところはメールの差出人名。これはgmailの場合gmailアドレスに上書きされてしまうようです(ここで指定するアドレスを本人アドレスとしてgmail側に登録すればいけるかも?)

subjectが題名、message以下が本文で$がついたキーワードにその時の状況に応じた情報が入ります。2バイト文字を入れるとちゃんとUTF-8とかで文字化けせずに届くかは試してません。

/etc/monit.d/logging

これもKUSANAGIイメージに最初から入ってました。

とだけ書かれており、ログの保存先を指定しているだけ。

/etc/monit.d/httpd.conf

こちらをゼロから作りました。

 start programとstop programは文字通り、起動、終了に必要なコマンドです。

ポイントは

です。今回のウチの状況だとhttpdプロセスはいきていてtelnetまではできます。なので単にポートを監視するだけでは生きているように見えてしまうので、実際にURLを指定して応答があるところまでチェックしています。ホストは自身なので省略可能。ポートもたぶんなくてもいいかも。指定するページはどこでもいいんでしょうが、PHPスクリプトがあまり含まれていない軽いページが良いでしょう。Apache側でアクセスログが30秒に1回発生してしまうので、通常のコンテンツとしては閲覧されない隠しURLみたいなところだと除外指定がしやすいかも知れません。まぁ自分の場合は次節のようにUser-Agentで除外したので、とりあえずトップページ(/index.html)にしてあります。

その下は10回試してダメなら諦める(unmonitor)ということのようです。なにかもっと致命的な原因で落ちている時に無闇に無限試行しないためだと思われます。現状不都合がないので初期状態で。

monitコマンドの操作

CentOS7の場合、httpd同様、systemctlコマンドで起動や終了ができます。またmonit -tで設定ファイルの文法チェックができ、monit reloadで設定ファイルの再読み込みができます。

メール例

実際に再起動が行われた際にこんなメールが来ていました。

monitからのメール例

1通目で検知して復旧を知らせるまでに30秒ちょっとかかってますね。これは単に30秒間隔設定だからかな?実際には1通目の直後に復帰はしているのかも知れません。

Apacheのログからmonitを除外する

さて、上にも書きましたがリクエストを投げて死活監視をするとApacheのログがとんでもないことになってしまいます。

なので、/etc/httpd/httpd.confのログ設定に除外指定を追加します。log_config_moduleのIfModuleディレクティブの中の、SetEnvIFで画像ファイルを除外している辺りに追加しました。User-Agent(ブラウザ名)もSetEnvIFで指定できますが、それ専用にBrowserMatchというのがあったので使ってみました。実際のUAは「Monit/5.26.0」ですが、将来的にバージョンがかわる可能性もあるので正規表現で「Monit」だけマッチさせるのが望ましいですが、BrowserMatchは最初から部分一致で判定してくれるので第一引数に「Monit」と書くだけで済みます。

識別子にmonitとno_logをつけておきます。no_logがついていればメインのaccess.logからは除外されます。monitは専用ファイルでログを残す時などに使いますが現状はつけただけです。

■まとめ

Apacheが無反応になる根本原因を掴めていないまま泥縄式に対策をしてお恥ずかしい限りですが、とりあえず最低限Webサーバーの稼働は継続できるようになったようです。

送られてくるログをみると、もともとsite24x7(10分毎チェック)が知らせてくるのより頻繁に再起動が行われていることがわかります。つまり放置すれば自動復帰しているような小規模なロックがもっとたくさん起きてたっことでしょうか。やはりきちんと原因究明が必要なようですね…

ConohaVPSを新プランに移行しディスクを拡張する

ConohaでレンタルしているVPSが昨年新プランを追加しました。メモリ1Gのプランのディスク容量が50GBから100GBにアップし、料金はほぼ据え置きというか少し安い上、VPS割引き切符というプリペイドシステムで長期契約時の割引きが受けられるようになりました。とりあえずディスクが倍増するだけでも移行しない手はないのですが、今のVPSをイメージ保存して新プランのVPSに引き継いだ場合、ディスク(パーティション)拡張は自分でやる必要があること、IPアドレスが変わるなどがあり保留にしていました。が、ここにきてディスク残量が心許なくなってきたので、追加ディスクを契約するくらいならばと、新プラン移行を断行しました。

■移行自体は簡単

さすがVPSです。一定時間サーバーが停止していいなら超簡単。サーバーを停止し、イメージ保存。新サーバーを作成する時にそのイメージを読み込むだけです。CentOSベースのKUSANAGIイメージですが、IPアドレスやゲートウェイ、DNSなども新しいものに変更されていました。あとはドメインレコードを新IPアドレスに書き換えるだけです。

よりドメインレコード情報の反映を早めたいならば、数日前からTTLを1分とか短い値にしておくと良いでしょう。そのレコードの有効期間が短くなるので、世界中の端末やルーターに古いアドレスのレコードが残りにくくなります。その後で、新IPに変更し問題なければTTLを長いものに戻しておく、という流れです。

当たり前といえば当たり前なんですが、これだけの作業で新プランへの移行自体は完了。

せっかく新プランにするので VPS割引き切符を最大活用すべく3年分購入。しかし9/30までのキャンペーンで25%割引きと出ているのに、なぜかログインして買おうとすると10%にしかならないのが謎。そこで行ったり来たりしてるので一番時間食いましたw。結局諦めて10%で妥協。
旧サーバーシャットダウン後のイメージ作成がちゃんと測ってないけど10-15分くらいかかったかな?その後で切符を決済して新サーバーをイメージから生成するのはもう少し速かったような。クーポンのことを考えなければ30分くらいで移行できた気がします。

■ディスクを拡張する

さて、これでもらえるディスクは50GBから100GBに倍増しましたが、OSが認識しているパーティションは元のままなので、手動で追加しなければなりません。これは最初のサーバー作成時に選んだOSイメージによってパーティション構成が大きくことなるので、自分とドンピシャの構成の先行例が見つけられませんでした。そもそも追加ディスクを契約した場合はOSから別ドライブとして見えるはずなんですが、今回のパターンだとドライブ数は同じで空き領域が増えている、という感じなんでちょっと違います。2017年頃にCentOS7ベースのKUSANAGIイメージをから作成した(と記憶している)ウチのサーバーはLVM構成でした。fdiskで/dev/vdaをpした様子はこんな感じ。

これは新プラン移行後なので、赤字部分で容量が100GBになっていることがわかります。一方、LVM領域である/dev/vda2はBlocksをみると50GBのままです。つまり、104857600以降に追加された50GB分の空き領域ができているということです。LVMなので、この/dev/vda2上に作られる仮想ブロックPV(の一部)を使って、仮想パーティション/dev/mapper/centos_h16_rootが作られているわけです。dfするとこう見えています。

気持ち的には、/dev/vda2を拡張した上でPVを増やして/dev/mapper/centos_h16_rootに組み込んでやれるとスッキリですが、既存パーティションを迂闊にいじるのは恐いので、/dev/vda3を追加作成して、そこのPVを作ることにします。これならばサーバーを稼働したままでも大丈夫(なはず)。

物理パーティションを作成

再び、fdisk /dev/vdaして、n(=new)コマンドで作成します。ブロックはデフォルトの開始と終了値をリターンで選んでいけば最大容量になるはず。次にt(=type)コマンドで8eのLinux LVMをセット。もういちどp(preview?print?)でこんな感じになってればOK。

w(write)コマンドで書き込んで、rebootで反映されます。

追加したパーティション上にPVを作成

追加50GB領域に作成したパーティション/dev/vda3にPVを作成します。

pvcreateコマンドの前後でpvsをしてPVが増えていることが確認できました。

既存のVolumeGroup(VG)にPVを追加する

vgdisplayコマンドでVG名が「centos_h16」であることと、Free PE/Sizeがほぼ残っていないことを確認後、 「vgextend centos_h16 /dev/vda3」で先ほど作った/dev/vda3上のPVをVG「centos_h16」に追加します。

これでFree PE/Sizeが増えました。空きPEが12810個、容量で50.04GiB分が未アサイン状態ということです。

vgdisplayコマンドで現状を確認します。

物理ストレージとLVM仮想ストレージが多段化されていてとてもややこしいですが、

  • centos_h16という100GBのVolume Groupがあり、50GB(12799ブロック)のFree PEが残っている
  • centos_h16の中に、/dev/centos_h16/swapと/dev/cetnos_h16/rootという2つの論理ボリューム(LV)が存在する。今回拡張したいのは後者。
  • それはそうと/dev/vda2と/dev/vda3という2つの物理ボリューム(PV)がある。

ということがわかります。追加50GBで作ったのが/dev/vda3ですがすでにVG「centos_h16」に追加済みなので、物理レイヤーのことはもう忘れてOKです。残るは、VG内のフリーの50GBをLV「/dev/centos_h16/root」に割り当ててやり、同パーティションを領域一杯に広げてやるという2ステップです。

特定のLVに空きPEを割り当てる

Free PEをありったけ指定のLVにアサインするのはこんな感じ。

念のためもう一度vgdisplayしてみると、Free PEが0/0になっています。

パーティションを拡張する

いよいよ大詰め。/dev/centos_h16/rootのファイルシステムを確認します。XFSとext3/4では拡張に使うコマンドが違うからです。

XFSでした(ここの/dev/mapper/centos_h16-rootは/dev/centos_h16/rootと同じと考えてOKです)。なので、拡張にはxfs_growfsコマンドを使えばよさそう(ext3/4ならresizefsかな?)。-Dオプションでサイズを指定しない場合は可能な最大サイズを使い切ってくれます。

何分かかかるかと思いきや一瞬で終わりました。dfコマンドでみると使用率が79%だったのが38%に激減しています。特に指示は出てないですが気分的に再起動しておきました。

■まとめ

何年かぶりにLVMをいじってドキドキしましたが、まぁ最悪イメージが残っているので失敗したらVPSをもうひとつ作り直せばいいやってことで思い切ることができました。VPSはこういう時ほんと楽ですね。

とりあえず追加料金不要でストレージが倍になりました。それどころかプリペイドシステムの 「VPS割引き切符 」で安くなったくらいです。一挙に3年分前払いしてしまったので、このままあと3年はトラブルなく稼働してほしいものです。

VPNより安全高速?ポートを開放せずCloudflare Accessでプライベートサーバーにアクセス

■ゼロトラストセキュリティとは?

テレワークブームでオフィスのPCやNASへのリモートアクセスニーズが高まっている今日この頃、皆さんいかがお過ごしでしょうか。リモートワークといえばVPNが主流だと思いますが、昨今「ゼロトラストセキュリティ」とか「ゼロトラストネットワーク」という言葉が流行りだしているのを耳にされたことはありますでしょうか?VPNはファイアウォールの境界で認証をして、一旦くぐり抜けてしまえばあとは社内ネットワークに直接つないでいるかのようにLAN内のリソースにアクセスできる、というものです。一方ゼロトラスト(信頼)は社内ネットワークの端末や利用者も基本的に信用しないぞ、って考え方に基づいたセキュリティポリシーです。実際、情報漏洩事件の多くは社内LANへのアクセスが可能な人の犯行が最も多いんだとか。同じ社内につながっていても、各ファイルやWebアプリケーション(例えば経費申請とか人事管理とか)へのアクセス権は人それぞれで、結局そこでまた認証があったりして二度手間ですしね。またVPNがあることで、利用者に要求される手間やリテラシーやトラブルも増えますし、そもそもクラウドサービスとか使った社内システムだと社内LANにあるわけでもないし、とか、VPNは色々と時代にそぐわなくなってきているといえるのかも知れません。 ゼロトラストセキュリティの厳密な定義はググっていただくとして、今回はその考え方に基づいた実装の1つであるCloudflare Accessの紹介をしてみたいと思います。ゼロトラストはあくまで考え方なので、他社製品だと実装方法からして異なる場合もあるかと思うのでご了承ください。 利用者目線での価値としては、

  • 社内リソースにアクセスするたびにVPN接続操作や使用後の切断操作がいらない
  • 全てのデータを暗号化する負荷がない分、軽い、速い
  • 会社ネットワークのファイアウォールに内向きのポート開放をしなくて良い
  • 個人的な追加ポイントとして、
    • 固定IPアドレスが1つでも複数のWebサービスを(80番ポートで)公開できる
    • v6プラスのような使えるポートが制限されているサービスでも(80番ポートで)サーバー公開できる

などかなと思います。特に2番目はルーターや自分の端末の性能がボトルネックになりがちで、せっかく速い回線を使っていても頭打ちになったりします。そもそも昨今の通信はHTTPS/TLSなどアプリケーションレベルで暗号化されていることがほとんどなので、それをさらにVPNの入口と出口で暗号化するのも無駄といえば無駄。雑な設定でZoomなどのクラウドサービスを利用するにもVPNを通って一旦社内LANを経由とかしてたらヒドいものです。

■Cloudflare Access

サービスを知ったきっかけはInternet Watchのこちらの記事です。

CloudflareといえばCDNの大手ですね。普通の人は直接意識することはないかもですが、世界中のコンテンツを世界中でキャッシュしていて、地理的に遠いサーバーの情報でも近所の複製サーバーからデータをもってきてあたかも近くのサーバーにアクセスしているかのように快適にしてくれるものです。動画配信サービスやゲームソフトのダウンロードなどが快適に利用できる下支えをしてくれるCDNの業者のひとつ。Akamaiほど老舗ではないけど、個人サーバーでも比較的手軽に利用できる無料サービスなどが充実している(ここポイント!)会社です。あと個人レベルだとオープンなDNSサービスとしてGoogleの8.8.8.8と並んで有名な1.1.1.1を無償提供しているのがCloudflareですね。

さて、このローエンド向けの無料サービスが得意な Cloudflare が提供しているゼロトラストセキュリティサービスが Cloudflare Accessを含むCloudflare Teamsとなります。50ユーザまで使える無料プランが提供されていて気軽に試して見ることができます。

以下、ある程度サーバ-構築をしたことある人向けですが設定手順に基づいて動作原理がイメージできるように解説していきたいと思います。前提として、いくつかのWebアプリケーションを社内または自宅内LANで運用しており、外からのアクセスにVPNまたはポート開放で賄っているとします。これをVPNを使わず、ポートに穴も開けず、より手軽に使えるようにできるというのが主旨です。ぶっちゃけゼロトラストセキュリティ云々は二の次です(笑)。

ポイントはDNSを委譲するところ

Cloudflareにアカウントを作り、最初にする作業は自ドメインのネームサーバー管理を Cloudflareに移すことです。 Cloudflareがドメインレコードを自由に書き換える権限を持つことで、様々なサービスを実現しているのです。

例えば、hogehoge.comという自ドメインがあったとして、こんなドメインレコードが登録してあるとします。

hogehoge.com123.123.123.1
mail.hogehoge.com123.123.123.2
private.hogehoge.com123.123.123.3

ネームサーバーをCloudflareに移すことで、Cloudflareはこれを自由に書き換えたり、新しいホスト名を追加できるようになります。ただし、Cloudflareのサービスをバイパスしたいレコードについては個別にロック指定しておくことができますので、メールサーバーは触らないで欲しい、みたいなことは可能です。こちらがCloudflare TeamsのDNS管理画面です。

「プロキシステータス」の列で「DNSのみ」というのが勝手にプロキシ(後述)を割り込ませないでねという意味になります。

逆に「プロキシ済み」となってるサーバーでアクセス制限の設定をすると、IPアドレスが別のものに差し換えられます。つまり利用者がホスト名でアクセスをしようとすると、一旦Cloudflareが用意するプロキシサーバーにつながります。そこに然るべき認証画面を割り込ませることでアクセス制限を実現するわけです。認証はホスト単位ではなく、パス毎に設定できます。例えば、「private.hogehoge.com/calendar/」を指定してやると、/calendar以下へのアクセスだけが対象になりますが、private/hogehoge.com/index.htmlなどは素通しのままです。1つのサーバーの異なったディレクトリに異なったWebサービスを動かしている場合、それぞれに別個の認証ポリシーを割り当てることができます。

実際にアクセス制限をしたページを開こうとすると、こんな認証画面が立ち塞がります。

ロゴや配色はカスタマイズ済み

認証方法も色々選べます。標準で一番簡単なのはワンタイムパスコードをメールに送る方式(Get a login code emailed to youのとこ)。メールアドレスを入れて「Send me a code」すると1回使い切りの数字列がメールで届きます。そのメールアドレスを受信できる人ならそれを読み取って次の画面に貼り付けて送信すれば認証完了です。これだけだと自分のメアドをもっている人なら誰でも入れてしまうので、設定画面で制限するメールアドレスやドメインを指定しておきます。例えばhogehoge.comドメインで制限すれば、なんちゃら@hogehoge.comのメアドをもつ人にしかコードが届かないということになります。ただこれだと毎回メールを開く必要があったり、下手するとVPNより面倒くさいですね。

なので私はMicrosoft 365の法人アカウントを作っているので、Azure ADが利用可能でしたので、それを設定しました。これで(企業や学校向け)Microsoftアカウントでログインすることができます。そちらで二要素認証などをしていれば当然ここでも要求されます。認証方法は他にもGoogle、Facebook、GitHub、G-Suiteなど名だたるSSO(シングルサインオン)システムが並んでいます。GoogleやFacebookが個人アカウントで使うかは不明。G-Suiteが別にあるからできるのかな?

ここまで元からあるサーバーにはなにも手を加えてないのに、サクっとMicrosoftの強固な認証システムを実装できてしまうというのがスゴいところです。ログインの有効時間も設定できるので、一度ログインしておけば一定時間はこの認証をバイパスして、あたかもVPNに入った状態かのようにサービスを利用することができます。またアクセス元のIPアドレスや国で制限することも可能です。Apacheのディレクティブでしていたような制限もGUIで簡単にできちゃうわけですね。

内向きポートを開放せずに実現する

さて、既存ホスト名でアクセスしようとした場合に、Cloudflareが書き換えたプロキシサーバーに転送され、そこで認証手続きを代行してくれる、ということがわかりました。社内のあらゆるシステムに共通の認証基盤を簡単に実装できるという点でも素晴らしいです。

しかし鋭い方ならお気づきでしょう。元のIPアドレスを直接叩かれた場合のアクセスについてはなにも防御されていない、と!Cloudflare側で認証してくれるから二度手間になると、元のサーバーの認証を切ってしまったりしたらエラいことになります。元サーバーへは常にCloudflareのプロキシーサーバーのIPアドレスからのアクセスだけを受け付けるようにアクセス制限をかけるのも手かも知れませんが、IPアドレスだけを条件にするのは危険でしょう。そもそもCloudflareのプロキシサーバーのIPアドレスブロックについても記述は見当たりませんでした。サーバー証明書などの類も同様です。しっかり探せばあるかも知れませんが。

2022.11.24追記: IPアドレスブロックはたぶんこれですね。

で、これには別の対処方法があります。Impressの記事でも紹介されているcloudflaredというトンネリングプログラムを使う方法です。Linux、Windows、Macなどなんらかのローカルネット内部で可動するPCで起動させておく必要がありますが、社内サーバーの出力情報をCloudflareのプロキシーサーバーに中継してくれます。Cloudfrareのプロキシーがこちらにデータを取りに来る場合、待ち受け(IN方向)ポートを開放してやる必要がありますが、cloudflaredならそれが不要になります。社内に連絡員を常駐させるようなものですが、門は閉じておくことができるというわけです。

この方式を使う場合、Cloudflare上のDNSレコードに仮想ホストのレコードが割り当てられます。例えば、社内にプライベートIPでアクセスできるカレンダーシステム(192.168.0.200/calendar)をvirtual.hogehoge.com/calendarみたいなURLで公開できます。virtualというホスト名のホストマシンは実在せず、常にcloudflaredが中継するデータを(認証を通した上で)見せる専用のホスト名となり、CloudflareがDNS編集権を握っていることで、cloudflared側からの設定ひとつで簡単に追加することができるのです。

■待ち受けポートがいらないことの副次効果がスゴい!

さて、長々とCloudflare Accessの概要を書いてきましたが、ここからは個人的な副次効果についてです。先に書いてしまうと、

  • グローバルアドレスが1つかないような環境でも複数のWebサービスをポート番号指定なしで公開できる
  • v6プラスのような使用ポートに制限がある環境でも任意のポートで公開できる

というところです。

ウェルノウンポートを使う難しさ

ウェルノウン(well known)ポートとは、主要サービスがデフォルトとするポートです。例えばhttpなら80番、httpsなら443番などと決まっています。本来、URLでは「http://hogehoge.com:80」とか「https://hogehoge.com:443」などとコロンで区切ってポート番号を指定することでウェルノウンポート以外を使うことは可能です。省略した場合にウェルノウンポートが使われるのです。しかし世の中ポート番号の指定などという事例は認知度が低く使ってもらいづらかったり、実際問題としてスマホのキーボードだと記号や数字の切り替えが面倒だったりします。

例えば、社内にプライベートIPでアクセスできるカレンダーシステム(192.168.0.200/calendar)と経費精算システム(192.168.0.201/keihi)があったとします(別々のホストで運用)。外向けのIPアドレスが1つしかない場合、80番ポートも1つしかないので、片方をhogehoge.com:8080/keihiなどとすることになります(若い番号は他のサービスでウェルノウンポートに指定されてることが多いので、ケタが多くなりがち)。これを回避してすべてを80番ポートでアクセスさせたいと思えば、リバースプロキシサーバーを建てて、内部で振り分けるなどの工夫が必要になります。Cloudflare Accessはまさにこれを外注できるという見方もできるでしょう。別々のホスト名を割り当てることも簡単です。オープンソースのApacheなどで動いてVirtualHostなどを簡単にいじれるものなら1台で済ますこともできますが、例えば市販のネットワークカメラを複数公開したいなんて時はそれもできません。外部のプロキシならこれも簡単です。

次にフレッツ系の光回線とかで最近主流になっているIPv6 over IPoEをについて考えてみてみます。IPoEでIPv6通信をできるようにし、なおかつMAP-EやDS-LiteなどでIPv4 over IPv6が利用可能になると、従来のPPPoEを使ったIPv4よりも幾分高速になります(IPoEも利用者が増えてきて以前ほどPPPoEと比べて劇的に速いということもなくなってきてはいるようですね)。我が家のプロバイダはMAP-E方式のv6プラスです。この方式は自宅側のIPv4に変わってプロバイダ側でIPv4通信を受け取るIPアドレスが共有されている為、65536個あるポートの全てを自由に使うことができず、4096~65536番のうちの割り当てられた240個しか利用できません。ウェルノウンポートを含む4098番以下は公平に誰も利用できません。なので、どうしてもウェルノウポートを使いたい場合、通常、

  • 設備側でも専有の固定IPv4アドレスが付与されるプランを使用する(高い)
  • 別にPPPoEで固定IPv4アドレスが付与されるプランを使用する(遅い)

のどちらかを選ぶことになります。ウチが使っているプロバイダでは前者は+3,000円ほど。後者は1,000前後で契約可能なので、我が家は速度を妥協して後者にしています。ちなみに後者の場合、通常の内から外へのインターネット利用にはIPoEを使い、外向けサーバーの通信はPPPoE経由というより振り分けができるYAMAHAなど業務用の機能を備えたルーターを使ったりする必要もでてきます。

Cloudflare Accessを使えば、80/443番ポートのサービスがいくつでも

私はこのブログも含め一般向けのWebサイトはConoHaのレンタルサーバーに置いています。自宅のIPアドレスではあくまで自分や身の回り向けの非公開サービスを運用するのみです。それでもできれば80/443番ポートにしてURLをシンプルにしたいし、せっかくあるIPoE側に速いスピードで使えるようにしたい。またごく簡単な自作サービスにBASIC認証だけでない強固なセキュリティも装備したい。そんな事情にこのCloudflare Accessがカチっとハマった気がします。あらためてまとめると、

  • 自宅のファイアウォールはIN方向のポート開放が必要ない
  • 異なるホストでもすべて80/443番ポートで公開できる
  • IPoE経由でPPPoEより高速な経路を使って公開できる
  • SSO、IP制限など高度な認証システムを付与できる
  • LAN内アクセスとWAN経由でブックマークを共通化できる
  • 無料

という感じ。とはいえ3つ目についてはまだ評価段階なのでなんとも。PPPoEを経由しなくていい代わりにCloudflareのプロクシサーバー(地理的位置は不明)を経由するので差し引きで本当に速くなるかは微妙。それでも時間帯で数Mbpsに落ちることもあるPPPoEよりはマシのはず、という現時点での想定です。またCloudflare側は当然IPv6に対応しているので、自宅からのトンネルがIPv4 over IPv6ではなく直接IPv6同士で通信したらさらに効率的なんだろうと思うんですが実際にどうなっているかは不明。cloudflaredのステータスだと相手先サーバーとしてはIPv4アドレスが見えているのでIPv6かどうかはなんとも。OSの優先設定やルーターのIPv6の外向きフィルターでブロックしていないかとか、cloudflaredにIPv6経路を強制するオプションがないかなど追々検証/調査していく予定です。とりあえず現状で使っている限りでは、「海外サーバー経由してんな」ってレベルの遅延は全く感じられません。様子見てよさげなら順次Cloudflare経由にして、PPPoEサービスは解約できたら1,000円/月浮かせられるなという感じ。

ブックマークの共通化についても補足します。例えばネットワークカメラにLAN内からアクセスするのに192.168.0.200だったとします(ポートは80から変更不可)。これを外からも見られるようポート開放するとすると、ルーターのIPマスカレード機能でグローバルIPアドレス:8080を192.168.0.200:80に変換します。ポート番号が違うので、仮に内向きDNSでprivate.hogehoge.comをいうホストを192.168.0.200に振り向けたとしても、LAN内では80番ポート、外からは8080番ポートを指定することになり、ノートPCやスマホなど内でも外でも使う端末ではそれぞれをブックマークして使い分けることになります。しかしすべてCloudflareのプロキシを使ってポート番号を共通化することで、この問題も解決します。内向きDNSでローカルIPを指すレコードを作っておけば、内部アクセスなのに一旦Cloudflareを回ってくる、といった経路になることもありません。

80/443番ポート以外は?

とりあえずWebサービスは使えそうだということがわかりました。では他のSSH(22番)とかRDP、VNC、SMBといったプロトコロルはどうなんでしょう?Internet Watchの記事によるとRDPはできるっぽいけど、接続元の側にもcloudflaredを入れて接続先LAN上のローカルIPアドレスも指定してやる必要がありそう。接続元も固定のネットワーク(例えば実家とか)ならRaspberry Piとかにゲートウェイ運用とかさせればヨサゲですが、ノートPCをモバイルルーターや公衆Wi-Fiで使うなんてことを考えるとやはりPC上にcloudflaredを稼働させて、localhostに向けてRDPする、みたいな形になりそう。それだとVPNの方が簡単じゃね?って感じになるような気もします。コロナ禍ではあまりノマドや帰省をしないので、RDPやVNCでリモートデスクトップ接続をする機会自体がほぼないのでこちらは保留。どちらかというとSMB(ファイル共有)くらいはしたいかもですが、これはローカルのファイル共有とポートがかぶるのでちょっとややこしいようです。たぶん次に試すとしたらSSHかなと。今は1つだけ外から入れるホストにSSHで入って、そこを踏み台に別PCにSSHするという感じ。まぁそれであんまり困ってないですが、個別ホスト名で直接入れるとやはり内外同じ感覚で使えるので便利かなと。ただまぁSSHは侵入を許すと危険なので、もともとウェルノウンポートで運用しないのが鉄則みたいなところもありますし、どうでしょうね。

そもそもWebアクセス時にWeb認証画面が出るのは手間として違和感ないですが、RDPやSSHする時都度認証するとしたらどうなんだろ。Web認証の必要な公衆Wi-Fiみたいな煩わしさはないんでしょうかね?

■まとめ

背景説明もしたのでかなり長くなってしまいましたが、とりあえずクローズドなWebアプリケーションをより使いやすく安全にすることが、アプリケーションに手を加えることなく実現できるので非常に有用なサービスだなと感じています。まだまだ機能がたくさんあり、もっと便利な使い方もきっとあるんだろうなと思いますが、何分公式も解説記事も日本語によるものがあまりなくて、少しずつ試していこうかなというところです。また続報などあればお知らせしていきたいと思います。オススメの使い方などあれば是非教えていただければ幸いです。