キャプティブポータルとVPNの膠着：どちらが先に動くか

ホテルのポータルは、どんな通信も通す前にブラウザを要求する。あなたのVPNは、トンネルが上がる前の通信を拒否する。双方が相手を待っており、どちらも設定どおりに動いている。この膠着を破る順序は二つだけで、すき間が開いている間に何を露出するかが違う。ブラウザが読み込まれる設定を切り替えるのではなく、どちらかを意図的に選ぶべきだ。

二つの順序、うまくいくのは一方

ネットワークが先にあなたを許可し、トンネルが後から来るか、ポータル用に狭い例外を開いてあとでブロックを戻すか。どちらも正当だ。正当でないのは、ブロックを無効にしたまま戻すのを忘れることだ。

二つの順序は、どの状況でも同じように良いわけではない。許可手順が義務づけられた管理端末には一つの答えがあり、ホテルのWi-Fiにつないだ個人のノートPCには別の答えがある。比べるべきは、それぞれの選択が何を手放すかだ。

まず、自分のクライアントと端末ポリシーが実際にどちらを支えているかを知ることから始める。

選択肢A：ネットワークを許可してから、トンネルを接続する

想定されるネットワーク名を確認し、OSのサインイン要求か、クライアントが対応するキャプティブポータルの流れを使う。iPhoneとiPadでは、サインインシートを閉じると関連付けが切れる場合と、インターネットがないという警告付きで維持される場合があり、これらは異なる出発点だ。まず許可の段階を完了し、それからトンネルを上げる。この順序なら、トンネルが落ちている間ずっとブロックが保たれる。

落とし穴は、インターネット接続を許可するポータルが、あなたのVPNアカウントを認証したわけではないことだ。トンネルはそのあと接続しなければならず、それ自体の理由で失敗しうる。許可と認証は別々の出来事であり、人はそれを一つに混同する。

許可が何度も切れるなら、ポータルが再び要求するのか、ネットワークが切れるのか、VPNだけが失敗するのかを記録する。

選択肢B：狭いサインイン例外を開き、そのあとでブロックを戻す

別の方法は、ブロックを他の部分では有効にしたままポータルの通信だけを許し、サインインしてから例外を外すことだ。例外は狭くあるべきで、一つの宛先か一つのアドレス範囲を、サインインの間だけ、直後にブロックを戻す形にする。広い一時的な窓は、二分のサインインが午後いっぱいの無防備な通信になる道だ。

自分のクライアントが実際に何を実装しているかを知る。macOSのOpenVPN Connectは、VPNの一時停止中や再接続中にインターネットアクセスをブロックするオプションとは別に、キャプティブポータルの検出を文書化している。ポータルを検出することとその通信を許可することは関連する作業であって、交換可能な約束ではない。

管理端末では、例外をでっち上げるのではなく、設定された許可手順に従う。

すき間が何を、誰に露出するか

この膠着で面白いのは目の前のブラウザタブではない。接続性が現れた瞬間からネットワークを使い始める他のすべてだ。メール、写真の同期、更新の確認、再接続するチャットクライアント、再開するバックアップエージェント。

静かなブラウザウィンドウは、それらについて何も教えてくれない。許可された直接アクセスの間隔の前に機密の作業を閉じるか止め、ログイン時に何が動くかを確認する。Androidでは、 VPNの外側の接続をブロックする設定と組み合わせた常時接続VPN が該当する制御であり、いいかげんな経路の例外はそれを理解することの代わりにはならない。

一時的なアクセス窓についての古い助言がまだ当てはまるのは、ここだけだ。仕組みがそうでなくても、懸念は正しかった。

どう選び、どう確認するか

端末かクライアントが本物のポータルの流れを支えているなら選択肢Aを選ぶ。ブロックが終始保たれるからだ。ポータルに他の方法で到達できないなら選択肢Bを選び、例外は担当者を決めた期限付きの変更として扱う。

次に、結果ではなく順序を確認する。

curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'

許可を完了し、意図したプロファイルを確立し、一時的に変えたブロック制御を戻し、それから新しく無害な要求を出して、それがトンネルを通ることを確認する。ブロックがまだ切れているから成功する要求は、トンネルについて何も証明しない。

VPNの出口を切り替えても、期限切れのホテルのセッションは更新されない。それは別の出来事であり、混同すると探す場所を間違える。