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

MagSafe iPhoneでもハンドストラップを使いたい

iPhone13シリーズが発売されました。今年もPro Maxにしました。マクロとかシネマティック動画とか楽しいです。

さて、前モデルのiPhone12シリーズより導入されたMagSafeですが、昨年はいまひとつ活用しきれていませんでした。

MagSafe充電器

MagSafe充電器

Amazonの情報を掲載しています

なぜなら私はiPhoen Pro Maxような大型スマホでは背面にハンドストラップをつける主義だからです。片手で保持しても危なげがないように、また寝転がって使う時にうっかり顔面に落下させないようにこうした商品は必要です。従来はケースに一体型になったものを使っていいましたが、最近あまり選択肢がなく、最近のiPhone 12 Pro MaxやGalaxy Note 10+では後付けのこういうのをハードケースに貼り付けて使っていました(TPUなど柔らかにケースだと貼り付きません)。ちなみにバンカーリングなどの金属リングは手に馴染みが悪くQi充電とも相性が悪いので除外です。

MOMO STICKは収納すると比較的薄型でGlaxy Note 10+ではかろうじてQi充電もできています。iPhoneはダメ。その後で発売になったgoBeltは使用時の感触はイマイチですが収納時はさらに薄くなるというので買ってみました。両面テープが剥がれやすくケースの材質をかえたり両面テープを自分で貼り直したりしましたがここ半年くらいは普通に使えていました。個人的にはあまり活用してませんでしたが、横向きでスタンドになるというのもポイントです。タダこちらもケースをつけてしまうとiPhoneのQi/MagSafe充電はできたりできなかったりという状態で、寝る前に充電器にセットしておいたのに朝全然充電できてなかった、ということもしばし。(どちらもケース無しであれば公称としてはQi充電対応っぽいです)

今年の13 Pro Maxは更に重量も増していてやはりストラップベルト無しでは厳しいだろうなぁと思いつつケースを物色。去年かもっと前から気になっていたDeff(ディーフ)の13シリーズ用が本体発売前から予約受け付けていたので買ってみました。

ケブラー素材でかなり薄型ながら耐摩耗性などはよさそう。衝撃吸収はあまり期待できないでしょうが、裸に近いスタイリングは久々で心地良いです。これだけならMagSafe充電器もピタッと貼り付くしもちろん充電もちゃんとできます。

そして次に買ったのがこちらのMagSafeのマグネットを利用してくっつくストラップベルト。

充電器に載せる時にこれを外してやればよくね?というワケです。カード収納とかいらないのでもうちょっとシンプルに薄く仕上げてほしかった気はしますが、ベルトの使い心地は上記2つよりもしっくりきます。うっかりカード挿入口に指が入ってしまうのがイマイチ。

で、Deffといえどもやはりケースをつけてしまうと磁力を遮断してしまい、ひっつき具合がいまいちでした。そこで引っ張り出してきたのが去年アリエクで買っておいたこちらの商品。ケースの内側に貼り付けることが、ケースをMafSafe対応にするというかまぁ磁力を増強するものです。今日本で買うとしたらコレとかでしょうか。

去年使っていたケースでは厚くて力不足でしたが、Deffならばいい感じです。これを内側に仕込んだ状態ならば上記ベルトもバチコーンと吸いつき、意図をもって力を込めない限り外れないくらいです。

充電台の載せるたびにつけ外しするのはやや手間ですが、これで今年こそMagSafeを活用した充電ライフを送れそうです。早速充電台を物色します。クルマ用も欲しいところ。

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年はトラブルなく稼働してほしいものです。

飲みたい時に瞬時に緑茶/麦茶ができるワン・ツー・キューブ

WBSでみて知りました。お茶をフリーズドライ製法でキューブ状に固め、水に溶かすだけで瞬時にお茶やコーヒーができるという製品。

No Title

No Description

緑茶はまぁ粉末製品もあったし、コーヒーもインスタントがありましたが、麦茶ってなかった気がします。夏は麦茶が飲みたくてティーバッグのものを買うんですが、お湯だしは面倒だし水出しは時間がかかります。さぁご飯食べよって時に「あ、麦茶切れてるわ」となると諦めて水か他の印象にいくしかありませんでした。また、ポットにティーバッグを入れておくと出過ぎて渋くなるので、忘れずにティーバッグを取り出す必要などもありました。

しかしこれならばその場で水にポンと投入するだけで麦茶ができます。未来ですね!

自分はコーヒーはそんなに飲まないので、麦茶と緑茶を買って試して見ました。

実物はこんな感じ。言われないとまさかお茶だとは思わないですね。200ml~400mlに1つが推奨のようなので、1Lのポットにちょっと水を少なめにして2つ入れています。ポットを軽く揺すってやると1分も経たずに色が均一になり”お茶”が完成します。お味はというと、うーん、飛び上がるほど美味しくもないですが、水出しの麦茶とそうかわらない気がします。個人的にはアリ。緑茶はペットのお茶より風味を感じる一方で、甘さや旨味のようなものはほぼ感じないかな。どちらもコールドで飲むならまぁ許容範囲。単価も高いので作り忘れの時の緊急用くらいがいいかもですね。特に麦茶は1杯分だけさっと入れる、という方法が他にあまりないので、夏場など飲む期間は常備しておきたい。あと緑茶とコーヒーは牛乳で作ってラテにすることもできる模様。

今はまだ店頭販売はしておらずAmazonでの数量限定販売のみっぽいです。

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