VPNをまたぐDHCP：ブロードキャストをブリッジするか、リレーするか

トンネルの向こう側に置いた新しいノートPCだけがアドレスを取得できず、同じノートPCは本社では問題なく動く。最初に疑いがちなのは、トンネルがDHCPを遮断しているという説だ。しかし実際には、ブロードキャストに経路がなかったことのほうが多い。未設定のクライアントは 255.255.255.255 に送信し、通常のIPルーターはそのパケットを転送しない。トンネルは、ルーテッドトンネルとして当然の動作をしているだけである。

これを変える設計は二つあり、両者は等価ではない。一方はブロードキャストを運び、もう一方は要求を中継する。

ブロードキャストはルーターを越えない

アドレスを持たないDHCPv4クライアントは、0.0.0.0 から限定ブロードキャストアドレスへ、UDPポート 67 と 68 で送信する。このパケットは設計上、自分のリンクにとどまる。これを転送するルーターは、配下のすべてのセグメントに洪水を起こすことになる。

つまり、ルーテッドのサイト間トンネルはリレーをサーバーに接続する。クライアントのブロードキャストドメインを広げるものではなく、ファイアウォールのルールでそうなるものでもない。

ブリッジしたトンネルが実際に広げるもの

意図的にブリッジしたVPNなら、対応するトポロジーの範囲でEthernetブロードキャストを運べるため、DHCPはローカルトラフィックとして通過できる。これは現実的な選択肢だが、レイヤー2の設計判断である。ブロードキャストと一緒に、障害ドメインとアクセス境界まで広げることになる。

ブリッジは、ブロードキャストストーム、ARPスイープ、悪意あるDHCPサーバーが届く範囲も変える。遠隔オフィスを同じスイッチにつながないのであれば、アドレスを配るためだけにトンネルをブリッジしてはいけない。有効にする前に、その影響範囲を試しておくこと。

アドレスを渡すより大きな判断であり、意識して決めるべきものだ。

代わりに要求を中継する

通常の答えは、クライアントのローカルネットワークに置くリレーだ。ブロードキャストを受け取り、ユニキャストの要求に変え、自分のアドレスをゲートウェイアドレスフィールドに入れる。サーバーはそのリレーアドレスに応答する。

例としての遠隔オフィスでは、リレーはオフィスのLANに置き、サーバーにはサイトVPN経由で到達する。そのオフィス向けのスコープ、リレーとサーバーの識別情報、完全な戻り経路を設定する。トンネルでUDP 67を通しても、サーバーにどのプールを使うかは伝わらない。

転送はするが応答を一度も受け取らないリレーは、たいてい戻り経路の問題だ。スコープを変える前に、リレーアドレスへの戻りルートを確認する。

DHCPをARPから、そしてトンネルのアドレスから切り離す

DHCPはUDP/IPの上を走る。Ethernetでは、ホストがARPを使って候補アドレスがすでに使われていないか確認することもある。この競合確認は独立したリンクローカルな処理であり、DHCPメッセージの転送経路ではない。DHCPは要するにARPだというのは誤りで、両者は無関係だというのは広すぎる。

VPNクライアントは、DHCPブロードキャストではなくVPNプロトコルやサーバー自身のプールからトンネルアドレスを得ることもある。名前にDHCPを含むオプションは、中継されたDHCPパケットではなく、プッシュされたクライアント設定を表していることがある。DHCPが関与していると決めつける前に、サーバーのプールを確認する。

受け取るネットワーク、割り当ての所有者、スコープ、リレーの有無、障害時の想定動作を記録する。そのうえで、そのモデルを通して新しいリースと更新を試す。二つの拠点が同じ未管理のプールを提供できるなら、最初の持ち運ばれるノートPCを待つ競合がそこにある。