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

Pocket

数日前、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を新プランに移行しディスクを拡張する

Pocket

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でプライベートサーバーにアクセス

Pocket

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

テレワークブームでオフィスの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アドレスブロックについても記述は見当たりませんでした。サーバー証明書などの類も同様です。しっかり探せばあるかも知れませんが。

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

GutenbergでWPアソシエイトポストR2の挿入ボタンが反応しない問題

Pocket

ふとWordPressでMarkdown記法が使いたいなと思い調べると、なんとWordPress 5.0から採用されたブロックエディタGutenbergなら標準で使えるとのこと。いままで何度か触りつつもしっくり来なくてClassic Editorに戻ってましたが、改めて真面目に取り組んでみるかと試用開始。

しかしいきなり問題にぶち当たる。Amazonや楽天の商品リンクを貼り付けるWPアソシエイトポストR2を使おうとするも、商品選択後の「挿入」ボタンが効かない。クリックしてもなにも反応がない。バージョンは執筆時点最新の4.1。

このボタンを押してもなにも無反応

WPアソシエイトポストR2 自体は専用ブロックまで提供しているくらいでGutenbergにはバッチリ対応済み。さすがにこれだけメジャーなプラグインがバグ持ちであるとは考えづらく、ウチの環境の問題だろうと。なにかのプラグインとバッティングしているのかな。

開発者ツールでJavaScriptのコンソールをみてみると、クリックした瞬間にこんな感じのエラーを吐いていました。

Uncaught ReferenceError: wpActiveEditor is not defined quicktags.min.js?ver=5.8.1:2
挿入ボタンを押した時のエラー

とのこと。quicktags.min.jsはググるとWordPress標準の機能クイックタグに関するスクリプトっぽい。wpActiveEditorというオブジェクトがないぞという感じのエラー。名前からして使ってるエディターがGutenbergかClassicかを取得するメソッドかプロパティでしょうか?ここで特定のプラグインを示す名前が挙がってくれると簡単だったんですが…

■なんとClassic Editorプラグインが原因だった!

WordPress 5.0以降でClassic Editorを継続して使用する時に使うそのまんまClassic Editorというプラグインを外したら正常に商品リンクが挿入できるようになりました。なんと、WPアソシエイトポストR2は新旧両エディターに対応しているものの、旧エディターと使い分けようとすると新エディターで不具合が起きる、ということでしょうか。ばっさり旧エディターを無効化して使うならば新エディターでバッチリ動くぞと。

うーむ、ざっと見た限りClassic Editorで作成した過去記事はClassic Editorプラグインが無効でも編集できるっぽいし、これから新規でClassic Editorを使った記事作成をしなければ問題なさげかな?しばらくこれで頑張ってGutenberg移行をしてみようかな。

docomo回線でIPv6シングルスタック接続を先行体験する

Pocket



IPv6に対応したと言われて数年経つドコモ回線ですが、「接続先設備によってはIPv6アドレスが割り当てられない場合があります。」という一文があり、spモードでIPv6が振ってくるのを見たことがない神奈川県民です。IIJの中の人の調べによると、都内でひたすら機内モードを入り切りしているとつながることもあるらしいですが、逆にいえば一律のサービスとして保証はしておらず、設備更新したとこから順次提供という雰囲気で安定して使う方法はなさげ。世の中5Gの時代だというのに嘆かわしい。現状追加料金なしでIPv6を使えるのはソフトバンクかIIJmioなど一部のMVNOという感じぽいですね。

そんなドコモですが、一足飛びに2022年春からIPv6シングルスタックを導入する予定があるようです(以下IPv6SS)。IPv4/v6のデュアルスタックがまともに整備されないままv6オンリーになるということ。もちろんそれまでに世の中全てのサーバーがv4を廃止できるわけはないので、局設備側でIPv4-v6変換をして既存v4ネットワークとの接続も確保してくれるようです。光回線でIPv6 IPoEを使ってIPv4 over IPv6を提供しているようなことをモバイル回線でやるわけですね。そして各種サービス事業者向けに不具合がないか検証する用の先行確認用のAPNが2021年12月3日まで提供されています。

自鯖が正しく見えるかなどの検証も兼ねてちょっくら試してみました。iOSならば上記ページでQRコードを読み取ってプロファイルをインストールするだけ。モバイルルーターのSH-52Aは対応機種に載ってませんがAndroid用のAPN情報を自分で設定したら使えました。配下にWi-FiでつないだPCもきちんとIPv6になりました。

  • 当環境のご利用にあたっては、パケット通信料がかかります。
  • 当環境への接続により発生した通信料は、お客様ご負担となります。

などと書かれていますが、ギガホなどの対象外だよとかは明記されてないので大丈夫(対象内)じゃないでしょうか(ドキドキ)。

試した限りではIPv4通信も特に問題なくできている感じでした。自前サーバーのIPv6アドレスともばっちり通信可能でした。

一応PC(Wi-Fi6接続)から速度テストもしてみましたが、IPoEのようにIPv6経由だから速いという優位性はなさそう。下記の写真だけみるとspモードの方が速そうですが、計測する度にバラ付きが大きいのでなんともですが。ほぼ同じと言って良いと思います。IPv4サーバーへの速度目的で常用する価値はないでしょう。むしろ変換サーバーを経由しているのに遅くなっていないだけでも立派だと考えるべきでしょう。IPv6サーバーで速度を計測できるところが見付からなかったので未検証です。

spモード

IPv6SS

spモード

IPv6SS

一方、v6プラスなどのIPv4の開放可能ポートが制限される環境で、モバイルから自宅サーバーへのアクセスを確保したい人は今すぐ常用したいレベル。でも試験目的で開放されているAPNなので、常用するのは憚られますね。2022年春にどういう形で提供開始されるのかわからないですが(ある日全ユーザがIPv6SSになるのか、新機種や新規契約者から段階的にデフォルトAPNが置き換わっていくのかなど)、楽しみでなりません。