あなたの VPN プールは LAN の DHCP 範囲ではない: なぜ壊れるのか

ルーテッドトンネルはイーサネットセグメントではない。LAN と重ならないプールを選び、クライアントが到達しようとする前に LAN に戻り経路を与えること。

魅力的な近道は、VPN クライアントにオフィスの DHCP サーバーが使うのと同じ範囲からアドレスを渡すことだ。どうせ全部ひとつのネットワークだという理屈である。そうではない。ルーテッドトンネルは二つの端点の間でユニキャストパケットを運ぶが、LAN のプールは物理セグメント上でブロードキャスト要求に答えるために存在する。番号を再利用すれば、二人の割り当て者が一つのアドレス空間を握ることになり、戻り経路は未定義のままになる。

二人の割り当て者、一つのアドレス空間

LAN の DHCP サーバーは、どのアドレスをどの MAC アドレスに貸したかを把握し、ARP で守っている。VPN サーバーは自前のプールを持ち、その貸し出しを何も知らない。どちらも間違っていない。ただ一度も引き合わされたことがないだけだ。

VPN サーバーが LAN のプールから配るアドレスは、すでにプリンターのものかもしれない。すると同じプレフィックス上で二台の機器が一つのアドレスを主張し、スイッチの転送テーブルがどちらが答えるかを決める。

それが人が最初に出会う故障だ: 接続は成功するのに、その後で間違ったマシンに届く、あるいは正しいマシンに断続的にしか届かない。

ルーターが VPN アドレスを配らない理由

DHCP の検出はブロードキャストであり、ブロードキャストはルーテッド境界で止まる。設計がトンネルをブリッジするか、権限の一致する DHCP リレーを動かさない限り、クライアントの要求が LAN のサーバーに届くことはない。

だから VPN サーバーが自分でアドレスを割り当てる: サーバー設定内のプール、WireGuard 構成におけるピアごとのアドレス、あるいは IKEv2 導入で認証層が押し出すアドレスだ。これらの仕組みは LAN の貸し出しデータベースとは独立しており、まさにそのために独自の範囲が要る。

同じ理屈で、DHCP スコープを変えてもアドレスを一度も受け取らない VPN クライアントは直らない。クライアントは LAN のサーバーに問い合わせておらず、スコープをどう編集しても問い合わせるようにはならない。

重複は遅いネットワークではなく競合として現れる

対応する設計なしにプレフィックスを共有する二つのネットワークは、二重所有とは別の問題であり、しばしば混同される。VPN プールが別のプレフィックスなら、重複が問題になるのは経路がトラフィックを誤った側へ送るときだけだ。プールが LAN のプレフィックス内にあれば、競合は即座かつ局所的になる。

実際には、誤った機器からの ARP 応答、途中でリセットされる接続、自分のアドレスを他人に主張されるクライアントを見ることになる。どれもルーティングの問題には見えないので、修正は誤った層に当てられる。重複した貸し出しは確認は容易で、付き合うのは厄介だ。再起動をしても消えない。二人の割り当て者が同じアドレスを主張し続けるからだ。

戻り経路は別の問題だ

きれいで別個のプールがあっても、LAN のホストはクライアントにどう答えるかを知る必要がある。既定ゲートウェイはルーターであり、ルーターにはプール用の、VPN サーバーを指す経路が要る。設計が代わりにクライアントのトラフィックを変換する場合を除く。

何かを変える前に経路を両方向から読む。ゲートウェイでは、カーネルがクライアントのアドレスにどのインターフェースを使うかを問う。クライアントでは、LAN のアドレスにどの経路を使うかを問う。

次のコマンドはゲートウェイでの転送判断と、重複を露見させる近隣エントリーを示す:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

最初のコマンドがトンネルのインターフェースで答えれば、戻り経路は存在する。LAN のインターフェースで答えれば、ルーターはクライアントが有線側にいると信じ、そのために ARP を試みる。

ブリッジ型の設計は存在するが、選ばなければならない

トンネルを LAN にブリッジするのは実在する設計で、クライアントがブロードキャストを受け取る必要があるときや、一つのセグメントを前提とするプロトコルに発見される必要があるときに使う。サーバーがそのブリッジ動作と、それに伴うアドレス処理を備えていることが条件だ。

うまくいかないのは、番号を写して結果を真似ることだ。ブリッジのない共有プールは、発見なしに競合だけを与える。両方の配置のうち最悪である。

アプリケーションが本当にセグメントを必要としない限り、別個のプールで第三層を選び、プールを文書化して、次の管理者が整理のつもりで DHCP 範囲を再利用しないようにする。

関連記事