Hyper-V の仮想マシンはホストの VPN を使うのか？スイッチ次第だ

Hyper-V ホストに VPN クライアントを入れ、そこでブラウザを開くと出口アドレスが変わるが、同じページを仮想マシンの中で開くと古いアドレスのままだったり、何も表示されなかったりする。よくある結論は、仮想マシンが壊れている、あるいはスプリットトンネリングを有効にすべきだというものだ。どちらも成り立たない。VPN クライアントはマシンの属性ではなく、経路の集合、仮想アダプター、そして特定のインターフェースに付いたフィルターであることが多い。ゲストの通信がその仕組みに触れるかどうかは、ゲストが使う仮想スイッチで決まる。

神話を率直に言う

ホストに入れた VPN は、仮想マシンはそのマシン上で動くプロセスにすぎないのだから、仮想マシンを含むマシン全体を守るという信念がある。ウイルス対策もホストのファイアウォールも普通はそう振る舞うので、これは心地よい信念だ。ネットワークの経路は違う。

ゲストのフレームにホストの VPN スタックが触れるのは、ホストがそれをルーティングまたはフィルタリングするときだけだ。以下のどの事例もその変形にすぎないのだから、この一文を付箋に書いておこう。

三つのスイッチ種別、三つの経路

外部スイッチは仮想アダプターを物理 NIC に結び付け、ゲストは自分の MAC アドレスでその結び付けを通してフレームを送る。ゲストは物理ネットワーク上の対等な存在になり、独自の DHCP リース、ゲートウェイ、DNS サーバーを持つ。ホストの VPN 既定ルートはホストのスタックにあり、ホストを通してルーティングされるのではなくブリッジされるため、それらのフレームを動かさない。Wi-Fi アダプターの上に外部スイッチを置くのが悪い考えなのも同じ理由で、ほとんどの無線ドライバーは二つ目の MAC アドレスのフレームを運ばない。

内部スイッチはゲストをホストの仮想アダプターにつなぐ。それだけではインターネットへの出口がなく、変換はホスト上の NAT オブジェクトが担うが、その説明は Hyper-V の NAT ガイド にある。これでゲストのパケットは実際にホストのルーティングと NAT の経路に入るため、VPN クライアントの経路とフィルターが再び効いてくる。仮想マシンが本当にホストの VPN に従うのはこの構成であり、キルスイッチがゲストを完全に遮断できるのもこの構成だ。

プライベートスイッチにはホスト側のアダプターもアップリンクもない。ゲストは互いにだけ話し、他の何とも話さないので、プライベートスイッチ上の仮想マシンにインターネットがないなら、原因は欠けているルーターであり、VPN は無関係だ。

既定のスイッチはそれ自体が別の仕組み

Windows は内部スイッチに NAT と DNS プロキシを組み合わせた既定のスイッチを提供する。そのサブネットはホストが選び、再起動後に変わることもあり、自分で作る NAT ネットワークとは同じオブジェクトではない。これを実験用ネットワークのように作り直すと、NAT が二つになり、ゲストは依然として経路を持たない、という結末になりやすい。

仮想マシンが既定のスイッチ上にあるなら、ゲストが受け取ったアドレスを読み、VPN クライアントに触れる前にホストの NAT テーブルと比べる。ゲストのゲートウェイと NAT プレフィックスの食い違いは、クライアントのどの設定よりも多くの障害を説明する。

問いを決着させる四つの事実

何かを変える前に、スイッチの種類とアップリンク、仮想マシンに接続されたアダプター、ゲスト自身のアドレス・ゲートウェイ・DNS、そしてホストの NAT と既定ルートの状態を集める。読み取り専用のコマンドは Get-VMSwitch、Get-VMNetworkAdapter -VMName "TestVM"、Get-NetNat、そして Get-NetRoute -DestinationPrefix 0.0.0.0/0 で、ゲストの中では ipconfig /all が残りを教えてくれる。

次に、ゲストが何をすべきかを決める。VPN の外に置くべきなら、ホストの実行ファイルを除外しても転送される仮想マシンの通信は除外されないのだから、その経路ちょうどに対するプロバイダーのサポート対象の例外を取る。VPN を使うべきなら、ホストのブラウザーでの試験で足りると決めつけず、クライアントが仮想マシンの通信をどう扱うと文書化しているかを確認する。

ゲストの中での試験だけが意味のある証拠だ。ゲストから出口アドレスを確認し、内部名を解決し、VPN をつなぎ直して繰り返す。ホストのブラウザーの結果は、そのどれの代わりにもならない。

神話の代償

人は試験を通すためだけにキルスイッチを切り、静的ルートを足し、スイッチを消して作り直す。どの近道も故障の仕方を変え、ゲストが誰も意図しない経路でインターネットに出ることもあれば、外部スイッチが物理カードを結び直したときにホストが接続を失うこともある。

外部スイッチを結び直すとホスト自身のアクセスが途切れるので、帯域外の経路を開けたままにし、診断中にスイッチを消すのは避ける。正しい結果は、ゲストがどう再接続し、どう失敗するかを含めた意図した経路であって、一度のページ読み込みの緑のチェックマークではない。

長く効く答えは、台帳の仮想マシンごとに一行、どのスイッチを使い、どの構成要素がゲートウェイを供給しているかだ。それが書いてあれば、次の VPN 変更は午後いっぱいの推測ではなく、一回の照会で済む。