プライベート WAN は IPsec トンネルの外側パケットを運べるため、ピアアドレスはパブリックなインターネットアドレスである必要はありません。変わるのは、その外側パケットが通る経路と、それを受け取るインターフェース上の許可です。SRX では、外側の制御経路、トンネルインターフェースのバインド、転送トラフィックのポリシーは三つの別個のオブジェクトです。ほかの二つが誤っているのに片方だけを切り分けるのが、トンネルがダウンしたままになる通常の原因です。

まず外側の IKE 経路を記録する

ポリシーに触れる前に四つの値を書き留めます。ピアアドレス、IKE を受け取るローカルインターフェース、ピアに到達するルーティングコンテキスト、そのインターフェースを選ぶルートです。IKE パケットは SRX 自体宛てなので受信ゾーンで host-inbound の許可が必要であり、転送トラフィックのポリシーではなく、プライベート WAN アドレスでもパケットが依然として装置で終端するためこの要件は消えません。

インストール済みの状態は次で確認します:show security ike sa、設定は次で確認します:show configuration security ike。最初のコマンドはフェーズ 1 が存在するかを、二つ目は装置がどう動くべきと考えているかを示します。

トンネルインターフェースを正しいポリシーにバインドする

ルートベース VPN はトンネルインターフェースを VPN オブジェクトにバインドし、保護対象プレフィックスはそのインターフェースへルーティングされます。どのインターフェース、どのルート、どのポリシーが関連ゾーン間のアプリケーションを許可するかを記録します。trust という名前のゾーンはポリシーの入れ物であり、名前は必要な制御パケットやデータパケットが許可されていることを証明しません。

古い図ではなく実際のバインドを読みます:show configuration security ipsec vpn はインターフェースへのバインド設定、show configuration security policies はトンネルゾーンを参照するルールです。

保護対象のルートが別の場所を指していると、トンネルはアップしていてもトラフィックが決して入りません。これは IPsec の衣装を着たルーティングの問題です。

ピアルートは underlay 上に保つ

外部ピアへのルートは underlay を経由して解決される必要があり、確立したトンネルを再帰的に通ってはいけません。ピアルートがトンネルインターフェースを指すと、IKE パケットが自分のトンネルを追いかけ、フェーズ 1 は決して完了しません。保護トラフィックの戻り経路には独自の正しいルートとポリシーが必要で、片方向だけが動くときは通常そこが欠けている半分です。ピアアドレスのルートテーブルエントリを読み、出力インターフェースが WAN インターフェースであることを確認します。

次で確認します:show route 198.51.100.10、実際のピアアドレスを入れて、次のホップがトンネルインターフェースでないことを確認します。

制御とサービスを順に検証する

上へ順に進みます:フェーズ 1 の状態、フェーズ 2 の状態、その後に実際のアプリケーションフローです。show security ipsec sa はセキュリティアソシエーションを一覧し、show security flow session destination-prefix 10.60.0.0/16 は保護ネットワーク向けの転送セッションが作られているかを示します。

健全な制御関係と機能するデータ経路は二つの異なる結果です、フェーズ 2 の通過はポリシーがアプリケーションを許可するかについて何も語りません。許可されるフローとポリシーが拒否すべきフローを一つずつ試し、違いが見えるようにします。

ピアルート、host-inbound の許可、トンネルのバインド、内部ルート、アプリケーションポリシーをまとめて記録します。これら五つの記録は、ポートラベルに頼らずに将来の障害がどの層のものかを示します。

関連記事