VPN は接続済みなのに名前が解決できない：DNS が本当に壊れる場所

トンネルは上がり、アイコンは緑なのに、ブラウザのどのタブも名前解決の失敗を報告している。この状況は三つの異なる仕組みで生じる。リゾルバーに到達できない、想定していないリゾルバーに問い合わせている、あるいは社内名だけが失敗している、のいずれかだ。トンネルプロトコルを変える前にこれらを切り分けてほしい。修復する場所がそれぞれ違うからだ。以下の順序は、三つを分ける観察から始まる。

名前解決に本当に必要なもの

名前解決には三つが必要だ。リゾルバーのアドレス、そのアドレスへの経路、そして問い合わせに合う回答である。それぞれが単独で壊れ得るが、目に見える症状は同じ、読み込まれないページだ。だからどの一つが壊れたのか分かるまで、エラーページはほとんど何も教えてくれない。

クライアントはリゾルバーを VPN プロファイル、トンネル上の DHCP、あるいは自身の設定から学び、どれが優先されるかはプラットフォーム次第だ。Windows では、ipconfig /all がアダプターごとの DNS サーバーを表示するので、配布された値が実際に届いたか確認できる。届いたはずの値が OS に一度も届いていない、という静かでよくある失敗もある。プロファイルに触れる前に、設定されている値を読んでほしい。

Linux と macOS は同じ問いに別のコマンドで答える。答えは同じように読む価値がある。resolvectl status と scutil --dns はどちらもインターフェースごとにサーバーを一覧表示する。その一覧を、プロファイルが配布していると主張するアドレスと比べる。ここでの不一致は下流のすべてを説明するので、名前を試す前に片付けてほしい。

公開名と社内名をひとつずつ試す

同じマシンから、ありふれた公開ホスト名と文書化された社内ホスト名を問い合わせ、どちらのサーバーが答えたかを記録する。両方が失敗するなら、リゾルバーかその経路が壊れている。社内名だけが失敗するなら、リゾルバーは答えており、問いはゾーンかルーティングに移る。経路変更で差を説明できないよう、二つの問い合わせを一分以内に実行する。

社内名は公開のスクリーンショットにも公開リゾルバーにも出さない。タイムアウトと存在しないドメインへの応答は別の観察であり、前者は何も戻らなかったことを、後者は権威がその名前は存在しないと答えたことを意味する。両者を一つのエラーとして扱うと間違った層へ向かうことになり、証明書の警告はまた別の話で DNS の失敗ではない。

nslookup は問い合わせたサーバーと受け取った応答の両方を表示する。まさに必要な組だ。同じシェルで二回実行し、各応答の横に応答したアドレスを書く。

nslookup example.com
nslookup host.corp.example 10.20.30.53

クライアントがそのサーバーに本当に到達できるか確かめる

プロファイルが配布する社内リゾルバーは、トンネルが上がっている間にクライアントが到達できて初めて役に立つ。正しく見えるアドレスでも経路がなければタイムアウトになる。トンネルの接続状態はその経路について何も語らない。確認すべきは、VPN の終端ではなくリゾルバー自体に向けた経路の検索だ。

どのプラットフォームも一行で答え、出力に示されるインターフェースが答えのすべてだ。リゾルバーがトンネルの向こうにあるのに物理アダプターを指すなら、プロファイルはそれを覆うプレフィックスを配布していない。

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

スプリットトンネルのプロファイルでは、リゾルバーが配布された経路の外にあり得る。これはサーバーではなくプロファイルの問題だ。リゾルバーのアドレスを配布されたプレフィックスと比べ、どれかが覆っていることを確かめる。同じ不一致が、あるネットワークでは DNS が動き、同じプロファイルの別のネットワークでは失敗する理由を説明する。

ブラウザーはシステムのリゾルバーを迂回できることを忘れない

安全な DNS を有効にしたブラウザーは、HTTPS で自ら選んだ提供元に問い合わせを送り、OS のリゾルバーを完全に無視できる。するとシステムは正しく見えるのにブラウザーが失敗する、あるいはその逆になる。これはトンネルではなくブラウザーのポリシーの問題だ。

ブラウザーの安全な DNS 設定と、それを制御する管理ポリシーを確認し、トンネルを変えないまま二つ目のアプリかブラウザーを試す。ひとつのアプリだけが失敗するなら、修正はそのアプリに入れる。プライベートウィンドウは公平な比較にならない。あるブラウザーでは既定で拡張機能を無効にし、別のブラウザーでは無効にしないことがあり、管理ポリシーを迂回することも決してない。代わりに二つ目のブラウザープロファイルか別のアプリを使う。

キャッシュを消して実際の作業をやり直す

設定を直したら、ローカルのリゾルバーキャッシュを消して、古い応答が修正より長生きしないようにする。いったん回復してまた失敗するなら、原因はまだ残っているのであって、キャッシュ消去が失敗したのではない。三つのキャッシュは別物なので、使っているマシンに合う行を選ぶ。

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

そのうえで合成の問い合わせではなく元の作業を繰り返す。ユーザーにとって大事なのは作業そのものだからだ。一度は再接続して、ユーザーが実際に置かれる状態を再テストが覆うようにする。Microsoft の nslookup リファレンス は、問い合わせ引数のために手元に置くべきページだ。

切断した後にだけ名前が失敗するなら、クライアントは以前の設定を復元していない。これは報告すべきライフサイクルの不具合であり、DNS サーバーを交換すべき問題ではない。名前解決が動くことは漏えいテストにもならず、出口の国はどのリゾルバーが答えたかを教えてくれない。