二つの IPsec ピア間のルーターに IPsec は必要か？

「二つの拠点間に IPsec を設定せよ」と言うラボ演習は、二つの異なる作業を隠しています。両端がトンネルを終端し、ネゴシエーション、認証、暗号化、復号を行います。途中のどのルーターも、外側ヘッダーが両端に属するパケットを転送するだけで、トンネルの存在を知りません。

どちらの作業を装置に求めているのかを見極めることが演習の第一歩です。ラボレポートの混乱の多く、そして本番構成図の混乱のかなりの部分は、「IPsec をサポートする」を 二つではなく一つの性質として扱うことから来ます。

転送は終端ではない

トンネルモードでは、外側の IP ヘッダーはトンネルを終端する装置に宛てられます。中間のルーターは宛先を調べて転送し、他のあらゆるパケットとまったく同じに扱い、それが運ぶペイロードはルーターにとって不透明です。

この不透明さは意図的です。ルーターは相手の秘密を保持せず、ネゴシエーションも行わず、ポリシーデータベースも必要としません。必要なのは遠端への経路と、パケットを転送する許可だけです。

両者を混同すると、本当の要件が特定のアドレス間でプロトコル 50 を許可することなのに、通過ファイアウォールに「IPsec を許可」と頼んだり、鍵もないのに中間装置が検査のために復号すると期待したりする実際の誤りにつながります。

中間装置がそれでも正しく行うべきこと

転送には独自の要件があります。経路は両方の外部端点に到達する必要がありますし、経路上のあらゆるポリシーは推測したポート番号ではなく実際の外側トラフィックを許可しなければなりません。誰かが TLS を前提にしたために TCP 443 に対して書かれたルールは、プロトコル 50 には一致しません。

ネイティブ ESP は IP プロトコル 50 です。TCP 50 でも UDP 50 でもなく、TCP 以外のトラフィックを遮断するルールはそれを落とします。設計が UDP カプセル化を使うなら、見えるトランスポートはカプセル化ポートに変わり、ポリシーは選んだ設計に合わせる必要があります。

パケットサイズも重要です。小さなプローブを通す経路は、カプセル化された交換の全体が収まる証明にはなりません。大きなパケットを落とす経路では、ネゴシエーションが成功してワークロードが失敗する可能性があり、アプリケーションの問題に見えます。トンネルを責める前に、実際のワークロードと同じサイズのトラフィックで試してください。

シミュレーターが問いを変える理由

シミュレーターは機能一覧が短いルーターではなく、文書化された部分集合と、ある装置に何をさせる設定ができるかについての独自の規則を持つモデルです。Cisco の Packet Tracer の FAQ は、装置とプロトコルが簡略化されたモデルであると明言しています。

そこで問いは 三つの問いになります。シミュレートされた装置はシナリオに必要なパケットを転送するのか。同じ装置はレッスンが前提とする設定面を備えているのか。そして受け付けたコマンドは、挙動が本当にシミュレートされているのか、それとも構文解析だけなのか。

存在しないコマンドは、設定の誤りではなくモデルの限界かもしれません。存在するコマンドは、すべての本番挙動を再現せずに構文だけを受け付けることがあります。どちらに結論するにせよ、インストール済みバージョンの装置ヘルプを確認してください。

ラボの合格条件を書く

アンダーレイのレッスンでは、合格条件は端点への到達性と、外側パケットが中間装置を通過することです。シミュレーター自身のカウンターかパケット表示で証明し、期待するプロトコルを名指ししてください。

IPsec のレッスンでは、ネゴシエーション状態と保護された LAN 間フローを 一本加えます。シミュレーターがセキュリティアソシエーションを表示するなら記録します。表示しないなら、トンネルを検証したと示唆する代わりにレポートにそう書いてください。

シミュレーターのバージョン、選んだ装置、学習目標をトポロジファイルと一緒に残します。その記録があってこそ、他の人が演習を再現し、どの部分がモデル化されたのかを理解できます。

本番設定には独自のプラットフォーム証拠が必要です。緑のシミュレートされたパケットは教育の結果であり、これから配備するハードウェアの互換性声明ではありません。