Windows VPN の DNS リーク：指標が経路に勝つ理由

クエリはマシンを離れて家庭用ルーターに届くのに、パケットはすべてトンネルを通っている。当然の結論は経路の欠落だが、経路はたいてい正しい。Windows はインターフェイスの指標によって、どのインターフェイスのリゾルバーに問い合わせるかを選べるため、トンネルアダプターはワイヤレスの相手にこの比較で負けることがよくある。

一つの漏洩に二つの説明

経路の説明は、通信の一部がトンネルの外へ漏れているというもので、それなら既定ルートか分割トンネルの一覧が誤っているはずだ。その説明はコマンド一つで試せる、そして既定ルートがトンネルを指していれば話は終わりだ。安上がりなのでまずこれを確認し、きれいに戻ってきたら脇に置く。

順位の説明は、通信はすべてトンネル内にあり、それでも名前解決は別のリゾルバーへ送られているというものだ。Windows はリゾルバーの選択を順序付きのインターフェイスごとの属性として扱うため、解決済みアドレス宛のパケットがトンネルを通っていても、指標の良い物理アダプターが名前の DNS を提供することがある。どちらの説明も漏洩テストのページでは同じ症状を出す、だからテストは診断ではない。ルートの編集で直るのはそのうち片方だけだ。

指標とリゾルバーをまとめて比べる

トンネルが上がっている間に、インターフェイスとその指標、設定されたサーバーを記録する。二つの別々の一覧ではなく表として読むべきで、問いはどのリゾルバーが先かであって、どのリゾルバーが存在するかではない。

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses

トンネルアダプターの数値が物理アダプターより大きければ、そのリゾルバーは優先されず、内部名は物理側が提供するものへ流れる。そのルーターはキャッシュから答えることも、クエリを転送することも、拒否することもあり、どの結果も意図した設計ではない。順位はあくまで優先度なので、エラーを出す代わりに黙って負ける。

リゾルバーがまったく設定されていないトンネルアダプターも、同じくらいよくある変種だ。クライアントは DNS を押し出さずにインターフェイスを立ち上げるので、順位の問いはそもそも生じない。

トンネルの順位を上げて再確認する

管理者権限のシェルで、トンネル インターフェイスに最も低い指標を与えるか、物理アダプターの値を上げる。どちらもインターフェイスごとの設定で、どちらも元に戻せる、目の前に座っていない可能性のあるマシンを変えるときにはこれが効いてくる。

Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric

変更はすぐに反映されるが、DNS クライアントや他の利用者はすでに行った選択をキャッシュしている。クエリの結果から何かを読み取る前に、トンネルを再接続するか再起動する。早すぎるテストは古い挙動を再現し、失敗した修正に見えるだろう。

そのうえで内部名と公開名を一つずつ引き、どのサーバーが答えたかを確認する。Microsoft の 自動指標についての解説 は、最も低い値が優先される理由と、自動割り当てがどう導かれるかを説明している。

再接続をまたいで維持する

接続のたびに作り直されるアダプターへの手動の指標は、消えてしまう設定だ。クライアントがインターフェイスを作り直すなら、この上書きには接続後のスクリプト、ポリシー、または接続中に DNS を所有するクライアント設定が必要になる。

物理アダプターに静的に設定されたサーバーは、同じ耐久性の問題を裏返しに抱える。それらは削除されるまでそのインターフェイスのために応答し続け、DHCP は次のリースでそれらを再び埋めるので、削除は測定であって設計ではない。耐久性のある設計は 内部名前空間のための名前解決ポリシー、または接続中 DNS の所有権を引き受けるクライアントだ。いずれにせよ、再接続の前後でリゾルバーの一覧を記録し、テストを終えたら元の指標に戻し、以前の挙動が戻ったことを確認する。