LAN アドレスを持つ VPN クライアントは LAN 上にいない

クライアントは接続し、10.50.0.200 を受け取り、同じ /24 にあるのに 10.50.0.20 のサーバーへ到達できない。この設定の背後にある思い込みは、LAN プレフィックスのアドレスを与えればクライアントが LAN の一部になるというものだ。そうはならない。クライアントはポイントツーポイントのリンク上にあり、サーバーは宛先をローカルとみなし、欠けているのは誰も送っていない隣接応答である。

神話: 同じプレフィックスは同じセグメントという意味

アドレスプレフィックスは、ホストが直接到達できる宛先とルーターが必要な宛先を告げる。宛先が物理的にどう接続されているかは告げず、宛先がリンク層の要求に応答できる保証もない。それらは別の問いであり、ホスト上の別の表が答える。マスクは前者に、隣接テーブルは後者に答えるが、VPN 側から制御できるのは前者だけだ。

サーバーが 10.50.0.200 へ送るとき、宛先を自分のマスクと比較し、そのアドレスを on-link と判断し、所有するハードウェアアドレスをローカルセグメントに問い合わせる。その要求は Ethernet インターフェースから出ていくが、VPN クライアントはそこにいない。

クライアントの設定で自分の側からこれを直すことはできない。応答経路は、LAN 上の機器がクライアントの代わりに応答するか、クライアントがサーバーのローカルとみなさないアドレスを持つかにかかっている。

ローカルホストは実際にアドレスで何をするか

挙動は観察しやすく、何かを変える前に観察する価値がある。クライアントへ到達しようとした後の LAN ホストの隣接テーブルを見れば、不完全または失敗したエントリが一行で診断そのものになる。その行は、障害がセグメント内のローカルなもので、トンネルのどこかではないことも示す。

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

ルート検索は Ethernet インターフェース経由で宛先を on-link と報告するが、それがまさに問題だ。VPN セッションが稼働している間に隣接エントリが不完全なままなら、欠けているのはリンク層の解決であり、ルーティングやファイアウォールポリシーではないと確認できた。

別のサブネットのホストから同じ確認を行い、比較する。ルーター経由でクライアントに到達するホストは隣接エントリをまったく必要とせず、その違いが縮小版の設計判断である。

proxy ARP が次のホップを提供する仕組み

proxy ARP は、別のインターフェース経由で到達できる宛先の代わりに、ゲートウェイがリンク層の要求へ応答する。LAN ホストはハードウェアアドレスを受け取り、フレームをゲートウェイへ送り、ゲートウェイはパケットを VPN セッションへ転送する。ホストから見れば、クライアントは単にゲートウェイの背後にいるように見える。クライアントの設定は何も変わらない。

MikroTik の RouterOS ARP ドキュメントは、接続された LAN のアドレス空間を借りるダイヤルインクライアント向けの用途を説明している。この仕組みは隣接解決の修理であり、ゲートウェイが本当に両方の経路上にいるから機能する。

これはクライアントを LAN へブリッジすることとは違う。ゲートウェイは依然としてパケットを正しいアクティブセッションへ転送する必要があり、ルーティングとファイアウォールポリシーは依然としてサービスを許可する必要がある。proxy ARP が変えるのは隣接要求に誰が応答するかであり、誰が話せるかではない。

プラットフォームのモード名を注意深く読む。RouterOS は proxy-arp と local-proxy-arp を区別し、後者は同じインターフェースを出入りするトラフィックを扱う。両者は入れ替え可能な表記ではなく、無差別に両方を有効にすることは近道ではない。

proxy ARP が与えないもの

ブロードキャストやマルチキャストによる検出は提供しない。ブロードキャストでサービスを見つける必要があるクライアントは、ゲートウェイがユニキャストをセッションへ転送し、クライアントを LAN のブロードキャストドメインの一員にしないため、依然として失敗する。ブロードキャストに依存する検出プロトコルは、借用アドレス設計で「片方には効くが他方には効かない」という報告のよくある原因である。

アドレスを予約しない。借用した番号が DHCP プールや静的割り当てにもある場合、二台の機器が同じアドレスになり得て、結果の挙動はタイミング次第である。ログインの成功は予約ではない。

また、LAN の所有者との調整の必要性をなくしはしない。アドレス計画の所有者を驚かせる proxy ARP エントリは、静かな週を待つサポート案件である。

別途ルーティングされたプールとの比較

代替案は、VPN クライアントに独自のプレフィックスを与え、LAN ホストにそこへのルートを持たせることだ。するとサーバーはゲートウェイへ off-link の応答を送り、ゲートウェイはプレフィックスを VPN エンドポイントへルーティングし、LAN セグメントでは隣接解決がまったく不要になる。借用アドレスと proxy 応答より可動部品が少ない。

その設計は、クライアントの範囲が LAN の範囲から目に見えて分かれているため、考えやすく監査しやすい。代償はルート一本、戻り経路、アクセスルールであり、proxy ARP 設計が見えにくい場所で必要とするものと同じである。

モデルは偶然ではなく意図して選ぶ。proxy ARP は特定の関係を一つ修復し、ルーティングされたプールはその修復を不要にする。どちらを選んだか、なぜかを書き残せば、次の人は失敗した隣接エントリから再発見せずに済む。