ホストが VPN に接続すると VirtualBox ゲストの DNS が壊れる
ゲストには独自のリゾルバーがあり、NAT は DNS に二通りに応答できる。アダプターのモード、リゾルバーの経路、ホストのリゾルバーモード、VPN の再接続という四つの確認。
VPN が接続した瞬間に Windows ホストでは社内アプリケーションが名前解決されるのに、VirtualBox の NAT の背後にある Ubuntu ゲストはそれをまだ見つけられない。ゲストには独自のリゾルバーがあり、NAT アダプターは DNS を複数の方法で扱える。ゲストのリゾルバーを公開サーバーに置き換えると、通常のウェブサイトは動くが社内名は失敗し、問題を解決するのではなく別の場所へ移しているだけだ。四つの確認を順に行い、当てはまらない最初の確認で止める。
どのアダプターモードを調べているのかを確認する
この記事が説明する挙動になるのは、素の NAT モードのアダプターだけだ。ブリッジアダプターは独自の識別情報を持って物理ネットワークに接続し、NAT ネットワークは独自の DHCP と DNS 設定を持つ名前付きの仮想スイッチであり、ゲスト内の VPN クライアントはまったく別のリゾルバーを追加する。読み進める前にモードを確認すること、どの場合でも修復方法が異なるからだ。
一台の仮想マシンが異なるモードのアダプターを二つ持つことがあり、影響を受けているものが常に一つ目とは限らない。
ホスト側でその名前が解決できるかどうかも確認する。トンネルを上げた状態でホスト上で同じアプリケーションを開き、ゲストが使うのと同じ完全修飾名を使う。ホストでも失敗するなら原因はゲストではなく、仮想ネットワークをどう変えても直らない。
ゲストのリゾルバーを通して一つの名前を追う
社内名を一つ、公開の対照名を一つ選び、両方を両方の場所で試す。公開名は解決できて社内名はできないなら、不具合は名前解決全般ではなく社内側の経路にあると特定できる。社内名だけを試すと、壊れたリゾルバーと壊れた経路を区別できなくなる。
ゲストの内部で、リゾルバーが実際に何を使う設定になっているかを見る。systemd-resolved を動かす Ubuntu ゲストでは、リンクごとの状態に到達したサーバーが表示され、resolv.conf の中身がスタブアドレスだけということもあるが、それは正しい状態であって怪しいわけではない。手で編集したファイルや別の暗号化 DNS クライアントが、問い合わせをまったく別の場所へ送っていることもある。変更する前に見つけた内容を記録する。
resolvectl status
resolvectl query app.internal.exampleここでは名前解決と到達性を分けて考える。サービスが到達不能なまま住所だけが返るのは DNS ではなく、経路やポリシーの問題だ。
そのアダプターでホストのリゾルバーモードを試す
VirtualBox の NAT DNS オプションは異なる仕組みを表しており、ホスト自身のリゾルバーがトンネルとともに変わる場合にはその違いが効いてくる。DNS プロキシーはゲストの要求を渡されたサーバーへ転送する。ホストのリゾルバーモードは要求を横取りしてホストの DNS API を呼び、VPN クライアントに再設定された Windows のリゾルバーに追随するのはこちらだ。
間違った仕組みを有効にすると、挙動が変わらないままコマンドだけは成功し、午後を無駄にする紛らわしいやり方になる。
VBoxManage modifyvm "work-ubuntu" --natdnshostresolver1 on仮想マシンの現在の設定を記録し、電源を切り、先に確認したアダプターを対象にする。オプション末尾の数字は定数ではなくアダプター番号なので、影響を受けているアダプターが二つ目のマシンに適用しても静かに何も起きない。ゲストを起動して、実際に受け取ったリゾルバー設定を確認する(ゲスト側の手動設定は NAT 層が提供するすべてに優先するため)。ホストのリゾルバーモードは、共有したいのがホスト自身の DNS 経路であることも前提にしている点を忘れない。
VPN の再接続をまたいで同じテストを繰り返す
ゲストで両方の問い合わせを繰り返し、そのうえで実際のアプリケーションを開いて証明書を自身で検証させる。アドレスだけのテストは名前解決の切り分けには役立つが、動作する TLS セッションと同等ではないので ping で止めてはいけない。次に承認された時間帯にホストのトンネルを切断して再接続し、もう一度繰り返す。起動後最初の接続でだけ保たれる挙動は報告すべきライフサイクルの問題であり、別のリゾルバーで追いかける DNS の謎ではない。
公開名の解決が動くことは、社内の問い合わせがポリシーの求める経路にとどまった証拠にはならない。
ホストのリゾルバーモードで何も変わらないときは、記録した設定を戻し、四つの観察、つまりホストが返したもの、ゲストが返したもの、アダプターのモード、リゾルバーの状態を残す。到達できない社内サーバー、ハイパーバイザーの通信を除外するフィルター、ゲスト側の上書きは、それぞれ別の修正を必要とする。アダプターをブリッジへ変えるのはネットワーク設計の変更であり、DNS のリセットではない。