LAN ホストが OpenVPN クライアントのアドレスに ARP を送る理由

LAN ホストと VPN クライアントの間の到達性の問題は、多くの場合アドレス計画そのものにさかのぼります。そのホストに 10.0.100.0/22 のインターフェースを与えると、10.0.100.0 から 10.0.103.255 までのすべてのアドレスを直接接続と見なし、10.0.101.0/24 に静かに置かれたクライアントプールも含めます。応答がルーターに渡ることはなく、ホストから見ればルーターは関与していません。パケットは隣接ホスト宛てに送られ、ワイヤ上で問い合わせられます。

この仕組みの背後には一連の報告があり、トンネルは確立し、サーバーには経路があり、それでも LAN ホストはクライアントに到達できません。

/24 を飲み込む /22

プレフィックスは文字列ではなく範囲として読みます。/22 は 1024 個のアドレスを含み、10.0.100.0/22 は 10.0.100.0 から 10.0.103.255 に広がるため、10.0.101.0/24 のプールは完全にその内側にあります。この誤りがレビューを通過するのは、プールの最初のオクテットが LAN の最初のオクテットと違って見え、包含関係を明かすのは 三番目のオクテットだけだからです。両方の範囲を数字で書き出してから、別物だと宣言してください。

同じ包含関係は逆方向にも現れます。現在誰も使っていないために空きに見えるプールでも、どこかのサイトルーターが広告するプレフィックスの内側に収まることがあり、アドレス計画だけがそれを示す文書です。

直接接続とは ARP であり、ルーティングではありません

/22 インターフェースを持つホストが 10.0.101.25 に送ると、カーネルは宛先をインターフェースのプレフィックスと比較し、一致を見つけます。パケットはルーティングされる代わりに隣接探索になり、イーサネットでは隣接探索がそのアドレスへの ARP 要求です。そのアドレスがルーティングされたゲートウェイの背後の VPN クライアントに属するなら、LAN 上のどのホストも所有していないため、要求は無応答のままとなり、パケットは破棄されます。トンネルに落ち度はなく、クライアントはその通信を決して見ません。

だから障害は非対称に見え、ときどき断続的になります。VPN ホストは自身の経路が正しい方向を指すため LAN に届くことが多い一方、LAN ホストは応答できず、古い ARP エントリをキャッシュするものはすべて症状をちらつかせます。

TUN、TAP、そしてそれぞれが運ぶもの

TUN デバイスは IP パケットを運び、TAP デバイスはイーサネットフレームを運びます。ルーティングされた TUN リンクは IP 到達性を提供するために ARP を運ぶ必要がなく、上の無応答の要求が故障ではなく想定内である理由はまさにそこにあります。意図的なブリッジを伴う TAP はブロードキャストドメインを拡張し ARP を機能させられますが、クライアントが見えるものを変え、同じフレーミングを支える端点を要求し、重複するプレフィックスの修理ではなくネットワークモデルの再設計になります。アドレス計画の誤りを治すためにルーティング構成を TAP に切り替えるのは、小さな問題を大きな問題と交換することです。

結論を出す前に、ARP 要求がどこで現れ、どのシステムが送ったのかを記録してください。送信側が語るのは宛先についての認識であり、トンネルの動作ではありません。

重複し得ないプールを設計する

接続されたすべてのプレフィックスと広告されたすべてのサイトプレフィックスの外側でプールを選び、次に双方向で到達可能にする経路を追加します。計画の未使用部分にある 10.8.0.0/24 のような範囲は考えやすく、そこへ到達する必要のある LAN は VPN サーバーを指す静的経路を受け取ります。割り当て、広告する経路、許可する送信元アドレス、ファイアウォール規則を四つの設定ではなく一つの設計を表しているのだから、まとめて変更してください。

サーバー上の Source NAT はプールを LAN から経路可能なアドレスの背後に隠せますし、正当な移行手段です。ただし送信元も書き換えるため、LAN は接続を個々のクライアントに帰属させ、クライアント単位の規則を適用する能力を失います。

受け入れでは、実際のクライアントに割り当てられたアドレスと、LAN ホストからの実際のアプリケーション要求を使い、応答がワイヤではなく計画したゲートウェイに従うことを確認してください。