ESPは正常に復号しているのに、内側のパケットはどこにも届かない

ESPの受信カウンタは増え、トンネルは上がったままなのに、アプリケーションにはパケットが一切届きません。復号は実行され、整合性検証も通り、そのうえで受信側は保護されたペイロードが実際に何なのかを判断しなければなりませんでした。書式の不一致が現れるのはまさにこの最後の段階で、外から見るとファイアウォールの問題とはまったく似ていません。

ラベルが嘘をつくときに見えるもの

クライアントのログには、これをルーティングのブラックホールと区別できるものは何もありません。どちらも健全なトンネルのそばでアプリケーションのタイムアウトを起こすため、まずカウンタが疑われます。

受信カウンタが増えているのは本当に良い知らせです。パケットは届き、認証も通っています。しかしそれは、暗号層より上の何かにとって内側のパケットが意味を成していた証拠にはなりません。

種別はトレーラに住んでいる

通常のIPsecトンネルモードでは、ESPで保護されたペイロードには完全な内側のIPパケットが入っています。トレーラの次ヘッダフィールドがそのペイロードの正体を示しており、それはTCPポートでも、外側ヘッダのプロトコル番号でも、先頭のSPIとシーケンス番号フィールドの一部でもありません。 RFC 4303 第2.6節 はこれをペイロード種別フィールドと定義しています。正確な仕事に対する正確な名前です。

出会う値はどれも小さく、覚えておく価値があります。IPv4は4（0x04）、IPv6は41（0x29）です。

これらの番号はローカルの慣習ではなく、IANAのプロトコル番号割り当てに由来します。IPv4と宣言しながらIPv6パケットを包んでいる送信側は書式の不整合を生んでおり、自分のラベルに反するバイトを直せるファイアウォール規則はありません。

よくある容疑者と見分ける方法

失われるパケットのほとんどは符号化の欠陥ではありません。 まずセレクタを確認する。IPv6プレフィックスを除外するトラフィックセレクタは、何かがカプセル化される前に通信を落とします。次にルーティング、その次に受信ホスト側のローカルフィルタを確認します。これらを除外してはじめて、ペイロード書式の不一致が筋の通った説明になります。

暗号化されたキャプチャでは決着しません。保護された次ヘッダは暗号化されたペイロードの内側にあるからです。実装の診断機能か、サポートされた復号済みの観測点が必要で、どちらも使用前に許可が要ります。

その証拠を誰も出せないなら、書式のバグではありません。理論があるだけで、セレクタのほうがまだ本命です。

修理ではないもの

通信を通すために整合性チェックを無効にしないでください。中間ルータで暗号化パケットを書き換えないでください。動くはずがなく、キャプチャでは役立ちそうに見えてもフローを壊します。ポートが塞がれているという推測でアプリケーションのファイアウォール規則を広げないでください。どれもラベルの不一致には触れていません。

確認済みの不一致が相手実装に由来するなら、最小限に無害化した再現を残し、その実装のサポート窓口に持ち込んでください。

カウンタではなくフローを検証する

修正後は実際のIPv6フローを端から端まで試します。トンネルを通るアプリケーションの要求、その応答、そして双方が観測するアドレスの組です。ESPカウンタの増加は、パケットが受信され認証されていることしか証明しません。内側のパケットが使えたかどうかは何も語りません。

両方の結果をチケットに記録します。カウンタの動きと機能するフローがそろって修正であり、カウンタの動きだけであれば始める前と同じ状態です。