ESXi ゲスト VPN：ルーティングかブリッジかをポート グループの前に決める
ルーテッド TUN には戻りルートが、ブリッジ TAP にはレイヤー 2 の到達性とより広いポート グループ ポリシーが必要です。promiscuous モードを広げる前に役割を決めてください。
パケットをルーティングするか Ethernet ドメインを拡張するか——ポート グループの変更はその選択の下流にあります。プライベート アドレスを持つアプリケーションから見ると結果は同じに見えますが、ハイパーバイザー側の要件はまったく似ていません。だからこそポート グループが先に広げられ、設計の問いは後回しにされ、たいていはブロードキャスト ストームの後に答えが出ます。以下の確認を順に行い、要件が曖昧なうちに止めてください。選ばれなかった設計は、どのポート グループ設定でも直せません。
決定はサービスの所有者のものであり、ハイパーバイザーの構成はそれを実装すべきで、偶然に決めてはいけません。
遠端が実際に何を必要としているかを確認する
リモート クライアントが到達すべきサービスと、使うプロトコルを列挙します。既知のプレフィックス上の TCP サービスが数個なら、ルーティングで足ります。レイヤー 2 の隣接が本当に必要なもの——ブロードキャスト依存の検出、非 IP プロトコル、ゲートウェイを受け付けない機器——があれば、ルーティングでは代用できず、早い段階でそう言うべきです。その一覧の非 IP 項目について正直でいてください。ルーテッド設計が 一週間後に静かに失敗するのはそこです。
次にクライアント プールを確認します。ルーテッド設計にはアドレス範囲と遠端側の明示的な戻りルートが、ブリッジ設計には拡張 Ethernet ドメインがアドレス割り当てと分離を所有することが必要です。どちらを選んでも、この VM の外の誰かが同意しなければなりません。
各設計が仮想ネットワークに求めるもの
二つの設計は仮想ネットワークが耐えるべきものが異なり、表が最短の確認方法です。
| 設計 | ゲスト側の役割 | 仮想ネットワークが受け入れるもの | 誤って選んだ場合の障害モード |
|---|---|---|---|
| ルーテッド TUN | 別々のプレフィックス間のルーター | ルーテッド クライアント プールと遠端側の戻り経路 | クライアントはゲートウェイには届くが、その背後のサービスには決して届かない |
| ブリッジ TAP | 参加するクライアント向けのレイヤー 2 ブリッジ | 追加の Ethernet アイデンティティ、ブロードキャスト トラフィック、VLAN ルール | vSwitch がフレームを破棄する、または誰も承認していない promiscuous モードが必要になる |
ルーティングはブロードキャスト ドメインをそのままにし、どのサービスがゲートウェイを越えるかを制限する自然な場所を与えます。ブリッジは境界を動かします。クライアントは拡張 Ethernet ドメインの参加者になり、アドレス割り当て、分離、レイヤー 2 ポリシーが今度は彼らに適用されます。選んだ行を変更記録に書いてください。「ルーテッド TUN、クライアント プール 10.90.0.0/24、コア上の戻りルート」のような一文があれば、次のエンジニアがポート グループ設定から設計を蒸し返すことはありません。
誰が誰のフレームを見てよいか
ポート グループに触る前に、プラットフォームの所有者に一つ尋ねてください。この設計は、この VM が他の参加者宛てのフレームを受け取ることを要求していますか。答えがいいえなら、この節は何も当てはまりません。ルーテッド TUN はその可視性を決して必要としないからです。答えがはいなら、Broadcom の promiscuous モードに関するガイダンスが重要です。VM が vSwitch のどこまで見えるかと、そのポリシーを 一つのポート グループに限定することを勧めています。
これは許可証ではなく要件確認として扱ってください。ブリッジの必要性が文書化されたときに、専用の接続一つだけ設定をオンにし、他のすべてではオフのままにします。別のブリッジ例からコピーした広い VLAN トランクは、誰も外すのを覚えていない部分であり、単一 VLAN の設計は単一 VLAN のままであるべきです。
どのポート グループがなぜ変わったかを、設計の行を書いた同じ場所に記録します。この対が次の監査を可能にします。
ゲストのオブジェクトを明示的に保つ
Linux の中では、ブリッジへの所属とアドレスの所有は別のオブジェクトであり、混同すると中途半端に動く紛らわしい状態になります。アドレスはブリッジ インターフェイスかルーテッド トンネルに割り当て、同じ経路の両側には割り当てず、メンバー ポートは IP 設定のないままにします。
一つのサブネットを、ルーテッド TUN と無関係な Ethernet インターフェイスの両方に独立して置くのは避けてください。その構成は同じプレフィックスへの 二つの経路、非対称な応答、そしてどちらの経路にも触れない flapping のサポート スレッドを生みます。ゲストがコンテナーやローカル ハイパーバイザーもホストする場合は、すでに同じアップリンクへブリッジしていないか確認してください。一つの NIC 上の二つのブリッジは設計であり、変更ウィンドウ中に発見したい事故ではありません。
ping ではなくパケット経路で確認する
到達性だけでなく実際の経路を検証します。クライアントから、どの送信元アドレスが遠端のサービスに届くかを確認し、次に応答が同じ道で戻ることを確認します。ゲスト側では特定フローの転送カウンターを、ポート グループ側では選んだ設計が必要とする以上の可視性が有効になっていないことを確認します。
最後に障害の方向を試します。トンネルを止めるかクライアントを切り離し、未使用だと思っていたルーテッド経路へトラフィックが静かに落ちないことを確認してください。その落ち方が、ブリッジ設計が静かに意図しないルーターになる仕組みです。