VPN 接続時に WSL が職場のホスト名を失うのはなぜですか？

Windows は社内ホストを何事もなく解決しますが、同じ名前はトンネルが上がった瞬間に WSL 内で失敗します。よくある修理はディストリビューションに公開リゾルバーを書き込むことですが、それでは通常の閲覧は戻るものの、職場のホスト名は解決できなくなります。これは一つの障害を別の障害に置き換え、実際に壊れた層を隠してしまいます。リゾルバーの行を追加または削除する前に、三つの層のどれが失敗しているのかを突き止めてください。

まずルーティングの失敗を除外する

両側でまったく同じ完全修飾名を、似た二つの名前ではなく問い合わせてください。同じ文字列に対して Windows では成功し WSL では失敗するのは、二つの解決経路があることの証拠であり、このパターンをこれほどきれいに生み出すものは他にほとんどありません。WSL が既知の数値アドレスでもサービスに到達できないなら、ルーティングやフィルタリングの問題も併存しています。その場合 DNS の作業では明らかにならず、午後は間違った層に費やされます。

三つの症状でこうしたケースのほとんどを覆えますが、それぞれ指し示す先は違います。設定ファイルを開く前に、該当する行を読んでください:

真ん中の行は、それを壊した変更が数週間前に行われ当時は成功したように見えたため、人々が読み違える行です。三番目の行は、解決できる名前がネットワークの健全さの証拠のように感じられるため、人々が誤診する行です。どちらの行も、以下の別の節へあなたを送ります。

DNS トンネリングにはバージョンの下限があります

Microsoft は、仮想化チャネルを通じて DNS 要求を Windows のリゾルバーへトンネルする WSL のネットワークモードを文書化しています。対応する Windows 11 のビルドでは既定で有効になっており、だからこそ同じ社内ネットワーク上の二台のマシンが異なる動作をします。変わるのはビルド番号であり、社内ポリシーではありません。

WSL ネットワークガイド はそのモードと対応するバージョンを説明しています。この機能が重要なので、社内の DNS ポリシーは通常 Windows のリゾルバーにあり、Windows の経路を引き継ぐディストリビューションはポリシーも一緒に引き継ぎます。公開リゾルバーに問い合わせるディストリビューションには、どれほど設定が整っていても、プライベート名への経路がありません。その仕組みが症状の全体を説明し、公開リゾルバーによる回避策が失敗する理由も説明します。

何かを編集する前にビルドを読んでください。新しいインストールからコピーした設定は、古いインストールがそれを実装している証拠にはなりません。二台のマシンの違いはほぼ常にポリシーではなくバージョンなので、変更の横にビルド番号を記録してください。

古い上書き設定は、それが解決した問題より長く生き残る

古い手順は 生成されるリゾルバーファイルを無効にし、ネームサーバーをハードコードし、あるいはファイルを不変属性でロックしていました。そうした変更は、それを引き起こした接続問題が消えたずっと後まで残り、新しい設定が何もしていないように見える理由はたいていこれです。また、ログインのたびにファイルを書き換える shell プロファイルという形で、ディストリビューションの再インストール後も生き残ります。最後のものは見つけるのが最も難しく、誰もが確認するファイルからは見えません。

手書きのリゾルバーファイルと、その上の不変属性と、それを書き換える起動スクリプトを探してください。ロックされたファイルへの書き込みは権限の問題のように読める形で失敗するので、編集する前に不変フラグを確認してください。そこのスクリプトがあなたの修正から数秒で古い内容を復元するので、その後で shell プロファイルを確認してください。

上書き設定の削除には影響があるので、何を削除したのか、なぜ削除したのかを記録してください。別の目的で本当に静的リゾルバーを必要とするディストリビューションは、生成ファイルが戻ると壊れます。

二つのファイル、二つの異なる役割

二つの設定ファイルは別の場所にあり、別のものを制御しており、混同すると間違った層に編集が適用されます。Windows 側のファイルは仮想マシンのプロパティを設定し、ディストリビューション側のファイルはそのディストリビューションが独自のリゾルバー設定をどう組み立てるかを設定します。どちらも他方を上書きしないので、両者が一致している必要があります。

この機能に対応したインストールでは、Windows 側の断片は短いものです。それがその側の変更のすべてです:

[wsl2]
dnsTunneling=true

その断片は Windows のユーザープロファイルに入り、単一のディストリビューションではなく仮想マシンに適用されます。トンネリングにはディストリビューションがリゾルバーの生成を無効にしていないことも必要なので、ディストリビューション側のファイルはその動作に触れてはいけません。片方だけを変えるとモードは黙って何もせず、これがこの修理が壊れていると報告される最も一般的な形です。数週間離れた二つの編集は誰も帰属できない二つの編集なので、同じセッションで両方のファイルを確認してください。

再起動してから、両側から問い合わせる

これらの設定は環境の起動時に読み込まれるので、実行中のディストリビューション内の新しい shell は再読み込みしません。どのディストリビューションもそれと一緒に停止するので、shell を再起動するのではなく環境を停止し、先に実行中の作業を保存してください。この省略だけで、変更が効かないという報告のほとんどが説明できます。

次に、両側から同じ質問をしてください。出力は、ディストリビューションが最終的にどのリゾルバーを使ったかも示します:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

最初のコマンドは環境を終了し、二番目はディストリビューションが今どのリゾルバーを使っているかを示し、最後の二つは同じ質問を各側に投げます。設定の状態ではなく、答えを比較してください。両方のファイルが正しい状態でクリーンな再起動を行っても失敗する問い合わせは、社内のリゾルバーポリシーを指しており、その会話の担当者は別です。