ブリッジ接続した拠点でもローカルなインターネット出口の決定が必要

VLAN 拡張の検証はきれいに通った。両拠点のホストは互いに見え、ファイル共有は動作し、プリンターも応答する。ところが小さい拠点の誰かが、すべてのダウンロードがもう一方の拠点のインターネット回線を使っていることに気づき、チケットは帯域の苦情として届く。ブリッジは求められたとおりに動いただけだ。二つの建物の間でフレームを運び、そのフレームがインターネットにどのルーターを使うべきかについては一切意見を持たなかった。

ブリッジはフレームを運ぶが、決定は運ばない

レイヤー 2 拡張は二つの拠点を一つのブロードキャストドメインに見せるため、ARP 要求、DHCP ブロードキャスト、同一サブネットのトラフィックがすべてトンネルを越える。それがこのサービスが提供するすべてだ。ブリッジの中では、宛先アドレスを検査することも、拠点のアップリンクと比較することも、より近い出口へトラフィックを誘導することもない。各クライアントは設定されたアドレスとマスクを使って、ローカルかリモートかの判断を今も自分で下す。

その共有サブネットにルーターを二台置けば、どちらももっともらしいゲートウェイになる。使うクライアントの近くにあるかどうかは関係ない。

クライアントがゲートウェイを選ぶ仕組み

RFC 1122 に記述された IPv4 の判断は単純だ。クライアントの接続サブネット内の宛先は ARP で直接到達し、その外の宛先は設定されたデフォルトゲートウェイへ送られる。だからこそ拠点間の同一サブネットのトラフィックはルーターの関与なしにブリッジを越えられ、インターネットのトラフィックはクライアントが受け取ったゲートウェイアドレスに完全に依存する。二つの挙動は独立しており、動作するファイル共有は最初の一つだけを証明する。

小さい拠点のクライアントが大きい拠点のルーターで設定されていれば、そのインターネットフレームはまずトンネルを渡り、そこから出ていく。

VPN アプライアンス自身のデフォルトルートを変えても、そのクライアントのゲートウェイは動かない。クライアントはアプライアンスをルーターとしては一切使っていないからだ。アプライアンスには、それらのフレームを運ぶトンネルを維持するために遠隔ピアへの別ルートも必要であり、この二つを混同することが、ブリッジ拡張が自らの通信路を落とす原因になる。

DHCP に意図した出口を表現させる

DHCP 応答のオプション 3 は、クライアントのサブネット上のルーターアドレスを優先順に並べたリストを渡し、クライアントは通常、最初に応答したものを取る。仕組みは問題ない。設計が狂うのは所有権のところだ。最も近い DHCP サーバーが最も近いゲートウェイを配ると仮定せず、各拠点で実際のリースが何を渡すかを記録しよう。

調整された割り当て機構を一つ、または同じポリシーに明示的に設定された二つを運用し、そのポリシーに所有者を決める。遠隔拠点に追加した二つ目の独立した割り当て機構はローカル性を生まず、同じブロードキャストドメインに二つの権限を生む。

両拠点の設定を同じに見せたいだけのために、一つのゲートウェイアドレスを独立に稼働する二台のルーターへ割り当ててはいけない。ブリッジされたセグメントをまたぐ共有仮想アドレスは、独自の要件を持つファーストホップ冗長化の設計であり、手作りの版は断続的なパケット損失に見える ARP 競合を生む。アプリケーションが共有レイヤー 2 セグメントを本当に必要としないなら、ローカルのデフォルトを持つ分離したルーティングプレフィックスのほうが運用が簡単で、障害時に説明しやすい。

四つの事柄を別々に検証する

一つの観察ではなく、四つの観察を求める。各拠点で新しい DHCP リースを取り、受け取ったルーターとマスクを記録する。もう一方の拠点で同一サブネットのサービスに到達し、経路がルーティングによる回り道ではなくブリッジであることを確認する。各拠点で公開インターネットから何かを取得し、どのアップリンクが運んだかを確認する。そしてトンネルを落として何が壊れるかを見る。ブリッジが失敗したときにすべての接続を失う拠点は、誰も気づかないうちに遠隔のゲートウェイに依存していたのだ。

その四つの結果から、拠点間ブリッジなのか、ローカル出口なのか、偶発的なバックホールなのかが分かる。集めるのに十分ほどかかる。

設計原則は地味だ。ブリッジが到達性を決め、DHCP がゲートウェイを決め、アプライアンスのルーティングテーブルがトンネル自身の経路を決める。この三つは別々の会話として扱うべきだ。すべてを直そうとする一つの変更は、たいてい二つを壊す。