VPNアドレスとLANのDHCPリース：トンネルのIPは誰が配るのか

クライアントを接続し、Wi-Fiアイコンではなくアダプターを見る。10.80.0.14 のようなアドレスがトンネル上にありながら、オフィスLANのどのDHCPサーバーもそのリースを記録していないことがある。番号を選んだプロセスが、トラブルシューティングの開始点を決める。

クライアント側ではどれも同じに見える：IPv4アドレスが一つ、マスクが一つ、既定ゲートウェイがあることもある。違いが現れるのは、そのアドレスに誰が応答し、誰が記録を保持しているかを問うたときだけだ。

クライアント側からトンネルのアドレスを読む

最初の行ではなくブロック全体を読むと、Windowsは違いを示す。ipconfig /all はアダプターの説明、物理アドレス、DHCPの行を出力する。PPPやIKEv2のダイヤルアップアダプターは通常DHCPを無効と報告するのは、ダイヤル中にアドレスをネゴシエートしており、LANサーバーからリースしていないためだ。DHCPが有効なトンネルアダプターは珍しく、単独で調べる価値がある。

Linuxは同じ情報を二つのツールに分ける。ip -4 addr show dev tun0 はアドレスとプレフィックス長を返す。nmcli -f IP4 connection show work はその値が接続プロファイル、リンク上のDHCP交換、プッシュされた構成のどれに由来するかを示す。最も明確なのはWireGuardで、wg-quick がインターフェース出現時に構成ファイルの Address 行を適用し、接続時にピアが何も割り当てない。

プレフィックスも手がかりになる。/32、あるいは 255.255.255.255 のマスクは、ゲートウェイが単一のホストアドレスへルーティングする想定を示す一方、より広いマスクは、トンネルの先のどこかにリンク上のサブネットがあることを示唆する。

IKEv2構成ペイロードが運ぶもの

IKEv2にはこの作業専用の仕組みがある。RFC 7296 3.15.1節に記述された構成ペイロードは、INTERNAL_IP4_ADDRESS、INTERNAL_IP4_NETMASK、INTERNAL_IP4_DNS などの属性とそのIPv6版を運ぶ。クライアントは希望がない場合に長さゼロの属性を送り、応答側は使用してほしい値を返す。このやり取りはすでに暗号化されたIKE_AUTHの中で行われるため、DHCPブロードキャストがトンネルを越えることはない。

そこから二つの帰結が生じる。第一に、アドレスを選ぶのは応答側、または応答側が参照する認可バックエンドであり、だからこそプールはゲートウェイ上にも、RADIUS応答にも、IDプロバイダーのマッピングにも置ける。第二に、DNS属性はアドレス属性とは別である。10.80.0.14 を受け取っても、どのリゾルバーが返ったのか、そもそも返ったのかは分からない。

ネットマスク属性は実際には任意である。多くの導入はアドレスだけを返し、クライアントにホストルートを設定させるため、同じプールが、あるクライアントでは /32、別のクライアントでは /24 に見えることがある。

LANのDHCPスコープとVPNプールが衝突する場所

両方の割り当て元が同じ範囲を指すと問題が始まる。10.20.30.0/24 用のDHCPサーバーは、10.20.30.128/25 用に構成されたVPNプールを何も知らないため、ゲートウェイが同じアドレスを遠隔クライアントに渡している間に、そのサーバーが 10.20.30.140 をプリンターにリースするのを止めるものはない。衝突は何日も静かに続き、その後、断続的な重複として表面化する。

ルーティングされたサイト間設計は、構造上その衝突を避ける。支店のホストはローカルDHCPサーバーが与えたアドレスを保持する。両方のゲートウェイのトンネルインターフェースはそれぞれのリンクアドレスを持ち、パケットの経路はルーティングテーブルが決める。リモートアクセスクライアントのアドレスは第三のカテゴリであり、ゲートウェイのリンクアドレスと混在させるべきではない。

トンネルをLANにブリッジすると、その分離はなくなる。設計が本当に一つのブロードキャストドメインを必要とするなら、VPN端点は自分でアドレスを発行するのではなく、リレーや共有の権威ある情報源を通じて、DHCPサーバーと同じ割り当て判断に参加しなければならない。

どのプロセスがアドレスを所有するかを確認する

スコープを変える前に所有権を証明する。クライアントではアドレスとプレフィックスを控える。LANではリースデータベースを検索する。ゲートウェイでは配布するよう構成されたプールを一覧する。リースファイルに見つかったアドレスはDHCPサーバーのもので、トンネルはブリッジまたはリレーされ、ゲートウェイのプールにしか見つからないアドレスはトンネル端点のものだ。

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

答えが明確になったら四つを記録する：どのコンポーネントがクライアントアドレスを割り当てるか、そのためにどの範囲が予約されているか、戻りトラフィックがその範囲にどう到達するか、どのリソースがそれを受け入れるか。この四項目が、仮想アダプターの一行を運用上の事実に変える。

そこにいる間にDNS属性の確認も繰り返す。アドレスを配るがリゾルバーを配らないプールは、クライアントをローカルDNSに残すが、これは、LANがすでに使っているアドレスを配るプールとは別の障害である。