Junos デュアルWAN IPsec VPN：送信元パスを正しいゲートウェイに合わせる

デュアルWAN IPsec のための Junos SRX 実践ガイドです。各ローカル送信元を候補ゲートウェイと対応づけ、実際にどのアソシエーションがトラフィックを運んだのかを確かめます。

サイトごとに WAN リンクが二本あれば冗長に見えますが、特定のフローが実際にどのアドレスペアを使ったのかを証明しようとすると別の話になります。SRX では IKE ゲートウェイ一つが外部インターフェース一つとローカルアドレス一つを担当し、リモート候補のリストがあってもローカル送信元が二つに増えるわけではありません。だからこのガイドは設定ではなくペアのマトリクスから始めます。Junos は意図した組み合わせの半分しか覆わない設計でも素直に commit してしまうからです。私がこれを踏んだのは SRX345s 二台の構成で、バックアップトンネルがきれいに上がったのに切り戻しでセッションを落としました。

手順どおりに進めます。サポートすべきペアを列挙し、ローカル送信元ごとにゲートウェイを一つ作り、どのアソシエーションがトラフィックを運んだかを確認し、そのうえで初めて、各障害が何を変えてよいかを決めます。

CLI を触る前にペアを可視化する

サイト A が A1 か A2 から送信でき、サイト B が B1 か B2 で受信できるなら、外側アドレスのペアは四つあります。多くの設計はそのうち二つを常時使い、残り二つは任意として扱います。マトリクスを書き出し、各行に印を付けます。約束した行はどれも、後でゲートウェイ一つ、トンネルインターフェース一つ、ルーティング判断一つを必要とします。

Local sourceRemote candidateRequired?
A1, ISP1 addressB1steady state
A1, ISP1 addressB2decide explicitly
A2, ISP2 addressB1decide explicitly
A2, ISP2 addressB2backup path

必要なペアはどれも同時に三つを満たす必要があります。そのアドレス間に到達できる underlay、両端でピア識別子と送信元アドレスを相互に受け入れること、そして保護された戻り経路です。片方向しか通らないペアでもトンネルは表示され、障害は後からアプリケーションの片方向トラフィックとして現れます。

リモートサイト単位ではなくローカル送信元単位でゲートウェイを分ける

リモートアドレスのリストはゲートウェイに属し、ローカル送信元も同じです。IKE ゲートウェイのリファレンスでは、リモートアドレス、外部インターフェース、ローカルアドレス、デッドピア検出が別々の設定として扱われています。ここが要点です。ローカル送信元が二つあるなら、st0 ユニット二つに対してゲートウェイも二つ必要です。IKE ポリシーを共有するのは構いませんが、ゲートウェイ一つで済ませて自分で送信元を選び直すと期待するのは筋が通りません。

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

次にトンネルを接続し、リモートプレフィックスにネクストホップを二つ、トンネルごとに一つ与えます：

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

一つのゲートウェイが address 型のステートメントを二つ持てるかどうかは、リリースとそのボックスがどの IKE プロセスを動かしているかで変わります。kmd ベースの古い Junos はゲートウェイあたりリモートアドレスを一つしか受け付けません。新しいビルドは複数の候補を扱えますが独自の制約が加わり、高可用性クラスタではこのサポートが狭まることがよくあります。古いシャーシから流用する前に、自分のビルドのリリースノートを確認してください。

どのアソシエーションがパケットを運んだかを確認する

SA が二つ、トンネルが二つあっても、どちらがセッションを転送したかは分かりません。ボックスに直接問い合わせ、意図したペアとフィールドを突き合わせます：

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

詳細出力はアソシエーションごとにローカルとリモートのゲートウェイを示すので、想定外の送信元からネゴシエートされたトンネルを見つける最短の方法です。そのあと通信を流しながら st0.1 と st0.2 のユニット別パケットカウンタを確認します。何も通していないトンネルは SA を保持したまま、サマリでは健全に見えます。

障害の種類ごとに検出器を分ける

ピアの生存、ローカルアップリンクの喪失、保護ルートの撤回、アプリケーションの断絶は四つの別イベントです。DPD が答えるのは最初の一つだけなので、既定値のまま他も覆うと決めつけるのではなく、説明できる間隔と閾値で設定します：

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

リモートサブネット内の宛先を試すトンネル監視は、DPD では見えないケースを覆います。IKE は生きていてゲートウェイも応答するのに、保護プレフィックスに届かない場合です。どちらに優先権を持たせるかを決めてください。両方が同時に発火すると、きれいなフェイルオーバーではなく変更の嵐になります。

遠端も忘れないでください。リモートサイトに残った優先ルートは、すでに捨てたトンネルを指したままになり、ローカルのタイマーでは直りません。同じ優先ロジックを両方のピアに公開し、復旧したリンクが自動でトラフィックを取り戻すのか、手動で切り替えるのかを記録します。

片方に触れずにもう片方のリンクを再アドレスする

ISP が新しいブロックを渡してきたら、一度に一つの関係だけを変えます。そのペアの両方のピアで address か local-address を更新し、commit して、ボックス上の全 SA を消すのではなく影響を受けたアソシエーションだけをインデックス指定で消します。全体クリアは健全なトンネルも巻き込み、メンテナンスウィンドウを障害に変えてしまいます。

何かを片付ける前に、失敗したフロー一つとそのセッション詳細を証拠として残し、そのうえで新しいアドレスペアに対して上の確認をやり直します。リンクの復旧はルーティングの判断なので、古い優先が自然に戻ると決めつけず、復旧自体を独立した検証済みの手順として扱います。

短いチェックリストで変更を閉じる

デュアルWAN のトンネル設計は、両方の SA が上がったときではなく、すべてのセッションの背後にあるペアを言えるときに完了します。実際に触ったボックスで次のリストを確認してください：

  • 約束したペアにはそれぞれゲートウェイ、st0 ユニット、ルートエントリがあります。
  • 各トンネルは SA を保持しているだけでなく、パケットを運んでいるのを確認済みです。
  • 両端が検出方法と、どちら側が優先を戻すかで一致しています。
  • 各ペアの戻り経路は、行きの経路の隣に書き留めてあります。

どこかの行が成り立たないなら、次を足す前にそのペアを直してください。半分しか動かないトンネルを重ねると、カウンタは意味を失い、フェイルオーバーの挙動は予測できなくなります。

関連記事