仮想マシンはホスト上で完璧に動く社内システムに到達できず、ホストはルーティング テーブルを所有するクライアント経由で接続されています。仮想アダプターをトンネルにブリッジする当然に見えますが、二つの別々の理由で失敗します。うまくいくのは、両方のマシンが所有するセグメントでの変換です。代償は現実で、すべてのゲストが社内ネットワーク上の固有の ID を失います。

ブリッジが機能しない二つの理由

クライアントのアダプターは通常ひとつのアドレスを持ち、多くの場合 /32 で、クライアントはホストのルートを書き換えて通常の外向きトラフィックがトンネルを優先するようにします。ホスト上のアプリケーションはそのテーブルに従い、プライベート システムに到達します。ブリッジされたゲストはテーブルをまったく読みません — フレームが IP 層より下のスイッチから出ていくからです。

トンネル アダプターをブリッジに入れれば理論上は経路が解決しますが、ドライバーは受け付けません。Windows 10 はブリッジ デバイスをひとつだけ許可し、ワークステーションが二つのサブネット間を転送できるルーティング ロールも与えません。残るのは送信元変換です。ゲストのトラフィックをホストから来たように見せれば、ホスト自身の判断がそれをトンネルへ運び、ゲストは持てないルートを必要としません。

ホストが所有するセグメントを作る

仮想ネットワーク エディターで、ほかではルーティングしないプレフィックス、たとえば 172.28.90.0/24 上に VMnet3 のようなホストオンリー ネットワークを追加します。ホストはそのアダプターで 172.28.90.1 を取り、ゲストは同じスイッチに接続します。そのセグメントでハイパーバイザーの DHCP を無効にし、アドレス サービスをひとつにします。

その上に何かを作る前に、Windows がインターフェイスを認識することを確認してください(設計全体がそのアダプターの普通さに依存します):

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

ホストオンリー アダプターはそこに物理アダプターと同じように現れます。何にも接続できないトンネル アダプターとの違いは、まさにそこです。

ゲストのプレフィックスを変換する

昇格したセッションを開き、プレフィックスを変換します。まず既存のものを確認してください — コンテナーのランタイムやハイパーバイザーは独自の変換をインストールしており、間違ったものを削除すると別の製品が壊れます。

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

次に、ゲストをそのプレフィックスの静的アドレス、ゲートウェイとしての 172.28.90.1、そしてトンネルがホストに渡すリゾルバー アドレスで構成します。変換はパケットを転送するだけで、ゲストに DNS を何も教えません — そのためローカル ルーターに置かれたゲストはパブリック名を解決し、内部名はすべて失敗します。

最初のホップを確認し、次にコストを確認する

最も近い境界を試すアプリケーションを試す前に。ホストのゲートウェイで止まるトレースは変換が起きていないことを意味し、ホストの先で止まるトレースはトンネルが落ちているか、相手側が変換されたアドレスを拒否したことを意味します。

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

トンネルが上がっている間に、同じ宛先へのホスト自身のアクセスと比較します。ホストが成功してゲストが失敗するなら、障害は変換かゲストのゲートウェイ設定にあり、接続にはありません。

そしてこの取引を受け入れます。社内システムはすべてのゲストをひとつのアドレスとして見るため、デバイス証明書やデバイスごとのポスチャー検査では区別できず、それを全面禁止するポリシーもあります。ドロップの挙動も決めてください — トンネルが失敗したとき、そのプレフィックスをホストのファイアウォールで遮断しない限り、変換されたトラフィックは通常のインターネット経路に落ちることがあります。

関連記事