拠点とラボをつなぐルーテッドVPNかブリッジLANか

支店から自宅ラボへ到達させる方法は二つあり、その違いは設定ではありません。別々のプレフィックス間をルーティングすれば各サイトは自分のブロードキャストドメインを保ち、二つのLANを一つにブリッジすればブロードキャストと検出トラフィックは全員が同じ部屋にいるかのように振る舞います。ルーティングは実在のネットワークとの接触に耐える設計です。ブリッジは最初の一週間を簡単にし、最初の障害を興味深くする設計です。以下の比較はそれぞれが何を与え、何を犠牲にするか、そしてルーティング版をどう検証可能にするかについてです。

接続の二つの方法、一つの明白なトレードオフ

ルーテッドリンクは自宅ラボを独自のアドレッシングを持つ遠隔ネットワークとして扱います。支店はラボのプレフィックスを要求し、トンネルがそのパケットを運び、ラボのゲートウェイが自分のサブネットから応答します。支店のARPテーブルは何も変わらず、ラボのDHCPスコープも支店には届きません。

ブリッジリンクは一つのレイヤ2ドメインを両サイトに広げます。検出プロトコルは機能し、機器は自動的に現れ、すべてのブロードキャスト、ARP要求、マルチキャストパケットがトンネルを越える候補になりますが、それはローカルセグメント向けに作られたプロトコルが運ぶ大量のトラフィックを、MTUが異なり往復時間が変動するWANに載せることになります。

ルーティングが与えるもの

第一の利点は影響範囲であり、ループ、望ましくないDHCPサーバー、ブロードキャストの洪水は、それを生んだサイトの中に留まります、ルーターはブロードキャストを転送しないからです。第二はアドレッシングの明確さです。支店のプレフィックスとラボのプレフィックスは別なので、パケットの宛先を見ればどちらのサイトが答えるべきか分かり、ファイアウォール規則は「どこからでもどこへでも」ではなく「支店からラボのサブネットへ」と書けます。

第三は、トンネルが実際に運ぶものと一致する点です。IPsecポリシーはプレフィックスの組であり、両側の転送経路はゲートウェイで転送を有効にした通常のIPルーティングです:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

手放すのはブロードキャストによる検出です。これは現実の損失であり、すべてをブリッジして回避するのではなく、意図的に置き換えるべきものです。

ブリッジのコスト

ブリッジはレイヤ2フレームをトンネル越しに運ぶ必要があり、これは単純なポリシーベースのトンネルではなく、IPsec上のGREやVXLANといったカプセル化を意味します。それが存在すると、二つのサイトは一つの障害ドメインを共有します。スパニングツリーはトンネルをリンクと見なし、ブロードキャストトラフィックはトンネルの帯域を食い、低遅延のセグメントを前提とする機器はどちらの端からも原因を特定しにくい形で誤動作します。

また、あなたを正直に保つアドレッシングの検査も失われ、単一のフラットなプレフィックスでは、重複アドレスはルーティングの誤りではなく、互いのトラフィックを静かに盗み合う二台のホストです。支店とラボのプレフィックスが重なるのは自宅ラボではよくあることで、ブリッジはその衝突を解決せず、分散させます。

セキュリティの論点が決め手になることが多いです。ブリッジはリンクローカルプロトコルが動くセグメントを広げるので、支店の機器が外部から到達できるはずのなかったラボの機器と話せてしまいます。ラボにハイパーバイザー、ストレージコンソール、管理インターフェースが同じフラットなネットワーク上にあるなら、それはいま支店と同じ一つのセグメントです。

ブロードキャストなしの名前解決

ブリッジする理由はたいてい検出であり、プリンター、メディア機器、一覧に決して現れないラボのホストが対象です。ルーティング側の答えは名前サービスです。ラボのホストを支店のリゾルバーが到達できるゾーンに公開し、利用者にはネットワークをスキャンするのではなく名前で接続してもらいます。これは最初は手間が増え、その後の変更のたびに手間が大きく減ります。

マルチキャスト検出はより難しいケースで、精度が要ります。mDNSのようなプロトコルはリンクローカルマルチキャストを使い、ルーターは既定では転送しないため、検出一覧に出てこないラボのホストでも、文書化されたアドレスでは到達できるかもしれません。特定のサービスが本当にマルチキャストを必要とするなら、LAN全体をブリッジするのではなく、その一つのプロトコルだけをリフレクターや的を絞った転送規則で設計してください。

リフレクターも無償の勝利ではありません。避けようとしていたおしゃべりなトラフィックを、サービスごとに一つずつ持ち込み、機器が以前より多く広告し始めたことに気づく所有者が必要であり、サービスごとに選んで理由を書き留めてください。どのサービスがそれを必要とし、何を広告しているかを記録してください。ファームウェア更新は誰にも告げずにその一覧を変えうるからです。

ルーティング設計を検証可能にする

一つの目標を選び、たとえばラボのウェブインターフェースを専用のサーバーサブネット上で、両方向に証明します。支店のホストからアドレスと待ち受けサービスをローカルで確認し、次にトンネル経由で接続して繰り返します。トンネルが上がっていることはゲートウェイの合意を示すだけで、ホストのファイアウォールや戻り経路については何も示しません。

ラボの通常のゲートウェイには支店のプレフィックスへの戻り経路が必要であり、設計が意図的に送信元を変換しない限り、またサーバー自身のファイアウォールは許可された遠隔範囲を受け入れる必要があります。どちらも成功したトンネルでは設定されません。strongSwanの転送に関する注意書きは、両側で機能する必要があるパケット経路を説明しています。

次に拒否される宛先も試してください。アプリケーションを一つ必要とする支店の利用者に、ハイパーバイザーのコンソールは必要ありません。ポリシーが本物かどうかを知る唯一の方法は、拒否されるべきものを実際に試すことであり、プレフィックス、リゾルバーへの依存、試験結果を記録しておけば、どちらかのサイトの将来の変更は、記憶から作り直すのではなく数分で見直せます。