Windows で OpenVPN 接続後に DNS が動かなくなる理由

オフィスのリゾルバーへの ping は "OpenVPN" が接続した後も応答を返すのに、名前の解決はどれも失敗する。アドレスには届くのにポートには届かない。Windows がアダプター単位で DNS をフィルタリングできると知れば、この組み合わせは筋が通り、プロファイルに block-outside-dns があればそのフィルターが第一の容疑者で、ルートテーブルを見るのは間違った場所だ。以下の二つのテストは数秒で階層を切り分ける。

到達できるアドレス、死んだポート

ping が成功すれば、ホストが動いていて経路が存在することは証明できる。しかしポート 53 に到達する許可については何も言えない。問題のフィルターは別の階層で動作し、アダプターに紐づくから、同じマシンが ICMP には応答し、同じアドレスへ送った問い合わせをすべて拒否することがある。設定を変える前に、二つのテストを同じセッションで実行してほしい。

ping <resolver-ip>
nslookup <name> <resolver-ip>

この二つが揃えば診断になる。サブネットへの通常の通信は動き続けるのに名前解決だけが死ぬので、サーバーが壊れたのだとか DNS が一度も送られていないのだと結論されがちだ。どちらの説明も追うには高くつくし、証拠はもっと狭い場所を指している。設定に触る前に、この組み合わせを確認してほしい。

このオプションはフィルタリング基盤の規則である

OpenVPN のリファレンスは block-outside-dns を Windows Filtering Platform の制限として説明している。トンネル外のアダプターでアプリケーションが DNS に到達するのを止めるもので、対象は TCP と UDP のポート 53 に及ぶ。フィルターは通常のファイアウォール規則一覧ではなく WFP の中に住んでいるため、別の場所に許可規則を足しても結果が必ず変わるわけではない。だから DNS を許可せよという定番の助言は失敗し続ける。

この設定は取り込んだプロファイルからもサーバーからも届きうるし、最後に編集したファイルは "クライアントが何を読み込んだかの証拠にはならない"。有効な構成と接続ログを併せて読むこと。このオプションは Windows 固有でもあり、移植可能として扱うと当てはまらない助言になる。

規則を増やすのではなく、その制限を所有するクライアント側のコンポーネントを探す。所有者こそが実際に制限を取り除けるものだ。

フィルターはリゾルバーではない

トンネル外の通信を遮断しても、その内側に動くリゾルバーが導入されるわけではない。このオプションは経路を一つ外し、トンネルの DNS 構成をプロファイルを設定した者の裁量に残す。リゾルバーを一度も送っていないプロファイルには、いまや一つもない。

三つの確認を順に行う。第一に、失敗しているアプリケーションが実際にどのリゾルバーを使っているか。第二に、クライアントが VPN の DNS 設定を適用したか。第三に、どのインターフェースがそのリゾルバーへの通信を運んでいるか。

1. 使用中のリゾルバー: Resolve-DnsName -Server <resolver-ip> <name> を ipconfig /all が一覧する DNS サーバーと比較する。
2. VPN の DNS 適用: 同じ ipconfig /all の出力でトンネル アダプターの DNS エントリを確認する。
3. 使用中のインターフェース: Find-NetRoute -RemoteIPAddress <resolver-ip> がその宛先の出力インターフェースを示す。

このポリシーの下では、他の LAN 通信が動いていても、LAN のリゾルバーは設計上到達不能になる。これはオプションが仕事をしているだけだ。設計に VPN 経由の DNS が必要ならリゾルバーの登録とトンネルの経路を直し、ローカルな例外を伴う split DNS が必要なら構成の所有者がその例外をサポートされた方法で表現しなければならない。

このオプションが覆わないもの

ポート 53 は名前解決のすべてではない。DNS over HTTPS と DNS over TLS は別のトランスポートを使い、一部のアプリケーションはシステム設定にかかわらず独自のリゾルバー処理を走らせる。だからブラウザーは名前を解決できるのに、コマンドラインはできないことがある。

その違いは矛盾ではなく診断材料として扱う。システムのリゾルバーが壊れていると決める前に、両者を比べること。

書き記すときは結論を狭く保つ。このオプションは一つのプラットフォーム上の一つのトランスポートを制約するだけで、解決経路の残りは所有者の異なる別の設計課題だ。

切断の前後で状態を確認する

接続中に同じ検索を実行し、所有者のクライアントが切断した後にもう一度実行する。トンネルが上がっている間は、外部のリゾルバーに対して一つ目が失敗するはずで、フィルターが外れれば二つ目が成功するはずだ。切断後も失敗するなら、フィルターが片付いていない。

ipconfig /displaydns
nslookup <name> <resolver-ip>

クライアント サービスやマシンを再起動すると、たいてい古いフィルターは消えるが、これは診断を裏づけるだけで恒久的な修正を証明するものではない。切断を生き延びるフィルターはまた同じことをするので、見たことを記録しておくこと。その記録がバグ報告の根拠になる。

リゾルバーの交換やファイアウォール ポリシーの作り直しが意味を持つのは、これらの確認の後だけだ。どちらも証拠が支えるより大きな変更である。