パケットキャプチャで最初の IKEv2 交換を読む方法

セッション途中から取ったキャプチャが IKEv2 のトレースを雑音に見せる通常の原因です。記録を始めた時点で、両側はすでに鍵を更新しているか、暗号化されたペイロードを交換しています。 代わりに新しい接続試行から始めてください。そうすればファイルの最初のメッセージが交渉を開くメッセージになります。以下の読み順はそれを前提にしており、パケットが遠端について何も証明しなくなる地点を示します。この手順を飛ばすと、正常なトンネルがブロックされたポートと診断されます。

最初の交換を見ていることを確認する

IKEv2 の交渉は IKE_SA_INIT、交換タイプ 34、メッセージ ID 0 で始まります。開始側は非ゼロの SPI を選び、応答側の SPI はその最初の要求ではゼロ、応答では非ゼロになります。この三つの事実が、新しい試行と鍵更新、あるいはキャプチャの先頭にたまたま居る IKE_AUTH メッセージを切り分けます。

ヘッダーのフィールドは読めますし、プロポーザル、鍵交換、nonce のペイロードも読めます。読めることは認証済みであることを意味しません。この時点でどちらの側も身元を証明しておらず、Diffie-Hellman の秘密値は決して回線に現れません。

デコードペインをスクロールするのではなく、フィールドを表として出力してください。再送や SPI の不一致が列で一目で分かります。

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

出力は対で読みます。メッセージ ID 0 の要求の後に、同じ ID と非ゼロの応答側 SPI を持つ応答が続けば一つの交換です。要求が再送されて三回現れても同じことです。同一の要求が三つあっても三回のログインではなく、そう扱うからこそ、単に辛抱強いだけのクライアントがループしていると結論づけられます。メッセージ ID、次にタイムスタンプで並べれば、会話全体は短い試行リストに縮みます。

成功を読む前に拒否を読む

応答は自動的な前進ではありません。応答側は cookie 通知で答えて開始側に再試行を求めたり、代わりに受け入れるグループを示す INVALID_KE_PAYLOAD で答えたりします。どちらも正しい形の IKE メッセージとして届き、パケットを数えるだけのフィルターにはどちらも完了した交換に見えます。

通知ペイロードを開き、何よりも先に種類を読んでください。cookie チャレンジは、応答側が偽装された送信元アドレスから身を守っているという意味で、クライアントは cookie を付けて再送する必要があります。無効なグループは二つのプロポーザルが一致していないという意味で、片側の設定が動くまで何度再試行しても変わりません。

暗号化された身元と認証ペイロードを運ぶのは、二番目の交換である IKE_AUTH だけです。したがって完了した IKE_SA_INIT が示すのは、両側がアルゴリズムと導出鍵で合意したということであり、資格情報が受け入れられるかについては何も示しません。そこでもメッセージは二つあり、セッション鍵なしではどちらも不透明です。

ポート 4500 は一つのプロトコルではない

通常、最初の交換は UDP 500 が運びます。NAT 検出が走ると IKE は 4500 に移り、各メッセージの前に四バイトのゼロの非 ESP マーカーを付けます。同じポート上のカプセル化 ESP はむしろ非ゼロの ESP SPI で始まり、一バイトの NAT keepalive は他に何も起きていないときに現れる第三の形です。

ポートだけに一致するフィルターは三つを混ぜてしまいます。だから「4500 にトラフィックがある」だけではほとんど何も決まりません。遠端について結論を出す前に、プロトコルで表示を分けてください。

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

無音は観測点を語る

応答のない要求が確立するのは正確に一つです。そのキャプチャ点では応答が現れなかった、ということです。フィルタリング、応答を別の場所へ送る経路、到達できない応答側、プロポーザルを好まない応答側のいずれも同じ空の結果を生み、汎用の UDP プローブでは区別できません。

ICMP 到達不能は別種の証拠です。その中に引用されたパケットを読み、どの機器が出したのかを特定してください。ルーターの管理的な拒否は、遠端からの認証されたエラーではありません。

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

同じ試行を、読むことが許されている範囲でサーバー側のログと突き合わせてください。要求は届いたのか、サービスは答えたのか、答えはどこで止まったのか。この三つの答えが、経路の問題かポリシーの問題かを教えてくれますし、資格情報を四度目に回すより安く済みます。