KMMR Note

システムエンジニアの備忘録

  1. HOME
  2. 開発
  3. ネットワーク
  4. WSLだけ名前解決できないときは？Windowsとの比較とcurlエラーの確認

WSLだけ名前解決できないときは？Windowsとの比較とcurlエラーの確認

WSLだけ名前解決できないときは？Windowsとの比較とcurlエラーの確認

Windowsのブラウザーでは開けるサイトに、WSLのLinuxからだけアクセスできないことがあります。すぐにDNSサーバーを書き換えるより、同じホスト名がWindowsとLinuxで解決できるか、その後のHTTPS接続で止まるのかを順に見ると、調べる場所を絞れます。

以下はWSL 2のLinux側でgetentとcurl、Windows側でWindows PowerShellのResolve-DnsNameを使う方法です。例のexample.comは、調べたいホスト名に置き換えます。名前解決のコマンドにはhttps://やURLのパスを付けません。

目次

Windows側でDNSの応答を確かめる

まずWindows PowerShellで、IPv4のAレコードが返るかを見ます。

Resolve-DnsName -Name example.com -Type A -DnsOnly | Select-Object Name, Type

対象名のTypeがAの行が返れば、この問い合わせではIPv4のレコードを得られています。Aレコードがない名前や、社内だけで使う名前もあるため、応答がないことだけでネットワーク全体の故障とは判断できません。IPv6や問い合わせ先も調べたいときは、WindowsのResolve-DnsNameによるDNS確認が参考になります。

WSL側で同じホスト名を調べる

実際にアクセスできないアプリを動かしているディストリビューションのLinux端末で、同じ名前を指定します。別のUbuntuやコンテナーで試した結果と取り違えないことが大切です。

getent hosts example.com

アドレスと名前が返るかを見ます。getentはLinux側の名前解決の仕組みを通して情報を得るため、DNSだけを直接問い合わせる検査と同じではありません。hostsなどの設定も関わり、実装や設定によって参照方法が変わります。Windows側のAレコードと出力のアドレスが完全一致しないことだけでは、異常とは限りません。

Windowsでは返るのにこのLinux側で返らない場合は、WSLが使う名前解決経路や対象名の有効範囲が次の手掛かりです。どちらも返らない場合は、名前の入力、対象サービスのDNS、接続しているネットワークの条件から見直せます。

HTTPSの失敗を名前解決と分けて読む

名前が返ったら、同じLinux端末でHTTPの応答ヘッダーを調べます。今回は接続待ちを5秒、全体を10秒までにした例です。対象サーバーの処理や回線が遅い場合は、この短い制限でタイムアウトすることもあります。

curl -I --connect-timeout 5 --max-time 10 https://example.com/

HTTPのステータスやヘッダーが返れば、その要求ではHTTP応答を受け取っています。ただし、HEAD要求への対応、認証、リダイレクトなどはサービスごとに異なります。403などのHTTP応答が返る状態と、名前が解決できない状態は調べる入口が違います。

curlのエラー6は接続先ホスト名の解決失敗を示します。一方、28は指定時間内に完了しなかったという意味で、DNSだけに固有の番号ではありません。Resolving timed outのようなメッセージも合わせて読み、どの段階で待っているかを確かめてください。証明書のエラーならTLS側の確認へ進み、検証を無効にして成功と扱わないことが大切です。

プロキシが設定されている場合は、そのプロキシを経由した結果になることもあります。Windowsのブラウザー、getent、curlがすべて同じ経路で接続するとは限らないため、短い結果だけで原因を断定しないでください。

VPNとDNS設定は利用条件を見て判断する

MicrosoftはWindows 11 22H2以降のWSL向けに、DNS要求を仮想化の仕組みで処理するDNS tunnelingを案内しています。VPNなど複雑なネットワークとの互換性改善を目的とする機能ですが、個々の社内VPNでの接続を保証するものではありません。

設定を見直す際は、Windows側の.wslconfigとディストリビューション側の/etc/wsl.confの適用範囲も確認してください。たとえばgenerateResolvConfは、WSLによる/etc/resolv.confの生成に関係します。以前の対処で手動設定を加えているときは、その内容と現在の公式設定を照らし合わせるのが出発点になります。

社内名だけが見つからない場合は、組織のDNSやVPNの条件も必要です。公開DNSへの固定、VPNの切断、保護機能の解除を一律に行うと、別の接続や社内名の解決を壊すことがあります。許可された環境で同じ名前・同じ時刻のWindowsとLinuxの結果を残すと、管理者への相談にも役立ちます。

WSL本体の更新だけが403で失敗する場合は、WSL更新の403とWARPの確認手順のように更新ファイルの取得経路を調べる場面です。Linuxから外部名を解決する問題と混同せず、表示されたエラーと実行場所を起点に進めてください。

参考資料

このブラウザからの自分のアクセスを解析から除外できます。