TCP 上の IKE 4500：ポート規則の前に両端を確認する
TCP カプセル化は両端が交渉するもので、ファイアウォール規則が与えるものではありません。リスナー確認、キャプチャ、四つの受け入れ段階を順に実行してください。
サポートチケットは、ファイアウォール変更がすでに承認済みなのにトンネルが依然として上がらない状態で届くことが多い。片側だけに機能がある場合、これが想定される結果だ：RFC 9329 の TCP カプセル化は両端で実装・設定する必要があり、保護されたトラフィックが流れる前に接続の中で合意が成立する。ポートを開けることは、存在しないかもしれないリスナーを宣伝することであり、反対側に一致する設定がないリスナーは接続を受け入れてから沈黙する。以下の順序では、安価な確認を最初に置いている。
そのオプションが実際に何を追加するかを知る
ネイティブ IPsec は暗号化されたペイロードを次のように運ぶ：IP プロトコル 50、許可すべきポート番号はない。NAT トラバーサルはそれらのパケットを UDP でポート 4500 に包むため、多くのファイアウォール規則がそのポートに触れる。RFC 9329 はストリーム表現を追加する：IKE と IPsec のパケットはどちらも一つの TCP 接続の中を、通常はポート 4500 へ流れる。
ストリームはウェブサービスではない。4500 への TCP 接続は HTTP、TLS、プロキシとの相性について何も語らず、経路上の HTTP プロキシは通常、運ぶのではなくフレーミングを壊す。
ファイアウォールに触る前の事前確認
標準は TCP を UDP 経路を落とすネットワーク向けの代替として位置づけており、その置き換えではない。各ベンダーから二つの事実、つまり機能の正確な名称と、独自仕様ではなく RFC 9329 を実装したバージョンを得る。IPsec over TCP のようなラベルは無関係な設計に使われてきたので、文書の参照と有効化する設定キーを求めよ。両方の答えがなければ、ワイヤ互換性について何も仮定してはいけない。
両端が自分のもののラボで証明する。TCP 4500 に応答するが IKE を完了しないゲートウェイは、反対側に対応するカプセル化がないリスナーの兆候であり、変更ウィンドウ中に発見するよりはるかに安く済む。
応答側：何かが待ち受けているか
ソケットから始める。ss -ltnp | grep 4500 は TCP リスナーが存在するか、どのプロセスが所有しているかを示す。行がなければ、調査はネットワークではなくゲートウェイ設定で終わる。
ソケットがあれば、クライアント側から推測せずにハンドシェイクを観察する：tcpdump -ni any 'tcp port 4500'。三者間ハンドシェイクが完了して沈黙が続くなら、ストリームは受け入れられて内部の IKE 交換が失敗している一方、応答のない SYN はフィルタリングか誤ったアドレスを示す。
両者を混同しないよう、同じキャプチャウィンドウで UDP 経路と比較する：tcpdump -ni any 'udp port 4500 or proto 50'。TCP が使われていると信じているのにプロトコル 50 や UDP ポート 4500 にトラフィックがあれば、両端が代替について合意していない。可能ならゲートウェイでもキャプチャせよ（クライアント側のキャプチャは遠端が何を送ったかを示せないからだ）。
四つの別々の段階で受け入れる
立ち上げを四つの結果として扱う。それぞれ別の理由で失敗し得て、単一の合否ではどれだったかが隠れるため、失敗した最初の段階で止まり、上からやり直す。
| Stage | What you check | What it proves |
|---|---|---|
| 1 | TCP connection established to 4500 | A listener exists and the path permits it |
| 2 | IKE_SA authenticated in the gateway log | Both peers agreed on the encapsulation |
| 3 | CHILD_SA installed, visible with ip xfrm state | Keys exist for the protected traffic |
| 4 | A new application exchange succeeds | The data path works, not just the control path |
飛ばされがちなのが第四段階だ。既存セッションはキャッシュされた状態で動き続けることがあるので、変更を閉じる前にゲートウェイ背後のホストへ新しい接続を開く。第二段階が失敗して第一段階が通るなら、不一致は提案かカプセル化設定にあり、ファイアウォールではない。
ロールバックと、有効なままにするコスト
変更の前に元に戻す手順を計画する。両端でカプセル化オプションを切り、トンネルが UDP で戻ることを確認する。代替が再び必要になる場合に備えて TCP 規則を一回のレビューサイクル残し、その後削除する（4500 の未使用リスナーは運用価値のない攻撃面だ）。
実際の作業を運ぶようになったら性能の兆候に注意する。TCP の中の TCP は単一の損失で止まる確認応答の層を追加し、一つの接続を共有するストリームは互いをブロックし得るため、ping ではなくトンネルを使うアプリケーションを測定する。
受け入れチェックリスト
両端の機能名とバージョン、応答側のリスナー、ハンドシェイク完了を示すキャプチャ、タイムスタンプ付きで記録した四段階を確認する。次の技術者が TCP がなぜあるかを知れるよう、変更記録に代替の理由を加える。必要になる前にロールバックを練習する。
いずれかの段階が失敗したら、その段階だけを直す。輸送の問題を追って暗号スイートや ID 設定を変えると、通常は最初の上に無関係な二つ目の障害を加えることになる。