strongSwan ESP-in-UDP：検出できる NAT がないとき

NAT 検出が見つけるのはアドレス変換であり、ファイアウォールの方針ではありません。NAT のないサイト接続でも、明示的な ESP-in-UDP の選択が必要になることがあります。

NAT 検出が答えるのは一つの問いだけです：途中でアドレスやポートが変わったかどうか。ファイアウォールが IP プロトコル 50 を許可するかどうかは答えません。変換がまったくないサイトゲートウェイでも、native ESP を落とす方針の背後にあることがあり、その要件は検出するのではなく設定しなければなりません。仕組みは ESP-in-UDP であり、これは判断であって、ひとりでに現れる代替手段ではありません。

検出はアドレス上の算術であり、ファイアウォールの探査ではない

IKEv2 は NAT 検出ペイロード を運び、そこには送信元と宛先のアドレスおよびポートのハッシュが入っています。各側は受け取った内容をローカルで見える内容と比較し、不一致があれば何かがパケットを変換したと分かります。その交換のどこにも、途中のルーターがプロトコル 50 を転送するかどうかを試すものはありません。

実務上の帰結は率直に述べておく価値があります。native ESP で動いていたトンネルは、新たに制限されたファイアウォールを自力で発見せず、次の試行はデータ段階で失敗し、IKE は成功し続けます。確立された IKE セキュリティアソシエーションと 保護された通信がないこと が表示され、これは有線でキャプチャするまでルーティング障害のように見えます。

したがってカプセル化は設定する接続の性質であり、ピアがネットワークの振る舞いから交渉して得る結果ではありません。

encap が交換をどう変えるか

現代の strongSwan 導入では、swanctl.conf を通じて管理され、接続上の encap = yes 設定が NAT 検出の交換に影響し、両方のピアが ESP に UDP カプセル化を使うようになります。保護されたパケットはその後 UDP の中を、通常はポート 4500 で流れ、両端がその取り決めに合意する必要があります。

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

その断片は実際の接続定義の内側に属するもので、完全なサイトプロファイルではありません。すでに運用しているピアアドレス、認証、child トラフィックセレクターは残してください；追加された一つのキーが変えるのは、保護されたデータがどう包まれるかであり、何を保護するかではありません。

strongSwan の NAT-traversal ガイド はこの振る舞いを説明しており、MOBIKE 使用時のポートフローティングとの相互作用も含みます。

自分のバックエンドに属する設定を使ってください

strongSwan には二つの設定バックエンドがあり、キーは両者で異なります。swanctl.conf 接続は encap を取り、従来の ipsec.conf 接続は forceencaps を取ります。一方のバックエンドのキーワードを他方に置くと、文句も言わずに読み込まれて何も変えない設定ができあがり、これはエラーよりも悪い結果です。

何かを編集する前に、実際にどのデーモンが動いているかを確認してください。多くのディストリビューションでは両方のファイルが存在し、一方は以前の移行の名残で、有効なのはサービスのユニットが起動するほうです。ファイルのタイムスタンプから推測せず、そのユニットを読んでください。ここでの五秒の確認が、何も読み込まなかった設定を何時間も試すことを防ぎます。

変更は接続の所有者を通じて適用し、管理された時間帯に関連付けを再確立してください。すでにインストールされた child は置き換えられるまで現在のカプセル化を保つので、ファイルの編集だけでは新しい取り決めが使われている証拠になりません。

包まれたデータを検証し、ポートだけを見ない

保護された通信が流れている間にゲートウェイでキャプチャし、それを strongSwan 自身の見え方と比較します：

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP は IP プロトコル 50 として現れ、UDP とはまったく似ていません。包まれた ESP は 4500 上の UDP データグラムとして現れ、そのペイロードは IKE ではありません。同じポート上の IKE 通信はカプセル化の証拠になりません；MOBIKE が IKE をそこへ移してもデータ経路は native のままなので、ポート番号ではなくペイロードを読んでください。

経路の MTU も念頭に置いてください。ラッパーはオーバーヘッドを増やし、native ESP を運んだ経路はパケットが大きくなると調整が必要になる場合があります。必要な ICMP 処理はすでに設計の一部であるはずで、カプセル化はその依存を取り除きません。

トンネル内の新しいアプリケーション通信が両端で包まれた ESP としてキャプチャに見え、内部サービスとその戻り経路がまだ機能しているときに、変更を受け入れてください。それ未満はファイル上で正しく見える設定にすぎません。

関連記事