VPN が接続する前にホットスポットが DNS を転送するのはなぜか
ホットスポットは自網内で名前解決を書き換え、ホスト名のエンドポイントはトンネルが存在する前に解決される。どのリゾルバが各クエリに答えたのかを追跡する。
ホテルのネットワークに接続すると、二つの DNS 判断が異なる場面で迫られる。サインイン中に端末が行う問い合わせと、トンネルが立ち上がった後に行われる問い合わせだ。ホットスポットは、自ら制御するネットワークを通じて前者に影響を与えられる。後者はクライアント自身の方針次第であり、別に調べるべき事柄である。
接続を、最初の DHCP リースから、非公開の名前を解決した問い合わせまで順にたどる。すると、サポートチケットでは同じに見える二つの障害がはっきり分かれる。一つはトンネルが存在する前に起き、もう一つはその内部で起きた。
ホットスポットが触れられる範囲と触れられない範囲
アクセス網は DHCP でリゾルバのアドレスを配り、そのアドレスに向かうポート 53 を傍受できる。それだけで、保護されていない問い合わせすべてにポータルのアドレスやブロックページで答えられる。エンドポイントがホスト名で書かれた VPN クライアントを壊すのにも十分だ。
ホットスポットにできないのは、確立したトンネルの中を問い合わせが通った後にそれを読んだり書き換えたりすることであり、ただしトンネルが本当に運んでいる場合に限る。傍受には平文の問いが見えることが必要だ。
問い合わせは、ホットスポットとは無関係な理由でもトンネルの外に出る。ブラウザの安全な DNS 設定、企業のサフィックスをローカルのリゾルバに残す split-DNS の規則、DNS をトンネルから外すよう設定されたクライアントなどだ。どれもクライアント側の選択であり、外から見ればどれもホットスポットの干渉のように見える。
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
最初の問い合わせはトンネルが存在する前に起きる
ホスト名を与えられたクライアントはまずそれを解決しなければならず、その瞬間にはどのトンネルも問い合わせを守っていない。ホットスポットがポータルのアドレスで答えると、交渉は失敗するか止まる。何も答えなければ、クライアントは名前のエラーを報告し、トンネルは決して始まらない。どちらの結果でも、そうでなければ無害に見える空のトンネルログを説明できる。
オペレーティングシステムも独自の接続確認とポータル検出を実行しており、それは RFC 8910 と RFC 8952 に記述されている。そしてそれらの要求は、どの VPN も立ち上がる前に出ていく。プロキシのログにそれが見えるのは漏えいの証拠ではなく、想定される動作だ。
実用的な解決策は、名前解決を必要としないエンドポイントをクライアントに与えることだ。それが不可能な場合は、先にサインインを終えてから接続する。
どのリゾルバが答えたのかを突き止める
ブラウザではなくシステムに尋ね、問い合わせを二回、つまり一度は端末が現在使っているリゾルバを通し、もう一度は固定のアドレスに対して実行する。
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
最初のコマンドの答えが三番目と違えば、ローカルのリゾルバが別の何かを返していると分かるが、リダイレクトするホットスポットはまさにそうする。三番目の失敗と一番目の成功が並べばポータルを指す。ローカルのリゾルバがサインイン用のアドレスを返し、外向きのポート 53 が落とされていたのだ。両方でタイムアウトするなら、認証が終わるまでネットワークが DNS を捨てているということだ。
接続後にもう一度繰り返して比べる。キャッシュされた答えは切り替えを生き延びるので、キャッシュを消すか、二回目の観察には新しい名前で問い合わせる。
以降の問い合わせを意図した経路に保つ
DNS も取り込むフルトンネルのプロファイルが最も単純な構成だ。すべてのアプリのすべての問い合わせがトンネルが押し出すリゾルバに届き、ローカルネットワークは暗号化された通信しか見ない。接続後に内部の名前と公開の名前を解決し、その両方の答えをトンネルのリゾルバが単独で返すものと比べれば証明できる。
split-DNS には、企業のサフィックスはトンネル経由、それ以外はローカル、そして両者に重なりを設けないという、意図をもって書いたドメイン一覧が要る。
ブラウザの安全な DNS はその方針の外にある。だからプロファイルが予測どおりに動くために切っておく必要があるなら、機械全体ではなくそのプロファイルで切る。システムのリゾルバを編集するのではなくブラウザの設定で行い、次回に変更が見えるようにする。テストごとに答え、リゾルバ、接続の段階を一行で記録する。ホテルの Wi-Fi で DNS が失敗したという報告は、少なくとも三つの異なる原因を持つ症状を述べているにすぎない。