IPsec ESP：何を運び、流れていることをどう証明するか
ESP はトンネルモードで内側の IP パケットを包み、SPI でそのアソシエーションを識別する。状態を読み、次に一つのフローがカウンタを動かすのを確認する。
ESP は IPsec VPN でトラフィックを運ぶが、その手順書は一つの原則、すなわちポリシーを変える前にセキュリティアソシエーションを読むことから始まる。説明のつかない ESP の挙動の多くは、一致しなかったセレクタ、読まずに前提としたモード、または一つのフローを流している間に誰も確認しなかったカウンタにさかのぼる。以下の三つの手順は、何が何を運んでいるかを確定し、一つのフローがそれを使っていることを証明し、記憶に依存しない切り戻しを残す。各手順は書き留める価値のある観察を一つ生む。
読む前にフィールドを知る
ESP は保護するデータの前にヘッダを、後ろにトレーラを置く。ヘッダは、受信側がどのアソシエーションを使うべきかを識別するセキュリティパラメータインデックス、再生を検出するためのシーケンス番号を運び、トレーラには暗号のためにペイロードの整列を保つパディングが入る。トレーラの次ヘッダフィールドは保護された中身が何かを示し、それによって受信側は何を脱カプセル化したかを知る。
モードはその保護の内側に何が入るかを変える。トンネルモードでは保護されるのは完全な内側の IP パケットであり、新しい外側のヘッダが二つの端点の間でそれを運ぶ。トランスポートモードでは、保護は既存のパケットの上位層ペイロードを包むので、開くべき二つ目の IP ヘッダは存在しない。どちらのモードを使っているかは設定の事実であり、解釈の問題ではない。図から推測せず、状態のエントリから読むこと。
どちらのモードも、パケットを届けるために必要な外側のアドレス指定を隠さないが、それは設計の性質であり欠点ではない。だからこそ、ペイロードが不透明でも、中間の観察者はどの二つのアドレスが話しているかを見ることができる。
手順一：状態を読み、次にポリシーを読む
状態のエントリは鍵とカウンタを保持し、ポリシーのエントリはそれを使ってよいものを決めるセレクタを保持する。Linux ではどちらもパケットキャプチャなしで見え、この順に読むことで二つの問いが分かれたままになる。
ip xfrm state
ip xfrm policy状態の出力では、アソシエーションの送信元と宛先、モード、そしてカプセル化が UDP ポートを示すかどうかを確認する。 そのポートは NAT トラバーサルが使われていることを意味する、これは中間のファイアウォールが何を許可すべきかを変えるが、端点でどのセレクタや鍵が適用されるかは変えない。
次にポリシーのセレクタを読む。テストしているトラフィックより狭いプレフィックスを指定するセレクタは、動いているトンネルがフローを無視しているように見える最も一般的な理由であり、誤ったプロトコルのセレクタも同じ沈黙を生む。
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
ベンダーのツールは同じ情報をより扱いやすい形で出力する。 ipsec statusall strongSwan では子アソシエーション、そのセレクタ、バイトカウンタが一覧され、どの子を見るべきかがすでに分かっているなら、生の xfrm 出力を読むより速いことが多い。
手順二：一つのフローがカウンタを動かすことを証明する
カウンタは、何が動かすはずだったかを知っていて初めて意味を持つ。だからセレクタが確実に覆う送信元と宛先を選び、無害な要求を一つ送り、そのうえで同じエントリをもう一度読み、比べる。
ip -s xfrm state
tcpdump -ni any esp二つの読み取りは異なる物語を語る。送出側では増えるが受信側では決して増えないパケットは、カプセル化されて出ていったのだから、鍵ではなく転送や戻り経路の問題を指す。 どのカウンタも動かないなら、トラフィックはポリシーに一度も一致していない、そして見るべき場所はセレクタである。
同じ手順でのキャプチャは、外側のパケットが ESP か UDP でカプセル化された ESP かを含め、回線上のカプセル化を裏づける。また、実際にフローを運んだアドレスも示すが、それは読んでいた設定のものと違うことがある。
手順三：一つだけ変え、切り戻しを残す
何かを編集する前に、アソシエーションの送信元、宛先、モード、セレクタ、カウンタを記録する。変更が状況を悪化させたとき、その記録があれば、推測から動く設定を作り直すのではなく、以前の状態に戻せる。記録には一分かかり、後で一時間を節約する。それは、変更を行った人の後にも残る唯一の成果物でもある。
セレクタかパラメータを一つ変え、再読み込みし、同じフローに対して手順二を繰り返す。アソシエーションを削除するとそれを使うすべてのフローが壊れるので、狙った編集と子の再読み込みは、何が起きるかを見るために状態を消すより、ほぼ常に良い。
セレクタ編集の切り戻しは、以前のポリシーを復元して再読み込みすることであり、セレクタがローカルではなく交渉される場合は相手側にも対応する変更が要るかもしれないという但し書きが付く。その依存は新鮮なうちに書き留めること、半分だけ戻した組はどちらの最終状態よりも考えるのが難しいからだ。
最後に、範囲を正直に保つ。流れている ESP アソシエーションは、二つのゲートウェイがセグメントを保護し届けていることを証明するが、その上のアプリケーションが利用者を認証しているか、保存するものを暗号化しているかについては何も言わない。それらは別の証拠を持つ別の統制であり、手順書は次の人が記録から繰り返せて初めて完成する。