VirtualBox NAT のゲスト DNS はホストが VPN に接続すると壊れる

Windows ホストでは VPN が接続すると内部アプリケーション名が解決されるが、Ubuntu ゲストの内部では解決されない。ゲストは独自のリゾルバー設定を保持する、そしてその前の NAT アダプターは DNS クエリに二通りの方法で応答できる。ゲストを公開リゾルバーに向けるとウェブサイトは再び読み込まれるが、プライベート名は壊れたままになる。そのため何かを編集する前にリゾルバーの経路をトレースする。

NAT アダプターを通して一度の検索をトレースする

対照として内部の完全修飾名を一つと公開名を一つ選ぶ。トンネルを上げた状態で、ホスト上で内部名が解決し、その背後のアプリケーションが開くことを確認する。次に同じ二つの検索をゲスト内で実行し、ツールではなく応答を比較する。

先に進む前に、アダプターが本当に単純な NAT であることを確認する。ブリッジアダプター、名前付き NAT ネットワーク、ゲスト内の二台目の VPN クライアントには、それぞれ独自の構成と独自の説明がある。この時点で推測すると、調査の残りが無駄になる。

VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natnet
resolvectl status | head -40
cat /etc/resolv.conf

最初のコマンドはアダプターのモードと、それに接続された NAT ネットワークを表示する。Ubuntu ゲスト内では二番目がリンクごとの DNS 設定を一覧し、三番目は多くの場合ローカルのスタブアドレスだけを明らかにする、つまり実際の upstream は別の場所にある。

解決と到達性は分けて考える。正しいアドレスを受け取っても接続を開けないゲストには、ルーティング、フィルタリング、またはサービス権限の問題があり、これ以上の DNS 変更では決して触れられない。アドレスを別にテストし、二つのうちどちらが失敗したかを書き留める。

プロキシモードとホストリゾルバーモードは別の仕組み

プロキシモードでは NAT エンジンがゲストのクエリを既知の DNS サーバーに転送する。ホストリゾルバーモードではクエリを傍受し、ホストのオペレーティングシステムに、ホストが今使っている方法で名前を解決するよう求める。トンネルが上がったときにホストの解決を書き換える VPN クライアントに従うのは二番目だけである。そのため二つの設定は同じマシンで異なる応答を返す。

この違いが一文で表した問題の全体である。ゲストにサーバーアドレスの一覧を渡すことは、Windows に構成済みのリゾルバーで名前を解決するよう頼むこととは同じではなく、分割 DNS の VPN では二つの応答が異なる。アダプターのオプションは仕組みの話であり、許可の話ではない。

どちらのモードも何かへのアクセスを許すものではない。認可は VPN ポリシーとサービスにあり、検索が成功したのは名前がアドレスになったというだけである。

アダプターを切り替え、ゲストが何を受け取るか確認する

まず VM のネットワークと DNS 設定を記録し、それからマシンを停止して、編集するのが永続構成になるようにする。最初のアダプターが NAT を担う work-ubuntu という VM では、VM の停止中にホストからアダプターごとのオプションを設定する。その後で再起動し、終了ステータスを信じるのではなく結果を調べる。

VBoxManage modifyvm work-ubuntu --natdnshostresolver1 on
VBoxManage showvminfo work-ubuntu --machinereadable | grep -i natdns

末尾の数字はアダプター番号を選ぶので、普遍的な値ではなく、アダプター 2 の設定ならその位置に 2 が入る。インストール済みの VirtualBox バージョンに属する VBoxManage バイナリを使い、パス上の古いものは、実行中のバージョンが無視する設定を書き込むことがある。

代わりにプロキシオプションを有効にすると別の仕組みが選ばれ、ホストリゾルバーの動作は得られない。ゲストの起動後、実際に保持している DNS 構成を確認する必要がある、ゲスト内の固定リゾルバーや暗号化 DNS 設定は、アダプターが何を提供してもアプリケーションを別の経路に保つからだ。

VPN のライフサイクル全体でテストし、一度だけで終わらせない

ゲストで両方の検索を繰り返し、それから実際のアプリケーションを開いて TLS ホスト名を検証させる。IP だけの接続テストは DNS をうまく切り分けるが、証明書の確認ではないし、そう報告すべきでもない。名前、アドレス、アプリケーションの結果を一緒に記録する。

承認された時間帯にホスト VPN を切断して再接続し、テストを繰り返す。結果はアクセスポリシーに一致すべきであり、公開解決が再び機能することは、プライベートクエリが意図した経路に残ったかどうかについて何も語らない。

ホストリゾルバーモードで何も変わらない場合は、記録した値を戻し、観察を保持する。ハイパーバイザーのトラフィックを除外する VPN クライアント、到達不能な内部リゾルバー、固定されたゲスト設定は、それぞれ別の修正を必要とし、アダプターをブリッジすると DNS をリセットするのではなくネットワーク設計を変える。