同じサブネットの二つのサイトが一つのLANにならない理由

二つのオフィスがどちらも 192.168.77.0/24 を使っていて、一つのネットワークにしようと誰かがトンネルを提案する。この言い方は単純に聞こえるが、三つの異なる設計、つまり衝突する二つの独立したLAN、WAN越しに意図的に延伸したイーサネットセグメント、そして遠隔アドレスに代わって応答するproxy ARPの構成を隠している。どれなのかによってホストがパケットをどう扱うかが決まり、その答えはVPNゲートウェイが関与する前に見えている。

ホストがルーターより先に決める

192.168.77.10/24 のアドレスを持つホストは、宛先を自分のプレフィックスと比較する。そのプレフィックスの内側にあるものはすべてオンリンクなので、ホストは宛先のリンク層アドレスを直接解決する。外側にあるものはすべてデフォルトゲートウェイへ送られる。

この判断はホストのスタックで行われ、トンネルの中ではない。ゲートウェイに追加したルートで、ホストがそこへ送らないパケットを救うことはできない。

したがって 192.168.77.20 が遠隔サイトにしか存在しない場合、ローカルのホストはそれをARPで問い合わせ、答えを得られない。VPNのハンドシェイクは完全に健全なまま、この部分だけが失敗する。症状はルーティングの問題ではなく死んだホストのように見える。この兆候を見抜ければ、トンネルのデバッグが一時間節約できる。

ARPはローカルリンクの問いである

ARPはこのリンク上でアドレスを所有するのは誰かを尋ね、その答えはブロードキャストを聞けるものから来なければならない。IPsecトンネルの反対側にあるルーターは、設計が二つのサイトを一つのブロードキャストドメインにしない限り、それを聞けない。

同じアドレスを持つ二つの機器はさらに悪化させ、解決が成功してもどちらが答えたのかは分からない。

アドレスの重複はルーティングの不具合ではなく、どんなルートでも直らない。サイトを別々のプレフィックスに再番号付けするか、意図的に一つのリンク層ドメインにするかのどちらかである。

延伸セグメントが運ぶのはフレームであり、ルートではない

ブリッジに接続されたイーサネットを運ぶトンネルは、二つのサイトを一つのリンク層ドメインの一部にする。ARPブロードキャストは反対側に届き、各ブリッジはどのMACアドレスがどこにあるかを学習する。Linuxブリッジのドキュメントが、そのMACベースの転送境界を説明している。

ここでは遠隔のゲートウェイは二つの同一サブネット間をルーティングしていない。フレームは自らIPをルーティングするアンダーレイを越え、ブリッジがイーサネットの会話を延長する。

代償は影響範囲の広さである。未知の宛先へのフラッディング、ループ、DHCPの割り当て、一意なアドレス指定のすべてに、両サイトをまたぐ一つの計画が要る。WANが落ちると、ホストはローカルだと思うトラフィックを失う。ブリッジ上のフィルタリングやVLANの規則で通過するものを制限できるが、それでもすべてのリンクローカルな制御フレームが届くことは保証されない。

proxy ARPは三つ目の設計である

ルーターは遠隔アドレスに対するARPに応答し、そこへルーティングできる。これにより、ブロードキャストドメインを延伸せずに、送信者から見て遠隔ホストがオンリンクに見える。

これはブリッジングより狭い道具であり、転送、戻りルート、そして各アドレスの明確な所有者に依存する。

任意の非IPプロトコルをルーティング可能にするものでもなく、イーサネットのブロードキャストドメインを再現するものでもない。要件がまさにその置き換えであるときに使い、先送りした再番号付けの近道として使ってはならない。

要件から選び、それから検証する

通常の拠点間アプリケーションアクセスには、別々のプレフィックスと明示的なルートのほうが明確な境界になる。要件が本当にリンク層の隣接性であるときにブリッジする。共有プレフィックスの唯一の理由がまだ誰もやっていないことなら、再番号付けする。

実際にどの設計なのかを確かめるには、ホストに宛先をどう扱うか尋ねる：

ip route get 192.168.77.20
ip neigh show 192.168.77.20

ネイバーエントリが失敗した状態でのオンリンクの結果は、リンク層の経路が欠けていることを示す。viaの結果はゲートウェイを名指しし、問いをルーティングへ移す。ブリッジでは転送データベースを見て、MACがトンネル越しに学習されたかを確かめる。どの出力も設計の問いを狭めるのであって、やり直しにはならない。