OpenVPN 後に VMware のブリッジ接続ゲストがネットワークを失った

一時間前まではブリッジ接続で到達できていたゲストが、今はあらゆる通信でタイムアウトしている。誰もその設定を編集していない。ホスト側ではインターネットはトンネル経由で今も動いている。この二つの事実を合わせると、原因は VPN ではなくハイパーバイザー側にあると分かる。ホストとゲストが同じ経路を使わなくなっているからだ。新しい仮想アダプターが一つあれば、これだけで起きる。

変わったのはゲストではなくブリッジ

Windows に OpenVPN クライアントを入れると、トンネルが上がったときにサービスが束縛する仮想ネットワークアダプターが追加される。OS から見ればリンク状態を持つ普通のインターフェースで、多くの場合独自のアドレスも持つ。VMware がこれをブリッジ候補として扱うには、それだけで十分だ。

VMnet0 は既定で「自動」に設定されている。つまりハイパーバイザーはブリッジを作るたびにホストのアダプターを選ぶ。導入したばかりの仮想アダプターはその候補群に入り、選ばれてしまうと、ゲストが送出するすべてのフレームは物理スイッチポートではなくトンネルデバイスへ流れる。

ブリッジを固定するかゲストをルーティングするか

ゲストを物理 LAN の対等な一員にするなら、第一の分岐が正しい。ブリッジに選ばせ続けるのをやめ、アダプターを明示的に指定する。ゲストに社内トンネルを使わせたいなら第二の分岐で、その場合ブリッジは最初から正しい設計ではない。ブリッジ接続のゲストはホストの VPN ルートを引き継がないからだ。

これは先に決める。二つの答えは作業内容が違ってくる。順序を逆にすると、ブリッジすべきでなかったゲストに対して、正しく固定されたブリッジができあがる。

第一の分岐では、ホストで仮想ネットワークエディターを開き、VMnet0 を選び、「自動」を物理アダプターに置き換える。アダプターが複数ある場合は自動設定の一覧を使い、ゲスト通信を絶対に通してはいけないもののチェックを外す。OpenVPN の TAP または Wintun デバイス、そして Hyper-V、WSL、Docker、ループバックのアダプターだ。ノート PC では有線と無線の物理アダプターを両方チェックしたままにしておく。そうしないと、次にユーザーがドックに接続したときにゲストはブリッジを失う。

選択を決める三つの条件

ブリッジが適切かどうかは、ゲストを何に使うかで決まる。ゲストを LAN 上の独立したホストとして見せたい場合、独自のアドレスと独自の受信到達性を持たせるなら、ブリッジが正しいモデルで、固定がすべての修正になる。外向きの通信だけが必要なら、ホストオンリーか NAT のネットワークのほうが単純で、アダプターの入れ替わりにも影響されない。

ゲストにホストと同じトンネルを使わせるなら、ブリッジモードでも固定したアダプターでも解決しない。ゲストの通信はホストのルーティング判断に一切入らないからだ。その場合はホスト側にルーティングされた経路か変換された経路が必要で、アダプターの選択は無意味になる。

VMware Player の画面にはネットワークエディターがない。そのため Player だけを入れたホストでこの設定に到達するには、単体のエディターか Workstation のインストールが要る。この制約だけで方針が決まることもある。

結果はゲストの内側で読む

仮想 NIC を再起動するか、ゲストを再起動して、リースを要求し直させる。そのうえで、ホストが設定したつもりの内容ではなく、実際に受け取った内容を読む。

ipconfig /all
ip addr
ip route

その出力のうち二つのフィールドだけを読み、残りはいったん無視する。ゲートウェイは LAN のルーターであるべきで、アダプターの説明にはトンネルではなく VMware Ethernet デバイスが載っているべきだ。169.254.0.0/16 の自己割り当てアドレスは、DHCP サーバーが応答しなかったという意味で、トンネルアダプターに張ったブリッジはゲスト側からまさにこう見える。

ほかを変える前に、もう一つ区別しておきたい。ルーターには届くがインターネットには届かないゲストは、ブリッジは動いていて上流に問題がある。トンネルの範囲のアドレスを受け取っているゲストは、まだ間違ったデバイスにつながっている。TAP アダプターを無効にしてもどちらの解決にもならない。OpenVPN サービスがそれを必要としているからだ。