IKE パケットの重複：欠けた遷移を見つける
繰り返される IKE リクエストはタイマー事象であり、診断ではありません。正しいバージョン識別子を伴う、開始側から応答までの証拠の連鎖を一つ組み立てます。
ログには同じ IKE リクエストが二度現れ、誰かがモバイル回線を指し、チケットは推測で閉じられる。その推測こそが神話である。再送されたパケットは一つのやり取りについての観測であり、回線の診断ではない。再送はそれ自体の規則を持つ正常な挙動であり、応答が遅いときには健全な経路でも現れる。インターフェースを疑う前に応答を追いかけよ。
神話：繰り返されるリクエストは一つの回線の損失を証明する
重複を生む原因は二つあり、どちらも犯人を名指ししない。要求側は応答を受け取らなかったためにリクエストを繰り返すことがあり、また捕捉点はスタックへの接続位置のせいで同じパケットを二度見せることがある。同じホストで入口と出口を見るタップは、一つのパケットを喜んで二つとして記録し、そのログを読む運用者にはやり取りの識別子なしに違いを見分ける方法がない。どちらを手にしているか言えるようになるまで、重複はタイマー事象として扱え。
二つのアップリンクは混乱を和らげるどころか悪化させる。ログの一行は一つのインターフェースを名指しするが、応答はもう一方から出たかもしれない。つまりメッセージ内のインターフェースはパケットが見られた場所を述べており、会話の形を述べてはいない。最初の問いが「どの回線が故障か」ではなく「どのやり取りを見ているか」である理由もそこにある。
再送が実際に語ること
IKEv2 では、再送 は次のように働く。応答が届かないとき要求側はリクエストを繰り返し、応答側は新しい応答を計算する代わりにキャッシュした応答を再送してよい。メッセージ識別子はそのやり取りに属し、同じ識別子を持つ繰り返しリクエストが新しい試行ではなくプロトコルの動作として認識できるのはそのためである。最初の試行は相関に送信元アドレスや開始側 SPI 以上のものを要することが多く、プラットフォーム自身のやり取り記録はパケット一覧より優れる。IKEv1 は別の識別子で別の規則に従い、最初のパケットの重複に関するベンダーの警告もバージョンによって同じ意味ではない。
つまり再送のタイムスタンプはタイマーが満了したことを告げる。どのホップが遅かったかは告げず、ましてや通信事業者が悪いとも告げない。これらは別々の主張であり、チケットで役に立つのは二つ目だけである。
実務上の帰結は、結論を出す前にやり取りを記録することだ。ローカルの受信アドレス、ポリシーが選んだ応答経路、ピアのタプル、やり取りの識別子を一か所に書き留めよ。記録を後から読むとき、それぞれが別の問いに答えるからである。
一つの連鎖としての四つの観測点
やり取りを四つの別々の見る場所ではなく、連鎖の四つの環として考えよ。環は証拠を保つか不明のまま残り、連鎖は記録された最も弱い環の分だけしか語らない。下の表はその目録であり、各位置が何を確定でき、何を手つかずで残すかを示す。
| 位置 | 提供できる証拠 | 開いたまま残すもの |
|---|---|---|
| 開始側が送信 | リクエストがこのホストを離れた | ピアに届いたかどうか |
| 応答側が受信 | リクエストが到着した | 応答が生成されたかどうか |
| 応答側が送信 | 応答がゲートウェイを離れた | 意図した経路をたどったかどうか |
| 開始側が受信 | やり取りが完了した | ポリシーが結果を受け入れたかどうか |
連鎖はアクセスがある場所だけ埋め、残りは推測せず不明と記せ。一つの機械でパケットを記録するフックは、遠端の機械が何を受け取ったかについては何も語らず、リクエストが見られたというログ行は応答がかつて出た証拠ではない。正直な空欄は、推測で組み立てた完全に見える記録より役に立つ。
最初の欠けた遷移を見つける
連鎖を開始側から外へたどり、証拠のない最初の環で止まれ。ゲートウェイがリクエストを一度も記録しないなら、障害はその手前の経路にある。ゲートウェイが同じリクエストを繰り返し記録する一方でクライアントが応答を一度も記録しないなら、疑わしいのは戻りの方向である。送信元アドレス、変換、そして管理下の各境界でのフィルタリングを見よ。応答が届いてもクライアントが進まないなら、問いは輸送を離れてポリシーや状態になっている。
比較する間はピアとプロトコルを固定し、遅延・損失・ポリシー・状態がそれぞれ別の時間軸を生むことを忘れるな。モバイル網が自動的に原因なのではなく、固定回線がすべての要件に対して自動的に十分信頼できるわけでもない。やり取りが生きているうちに両方向を捕捉せよ。
tcpdump -ni any -vv 'udp port 500 or udp port 4500'アクセスが遠端の手前で終わる場合でも、どこで終わるかを記せば記録は役に立つ。開始側だけで捕捉すれば、リクエストが出て応答が来ないことを示せ、障害をそのフック以降のすべてに絞り込める。どのホップが落としたかを知っているふりをせずに。遠い環は不明と記し、アクセスを持つ次の人に埋めさせよ。そう書けば記録は正直なままで、しかも短い。
何かを変える前に比較せよ。同じピアへ同じプロトコルで同じリクエストを繰り返せば変数を数えられるが、捕捉の間のリセット、鍵更新、ポリシー編集は比較を破壊する。変更が避けられないなら、直後にもう一度捕捉し、前と後が同じやり取りを語るようにせよ。
役に立つ報告が語ること
行動に値する報告は、一つのリクエストをその応答と対にし、背後に証拠のない最初の段階を名指しする。その一文は一週間後にその場にいなかった技術者が読んでも持ちこたえ、次の人に容疑者ではなく出発点を与える。
再送の理論を確かめるためだけに、本人確認を弱めたり許可プロトコル集合を広げたりしてはならない。リセットの前には元のパケットとイベント記録を保存せよ。リセットは、これから集めようとしていた素材そのものを破壊し、やり取りがどこで止まったかを示すタイミングを消してしまう。
神話は、一つの重複が通信事業者の過失を証明するというものだ。現実は、一つの重複がタイマーの満了を証明し、答えは応答経路の上にある。