2つの拠点にサイトVPN用の同じVLAN IDは必要か？

二つのオフィスでVLAN番号が同じならサイト間トンネルに役立つように感じられるが、トンネルが運ぶものは何も変わらない。VLAN IDは一つの建物内のEthernetブロードキャストドメインにラベルを付けるものであり、 トンネルはゲートウェイ間でIPパケットを転送する。二つの拠点がまったく異なるVLAN番号を使っていても互いにルーティングできるし、二つの拠点が同じVLAN番号を使っていても互いに到達できないことがある。到達性を決める変数はアドレス計画である。

神話：両端でVLAN IDを揃えること

この信念にはもっともな出発点がある。一つの建物の中では、同じVLANの二つのポートは通信でき、異なるVLANの二つのポートはできないので、VLAN番号が接続性を与えるものに見える。ルーテッドトンネルの向こうにはタグが記述する共有Ethernetセグメントはなく、ゲートウェイがVLANラベルを交換することもない。

トンネルに必要なのは、重ならない二つのアドレス範囲と、その間のトラフィックを許可するポリシーである。どのオフィスでVLANを変えてもトンネルは動き続ける。トンネルの設定のどこもそれを参照していなかったからだ。これが議論を決着させるテストである。VLANを再番号付けし、アドレスはそのままにして、トンネルが維持されるかを見る。

逆のテストも同じくらい示唆に富む。両方のオフィスに同じサブネットを与えても、VLAN番号をいくら揃えてもアドレスが一意になるわけではない。

トンネルが実際に運ぶもの

IPsecは、アドレス、プロトコル、ポートで表されるポリシーに従ってIPパケットを保護する。 IPsecアーキテクチャ は、スイッチのタグが記述するあらゆるものより数層上のIP層で、それらのセレクタを記述している。パケットがトンネルに入るときにはすでにVLANを離れており、タグはローカルスイッチによって消費されている。

ポリシーベースとルートベースの設計は、トンネルの選び方が異なるのであって、運べるものが異なるのではない。ポリシーベースのピアはトラフィックセレクタを照合し、一致するパケットをトンネルに送る。ルートベースのピアはトンネルインターフェースでトラフィックをルーティングし、判断をルーティングテーブルに委ねる。どちらも保護範囲を交渉するので、トンネルを指すルートがピアの合意した保護範囲を広げることはない。

この区別はよくある半端な失敗を説明する。ルートは存在し、パケットはトンネルに入るが、遠端がそれを破棄する。交渉されたセレクタにそのプレフィックスが決して含まれていなかったからだ。設定済みのポリシーを読めば、どの範囲が実際に有効になったかがわかる。

ip xfrm policy
ip route show
swanctl --list-sas

実際に壊れる重複

異なるサブネットを持つ二つのオフィスはトンネルを通じてきれいにルーティングされ、VLAN番号は無関係である。同じサブネットを持つ二つのオフィスはそうならない。特定のアドレスへの要求には二つの意味があり、ルーティングテーブルは一つしか選べないからだ。一方の拠点を再番号付けするのがきれいな修正であり、DNSとファイアウォールの変更を数えれば、通常は代替案より安い。

再番号付けが不可能な場合、意図的な変換設計によって各側に異なるアドレスビューを提示できる。それは一対一のマッピング、一致するセレクタ、変換されたビューを反映するDNSエントリ、書き換えを生き延びる戻りルーティングを意味する。実運用コストを伴うサポートされた設計であり、VLAN IDの変更が行うことではない。

両端のVLAN番号が同じなのは共有テンプレートの偶然であることがあり、その偶然を動くトンネルの原因とみなすと、後で何かが壊れたときに間違った変更に至る。

層ごとに一つの仕事を、文書にする

ローカルスイッチはどのポートがブロードキャストドメインを共有するかを決め、そのVLAN番号付けは他のどの拠点も知る必要のないローカルな帳簿である。ゲートウェイはピアを認証し、交渉された保護範囲を適用する。ルーティングテーブルは復号されたパケットが次にどこへ行くかを決め、アクセスポリシーはそのパケットをそもそも許可すべきだったかを決める。

こうした仕事を分けておくことが、変更を安全にする。一つのオフィスでのVLAN再番号付けは、ローカルスイッチ、DHCP範囲、場合によってはファイアウォールゾーンに触れるが、トンネルには触れない。プレフィックスの変更は、トンネルのセレクタ、両側のルート、アクセスポリシーに触れるが、スイッチのタグには触れない。

戻りルート、プライベートDNS、アプリケーションIDの要件もまた別の仕事であり、どれも他の拠点からVLAN番号をコピーして得られるものではない。到達可能なプレフィックスと許可されたサービスを列挙した設計文書はスイッチの更新を生き延びるが、VLAN番号を列挙した文書は生き延びない。

タグがトンネルに届くと仮定する前に、ブリッジツールでローカルの状況を確認する。

bridge vlan show
ip -br addr
ip route get 10.62.0.20

layer-2拡張が本当の要件である場合

拠点間でEthernetの挙動が本当に必要な設計もある。ブロードキャスト検出に依存するレガシーアプリケーション、マシンが移動する間もアドレスを保つ必要がある移行、layer-2の前提を埋め込むプロトコルなどだ。そうした場合はフレームを運ぶオーバーレイやブリッジサービスが必要になり、VLANメンバーシップ、ループ防止、障害処理がエンドツーエンドの問題になる。

それははるかに大きな障害ドメインであり、ファイル共有を動かそうとした結果の偶然ではなく、意図的な選択であるべきだ。普通のファイルサーバー、データベース、Webアプリケーションには許可されたIP経路が必要であり、その下に延伸したブロードキャストドメインがないほうが幸せである。

VPN契約は到達可能なプレフィックスと許可されたサービスとして書き、VLANラベルはローカル運用が必要とする場所にだけ記録する。そうすれば各オフィスは、あらゆる変更をトンネルの再設計に変えることなく、自らのスイッチングを再番号付けできる。