ホテル・公共Wi-Fiのキャプティブポータル——何が起きていて、どこまで気をつけるか

ホテルや空港のWi-Fiにつなぐと、ブラウザーが自動で開いて利用規約への同意画面が出る。これはキャプティブポータルと呼ばれる仕組みで、実装としてはネットワーク側が通信に割り込んでいる状態だ。危険かどうかの議論は、まずこの事実から始めたほうが正確になる。

割り込みの手段は、DNS応答の書き換えとHTTPのリダイレクトに限られる。HTTPSの通信は書き換えられない——施設側が正しい証明書を用意できないからだ。何が守られていて何が守られていないかは、この線引きで決まる。

「同意画面」が出るまでに何が起きているか

認証が終わるまで、端末のDNSとルーティングは施設側の機器の制御下にある。OSはこれを検知するために、接続直後に決まったURLへ定型のリクエストを送り、想定どおりの応答が返るかどうかを見ている。

• Appleの端末：captive.apple.com にある固定内容のページを取得できるかを確認する。
• Android：connectivitycheck.gstatic.com に対し、本文のない204応答が返るかを確認する。
• Windows：msftconnecttest.com の固定内容のテキストが返るかを確認する。

想定と違う応答（多くはポータルへのリダイレクト）が返ると、OSは「認証が必要なネットワーク」と判断し、専用の簡易ブラウザーを開く。ポータルがなかなか出ないときに http:// のページを開くと表示されることがあるのは、この割り込みがHTTPにしか効かないためだ。

なぜ接続直後にVPNが張れないのか

認証前は外向きの通信がほぼ遮断されている。VPNのハンドシェイクも例外ではないので、当然つながらない。ここでキルスイッチ（VPN未接続時に通信を止める機能）を有効にしていると、ポータル自体に到達できず「Wi-Fiにはつながったのに何も表示されない」状態になる。

• 対処は順番の問題。キルスイッチを一時的に解除 → ポータルで認証 → VPNを接続 → キルスイッチを戻す。
• DNS over HTTPSやDNS over TLSを常時有効にしていると、施設側のDNS書き換えが効かず、ポータル検出が失敗することがある。認証の間だけ既定のDNSに戻す。
• 端末側のプライベートリレー系の機能や、常時オンのフィルターも同じ理由で検出を妨げる。
• それでも出ない場合は、ブラウザーのプライベートウィンドウで http:// から始まるページを開く。キャッシュとHSTSの影響を避けられる。

証明書の警告を通してはいけない理由

認証が終わったあとの通常の通信で、ブラウザーが証明書エラーを出したら、そこで止める。それは通信相手が名乗っているとおりの相手だと確認できなかった状態であり、「ホテルだから当たり前」という話ではない。例外として登録すると、そのサイトについては以後の警告も出なくなる。

HSTSが設定された主要サイトでは、そもそも「危険を承知で進む」という選択肢が表示されない。これは仕様どおりの防御なので、回避策を探すのではなく、そのネットワークでの作業をやめるのが正しい判断になる。

一方、ポータル画面自体がHTTPで表示されるのは仕様上ありうる。ただしそこで入力してよいのは、部屋番号や氏名など宿泊者確認の範囲までだ。クレジットカード番号、メールのパスワード、SNSのログインを求めてくるポータルが出たら、そのネットワークは使わない。

実際の接続手順

1. 1SSIDをフロントか館内表示で確認する。1文字違いや、末尾に _Free を足しただけの似た名前が並んでいることがある。電波が強いほうを選ぶ、という決め方はしない。
2. 2接続前に端末のネットワークプロファイルを「パブリック」にする。Windowsはネットワーク探索とファイル共有をオフ、macOSはファイル共有をオフ、AirDropは「連絡先のみ」または受信オフ。
3. 3「自動接続」をオフにして手動で接続する。次回以降、同じ名前のSSIDに勝手につながるのを防げる。
4. 4プライベートウィンドウでポータルを開き、認証に必要な情報だけを入力する。パスワードマネージャーの自動入力は使わない。
5. 5認証が通ったらVPNを接続する。接続後、DNSの問い合わせがVPN側へ向いているかをリーク確認ページで確認する。施設側のDNSに漏れていると、どのサイトを見たかは経路上に残る。
6. 6作業を終えたら、設定から「このネットワークを削除」を実行する。保存されたSSIDは、別の場所で同名のアクセスポイントを立てられたときに自動接続の材料になる。

接続後に速度が出ない場合、原因が施設の帯域なのか経路なのかは切り分けできる。手順は遅さの切り分けの記事にまとめた。ホテルのWi-Fiは同時利用者が多く、夜間に落ちる場合は施設側の設備が原因のことが多い。

端末側で常に効く設定

• 保存済みネットワークの棚卸し：使い終わった公共SSIDは削除する。保存数が増えるほど、端末が周囲へ「このSSIDはあるか」と尋ねる機会が増える。
• MACアドレスのランダム化：近年のiOSとAndroidでは既定で有効。施設側で不具合が出たときにそのネットワークだけ解除し、恒久的には無効化しない。
• 共有機能の既定値：プリンター共有、ネットワーク探索、リモートデスクトップは出発前にオフにしておく。ホテルのネットワークは、他の宿泊者と同じセグメントのことがある。
• OSとブラウザーの更新：TLSと証明書検証の修正は更新でしか入らない。出発前に済ませる。
• テザリングという選択肢：短時間の重要な作業なら、施設のWi-Fiを使わずスマートフォンのテザリングにするのがもっとも確実で、手順も少ない。

自宅回線側は前提がまったく違う。IPoE環境での挙動はIPoE方式とVPNの記事にまとめている。

よくある質問