Windows VPN で DNS サーバーが誤る: メトリック、バインド順、サフィックス

Windows クライアントはトンネルが正常でも、社内リゾルバーを保持していても、内部名を家庭用ルーターへ送ってしまうことがある。どのサーバーが応答するかを決める仕組みは三つあり、それぞれ違う形で失敗する。三つすべてを直す必要はない。症状がどれが関与しているかを教えてくれる。以下の判断ツリーは数分で終わり、メトリック変更・レジストリの並べ替え・NRPT ルールが同時に入って何が効いたのか分からなくなる、よくある結末を防ぐ。

決める仕組みは三つ、たいてい一つが間違っている

インターフェイス メトリックは、特定のアドレス ファミリについてアダプターを順序付ける。Tcpip\Linkage 配下のバインド順は、古いコード経路が今も参照するマシン全体のインターフェイス識別子の一覧だ。名前解決ポリシー テーブル (NRPT) は名前空間を特定のサーバーに結び付け、サフィックス一覧は短い名前を展開するかどうかを決める。これらは独立しているので、VPN アダプター上の正しいリゾルバーが他所の古い優先設定に負ける。

これらの仕組みはいずれもトンネルの向こう側ではない。VPN が押し出すサーバーが名前を解決できなければ、クライアント側の設定はすべて飾りであり、最初の判断はリゾルバー自体が直接問い合わせられたときに応答できるかどうかだ。

判断その一: 押し出されたリゾルバーは応答できるのか？

サーバーに明示的に問い合わせ、通常の検索と比較する。二つの答えの差が選択の問題と到達性の問題を分け、ここでの最短の分岐はこれだ:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

最初が成功して二番目が失敗するなら、リゾルバーには到達できており Windows の選択が悪いので、以下の名前空間と順序の判断へ進む。最初も失敗するならクライアント側では何も助けにならず、UDP と TCP 53 がトンネル経由でサーバーに届くか、サーバー上のホスト ファイアウォールがプールを捨てていないか、サーバー自身のフォワーダーが健全かを確認する。

この分岐で止まる。到達できないリゾルバーに NRPT ルールを適用すると、同じ障害がより多くの後戻り作業とともに生じ、権威ありげに見えるルールの背後に本当の不具合を隠してしまう。

判断その二: 一つの名前空間か、すべてのクエリか？

範囲が道具を決める。社内名だけが失敗するなら、マシンを並べ替えるのではなく名前空間を結び付ける。NRPT ルールがそのサフィックスをトンネルのリゾルバーへ送り、ほかはそのままにする。すべての検索が影響を受けるなら、問題はアダプターの全体優先順位であり、サーバー設定を何も変えないメトリックから始めるのが正しい。

アドレス ファミリごとに、両方のインターフェイスでメトリックを設定し、その後に順序を確認する:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

11 を上の行のトンネル アダプターの ifIndex に置き換える。11 が LAN アダプターなら同じコマンドは誤った経路を下げてしまい、代わりに LAN アダプターを上げれば反対側から同じ順序に到達する: netsh int ip set interface interface="Ethernet" metric=15、二つ目のファミリには netsh int ipv6 set interface interface="Ethernet" metric=15 を使う、int ip は IPv4 にしか触れないからだ。

バインド順は最初の一手ではなく最後の手段だ。HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage はデバイス識別子の Bind 一覧を保持し、トンネルの識別子を先頭へ移すと確かにどちらのアダプターが先に問い合わされるかは変わるが、名前空間ごとの範囲を持たないマシン全体のレジストリ値である。編集前にエクスポートし、その後にトンネルを再接続して、クライアントが期待する状態で順序が効くようにする。

単一の名前空間には、より狭い道具を選ぶ:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

判断その三: 修正は再接続を生き延びるか？

次のダイヤルアップ再接続までしか効かないメトリックは、そもそも保存されていなかった。L2TP/IPsec などの接続プロファイルは接続開始時に作り直されるため、保存値は電話帳エントリに IpInterfaceMetric として存在し、稼働中のインターフェイスだけにあるのではない。まさにこの理由でそのフィールドをスクリプト化する環境もあれば、管理ポリシーから優先設定を押し出して端末をそのままにする環境もある。

キャッシュと登録は別の層だ。トンネルが上がってからこれらを実行すると、古いエントリが直りクライアントが再登録されるが、どちらもアダプターを並べ替えない:

ipconfig /registerdns
ipconfig /flushdns

同じ層に停止スイッチがある。物理アダプターで動的登録を無効にすると、クライアントが VPN 側のアドレスを誤った名前で広告しなくなる。これは上の更新とは別の修復だ。

IPv6 は判断の中で独自の行に値する。物理アダプターがグローバル IPv6 アドレスを持ち、トンネルが IPv4 しか運ばない場合、Windows は名前解決にトンネル外の経路を優先することがある。IPv4 向けに設定したメトリックはこのファミリについて何も語らないので、別に確認する:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

LAN アダプターで IPv6 を無効にすると、その経路とプロトコルが一緒に消える。IPv6 インターフェイスのメトリック変更や社内名前空間への NRPT ルールなら、ファミリを保ったまま優先設定を直せる。そのリンクに IPv6 を持たせないと決めたのでなければ、狭い方を選ぶ。

出所を名指しして検証し、所有者を一人に保つ

ページが読み込めるかだけでなく、どの出所が有効かを報告する道具で検証する:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

次に、フィルタリングと選択を切り分ける。アプリケーションから見ると両者は同じに見える。OpenVPN の block-outside-dns は他のアダプターでポート 53 を遮断するが、リゾルバーを選ぶわけではない。いま全てのクエリが失敗するなら、フィルターが唯一到達できるサーバーを遮断しているかもしれない。設定したリゾルバーが無視されているなら、順序か名前空間ルールが誤っている。両方を同時に変えると、遮断されたクエリと無視されたクエリの区別がつかなくなる。

DNS ポリシーの所有者は一人にし、VPN プロファイル、管理ポリシー、NRPT ルールのいずれかであって二つにしない。閉じる前に:

• 押し出されたリゾルバーは明示的に名指しすれば応答し、通常の検索がそれを使っている。
• 変更したルールやメトリックが、実際にクエリを運ぶアドレス ファミリを覆っている。
• 設定は切断と再接続を生き延びるか、保存済みプロファイルへ移してある。
• 権威を持つ仕組みはちょうど一つで、ほかは元のままにしてある。

順序は片付けるものではなく環境の状態として扱う。再接続の後、そしてネットワーク スタックに触れる Windows 更新の後に再確認する。どちらも物理アダプターを再び先頭に戻しうる。