ハブアンドスポークかフルメッシュか：あなたの拠点に合うVPNトポロジー
動くトンネルが二本あるだけではトポロジーになりません。ハブ、メッシュ、または直結リンクを少し加えたハブのどれを選ぶ前に、通過経路、障害時の挙動、変更コストを比較してください。
二つの支社オフィスが一日中互いに通信しており、その間のトンネルは別リージョンのデータセンターを経由して回り込んでいます。すべてのリクエストがその回り込みの代償を二重に払い、ファイル同期がおかしいと感じられるまで誰も気づきません。トポロジーの問いは、どの図がより耐障害性が高く見えるかではなく、どのトラフィックパターンに対して費用を払っているのかというところから始まります。どちらの設計も機能し、異なる形で、異なるコストで失敗します。
まずピア間の関係を数える
N拠点の場合、フルメッシュにはNにNマイナス一を掛けた数を二で割った本数のトンネルが必要で、ハブならN本で済みます。五拠点では十対五となり、まだ運用できるように聞こえます。十五拠点では105対十五となり、差はもはや算術ではなく人員の問題です。
そうした関係の一つひとつが、あなたが所有すべき状態を伴います。IPsecでは、セキュリティアソシエーション、アイデンティティ、鍵または証明書、デッドピア検出、そして遠隔プレフィックスごとに少なくとも一つのルートが必要です。WireGuardでは、ピアごとに公開鍵と AllowedIPs ブロックが必要で、ピア単位では安く済みますが、探索の仕組みはまったくなく、新しい拠点はいずれにせよ既存のすべての拠点での設定変更になります。
判断はトラフィックの混在に任せ、図に任せない
支社のトラフィックが主に中央のERPやファイルクラスタへのリクエストであれば、ハブは妥協ではなく、トラフィックはもともとそこへ行きたがっており、ポリシーの一点はペアごとのルールの網より監査しやすいため、正しい形です。メッシュは、二つのオフィス間のレプリケーション、拠点間の音声、十数人のエンジニアが一日中開くCAD共有のように、支社どうしがデータを交換するときにその複雑さに見合います。
扱いにくいケースはその中間にあり、しかも多数派です。組織図から推測するのではなく、議論の前に測定してください。
| シグナル | ハブを示す | メッシュを示す |
|---|---|---|
| 支社間トラフィック | 時々、小さい | 支配的、一日中 |
| 拠点数 | 増加、十を超える | 小さく安定 |
| 変更頻度 | 追加と移設が頻繁 | まれ |
| 障害耐性 | 二つ目のハブを用意できる | 各拠点が単独で生き残る必要がある |
表はルールではなく決め手として読んでください。四行のうち三行が同じ方向を指せばたいてい設計は決まり、割れている場合はハイブリッドで、成熟したネットワークの多くは結局そこに落ち着きます。
ハブには転送するよう指示が必要
機能しているスポーク・トゥ・ハブのトンネルが二本あっても、スポーク間のアクセスは生まれません。ハブにはIP転送の有効化、各スポーク網へのルート、通過を許可するファイアウォールルール、そして戻り経路の設計が必要で、各スポークには相手拠点のプレフィックスへのルートが必要です。Linuxのハブでは net.ipv4.ip_forward=1 に加えて FORWARD ペアを黙って落とさないチェーンが必要で、ポリシーベースのIPsecでは両端で遠隔スポークのサブネットを列挙するトラフィックセレクタになります。strongSwanの 転送に関する解説 は、そこが足りない層であるときにカーネル側とファイアウォール側を扱っています。安価なテストは、一方のスポークから他方のサービスへトラフィックを送り、ハブのカウンタを眺めることであり、決して増えないルールはルートではなく順序が間違っていることを意味します。
中央のポリシーも有用な部分です。支社どうしを到達させずに共有サービスへは到達させることはでき、そのアクセスマトリクスは明示的に書き留める価値があります。欠けたルートは、誰かが読めるルールの代わりにはなりません。
中途半端な版は、スポークAからハブ経由でスポークBへルートし、ハブは両方向にルートし、ハブのファイアウォールはAからの新規接続を許可するがBからは許可しないという状態です。最初の方向はうまく試せて二番目は止まり、これはルーティング障害に見えますが、そうではありません。
まず障害を設計し、その後に通常経路を設計する
単一のハブは共有された依存点であり通過のボトルネックであり、冗長化こそハブ設計がたいてい誤る場所です。二つのハブは各スポークが二本のトンネルを持つことを意味し、戻り経路は往路と一致しなければならず、一致しないとステートフルなファイアウォールが応答を落として、症状は開いてから死ぬ接続になります。大規模な配備ではこれを、静的プレフィックスではなくトンネル上のルーティングプロトコルで解決し、仕掛けは増えますが推測が消えます。どちらを選んでも、誰も試さない戻り側の半分こそ大事なので、戻り経路は往路の隣に書いてください。
メッシュはそのリスクを分散し、ある拠点のリンクが落ちても他が孤立しません。同時に、経路選択があなたを驚かせる場所も増えますし、アプリケーションのセッションは依然として経路変更を自力で乗り越えられません。
どちらの設計も、フェイルオーバーをまたいでTCPセッションを自力で維持しません。アプリケーションが再接続できないなら、トポロジーはあなたの問題ではありません。
変更コストで選び、その後にルートを検証する
ハブから始めるのがよく、間違えても安く済む側だから、トラフィックが正当化するペアには直結トンネルを追加します。そのハイブリッドは決断の放棄ではなく、多くの組織が一年以内に収束する設計です。大切なのは、直結リンクのそれぞれに明示された理由と所有者があることです。
そのうえで、一つの図ではなく二つの図を検証します。通常経路については、 traceroute 各拠点から各サービスプレフィックスへと確認し、ホップが図と一致することを確かめます。障害経路については、トンネルを一つ落として同じことを繰り返し、すべてが動いている間しか機能しないルートは設計されたのではなく設定されただけだと確認します。
両方の図をアクセスマトリクスと一緒に保管して拠点が増えたときに見直すべきであり、管理しているのは次の変更のコストであって現在の絵の美しさではありません。