トランスポートモードかトンネルモードか：図ではなくパケットで決める

教科書の図はトランスポートモードを二台のホストに、トンネルモードを二台のゲートウェイに結びつけますが、その経験則はそれを破る最初の配備までしか持ちません。モードが表すのは ESP パケットが何を包むかであり、誰が両端かではありません。ゲートウェイがトランスポートモードで通信を保護することも、ホストの組が望めばトンネルモードを使うこともできます。三つの問いが、特定の配備に何が必要かを決めます。

モードは配置であり、トポロジーではない

トランスポートモードでは ESP ヘッダーが IP ヘッダーの後、次層のペイロードの前に来るため、元の IP ヘッダーは外側に残り見えます。トンネルモードでは保護される内容は完全な IP パケットで、新しい外側のヘッダーが二つの IPsec ピアを名指しします。

機密性を選ぶと、トンネルモードで保護される領域にはその内側の IP ヘッダーも含まれるため、キャプチャーは鍵なしで本当の端点を教えてくれません。外側のヘッダーはどちらの場合も読めるままで、それこそがトラブルシューティングを可能にします。

問い一：ESP の内側に正確に何があるか

アプリケーションが作るパケットを見て、どの境界がそれを保護するかを問います。答えがすでに正しい二つのアドレス間のトランスポートペイロードなら、二つ目のヘッダーを発明せずにトランスポートモードが合います。保護する内容が独自のアドレスを必要とするなら、本当の端点が通信を運ぶピアと異なるため、トンネルモードがその役を果たします。どちらの場合も同じ組織に存在するので、一つのポリシー記述で全体を覆えることはまれです。

その問いはキャプチャーとルーティングテーブルから答えられます。箱をクライアントとサーバーと書いた図からは答えられません。どちらかのピアで取ったキャプチャーは、二つのどちらを見ているかを数秒で示します。

問い二：内側にすでにトンネルがあるか

L2TP がその点を示す歴史的な反例です。サービスは L2TP セッションの内側で PPP を運び、IPsec がそのやり取りを保護します。配置はトランスポートモードを指定し、トンネルモードは選択肢として認められています。目に見える結果はサービス水準のトンネルで、その外側の保護はトランスポートモードを使います。

したがって製品説明にトンネルという語があっても、その下の層のモードについては何も言えません。どの問いがそれを決めたかを記録してください。次のレビュー担当者も同じことを尋ねるからです。名前から推論せずその組み合わせの仕様を読む習慣が、製品が何を支えるべきかをめぐる議論の大半を防ぎます。

問い三：ピアは何を要求するか

二つのピアは合意しなければならず、一方が一つのモードを提示し他方が二つ目を要求する提案は、静かに劣化するのではなく交渉の途中で失敗します。遠端の所有者にポリシーがどのモードを名指すかを尋ね、文書の要約ではなく提案そのものを確認してください。

混在する環境はよくあり、一つのゲートウェイが旧製品向けのトランスポートモードのセッションと、拠点間リンク向けのトンネルモードのセッションを終端します。モードはデバイスごとではなく関連ごとです。機能名ではなく関連の一覧を求めてください。名前は設定より速く伝わるからです。

存在する関連を読む

レビューのために、ピア、モード、セレクター、次層のプロトコルを列挙し、その結果の周りに巻かれたカプセル化があれば加えます。アドレス変換は独自の外側の見え方を加えるものであり、モードではなく、変換されたフローもどちらかであり続けます。一覧は、関連を意図ではなく実際に導入された姿で示す唯一の成果物です。

最後にルーティングと認可の問いを置きます。正しいパケット配置は、どのサブネットが許されるか、戻りの経路があるかを何も教えてくれません。それらはポリシーとルートテーブルにあり、どちらもモードについての議論を変えません。