VPN の専用アドレスに実際に応答しているのは誰か

組織の割り当ての中で未使用のまま置かれているアドレスはリスナーではなく、ファイアウォールに追加してもリスナーは生まれない。そのアドレスで IKE を終端する何かが必要であり、仕組みはゲートウェイがアドレスを保持するのか、上流の機器が変換するのかで変わる。両者を分けるのはパケットの経路であり、変更要求を誰かが起票する前に、どのプラットフォーム機能が必要かを決めるのもこの経路である。まず経路をモデル化し、それから選ぶ。

アドレスの背後にあるパケット経路

ピアは与えられたアドレスへ、UDP 500 で、NAT トラバーサルが関わる場合は UDP 4500 で IKE を送る。経路上でそのアドレスを持つ機器は、データグラムをローカルで受信して応答するか、どこか別の場所へ転送するかのどちらかである。可能性はこの二つだけであり、この記事の残りはすべてどちらが真かから導かれる。

ローカルで受信するとは、その機器上にそのアドレスへ束縛されたソケットが存在するということである。転送するとは、データグラムが書き換えられて別の端点へ送られ、その端点がソケットを持つということである。UDP 500 を許可するファイアウォール規則は、どちらが起きているかを何も教えてくれない。

何かに触れる前に、ピアが接続するアドレス、上流ネットワークがそれをどう届けるか、それを受信するローカルインターフェースまたは論理端点、そして IKE に応答するプロセスという記録を書く。四行であり、各行は検証できる。そのうち一つが不明なら、その不明点こそ設計作業であり、後で片づける実装の詳細ではない。変更要求の承認後にこれらを埋めるのが、変換規則を誤った機器に追加してしまう経路である。

モデル A: ゲートウェイがアドレスを保持する

第一のモデルではゲートウェイ自身が、既存インターフェース上のセカンダリアドレスとして、専用インターフェース上のアドレスとして、あるいはプラットフォームがトンネル端点として対応する loopback として、アドレスを保持する。これらは三つの異なる機能であり設定経路も三つに分かれ、一つに対応していても他に対応しているとは限らない。

その構成を前提に設計する前に、プラットフォームとリリースが正確にその構成に対応していることを確認する。ルーティングされたブロック、インターフェース上の追加アドレス、loopback 端点は互換ではなく、あるリリースの文書は次のリリースが同じ挙動をすることを約束しない。

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

待ち受けているソケットが証拠である。アドレスに何も束縛されていなければ、ルーティングテーブルが何と言おうとゲートウェイは終端者ではなく、パケットキャプチャには応答するもののないデータグラムが到着する様子が映る。

トポロジの別の場所にすでに存在するサブネットへ二つ目のインターフェースを置き、プラットフォームが何とかしてくれると期待してはならない。インターフェースのサブネットが重なると送信元の選択が曖昧になり、多くのプラットフォームでは設定自体を拒否する。

モデル B: 上流の機器が変換する

第二のモデルでは上流のファイアウォールが専用アドレスを保持し、トラフィックを別の VPN ゲートウェイへ転送する。これは戻り経路を伴う宛先変換であり、そのように文書化されている限り完全に妥当な設計である。

そうでないのは、上流の機器がローカルの VPN ソケットを得たという証拠である。変換はパケットを転送するだけで、上流の箱を IKE の応答者にはしない。上流の規則が削除されたり戻り経路が壊れたりすると、ゲートウェイが健全で自身のリスナーが無傷でも VPN は止まる。

両方のアドレス、つまりピアが接続するアドレスとゲートウェイが実際に見るアドレスを記録し、次にトランスポートと戻り経路も記録する。UDP 500 では機能するがカプセル化された ESP では機能しない変換は、接続したうえでトラフィックを運べず、後から調べるのが厄介な障害になる。

ID は外側のアドレスではない

IPsec はトンネル端点とそれが保護するトラフィックを分離し、アーキテクチャはそれらの判断を別々の場所に置いている。ピアが接続するアドレスを変えても、どの内部プレフィックスが許可されるか、どの経路が導入されるか、セッションがどのリソースに届くかは自動では変わらない。

認証された ID はさらに別である。IKEv2 は外側のパケットアドレスと一致する必要のない ID ペイロードと認証交換を運ぶため、変換された設計でも正しく認証できる。

この独立性は有用であり、同時に罠でもある。一つの通常のリスナーへ解決する二つの DNS 名が別々の VPN バックエンドを選ぶことはなく、一つの ID を示す証明書は別の ID を期待するピアを満たさない。アドレスだけで決まるとみなす前に、ピアが何を検証するかを確認する。

一つの接続を観察して設計を受け入れる

新しく認可された接続が実際にどこへ届けられるか、どの ID が応答するか、その後にどのプライベートフローが許可されるかを調べる。三つの観察、三つの異なる層であり、アドレスの公開照会が成功してもそのどれも試していない。

否定側のケース、つまり受け入れるべきでないピアや到達できるべきでない内部プレフィックスも、変更後に検証して残す。冒頭に書いた記録があるからこそ、設計を記憶から再構成せずにその試験ができる。

ここまでの要点は、ネットワークの所有者が、追加アドレスでどのファイアウォールが何をできるかという一般的な主張に頼るのではなく、対応済みの割り当て方法を選べるようにすることである。その主張こそ、どのプラットフォームでももっともらしく聞こえ一般にはどれでも正しくないために、こうした設計が誤る地点である。四行の記録が、あなたのプラットフォームについて十分で決着させる。