Check Point VSX VPN：リンク選択か、それともピアの不一致か

Check Point のサイト間トンネルが上がらなくなったとき、同じ症状を生む変更が二つあります。ピアが別の外側アドレスを見ているか、あるいは今受け取っている IKE 識別子を拒否しているかです。片側で取得したキャプチャでは両者は同じに見えます。どちらなのかを判断するには三つの確認が必要で、そのいずれもリンク選択の画面ではありません。

順序を誤ると、識別子の不一致を直そうとして送信元選択を調整してしまいます。こうして同じトンネルが二度直され、次のルート変更のあとにまた壊れます。

二つのケースを分ける三つの条件

一つ目の条件は、ピアに設定されたエンドポイントが実際に到着するアドレスと一致するかです。パケットが、ピア側で自分のピアオブジェクトに関連付けられていないアドレスから遠隔ゲートウェイに届くなら、識別子を交換する前にネゴシエーションが失敗します。二つ目の条件は、提案に含まれる IKE 識別子がピアの期待値と一致するかです。これは認証であり、転送ではありません。三つ目の条件は、変更したいオプションが このリリースのこの仮想システムでサポートされているか です。画面に見えている設定は、これらのどれにも答えません。

一つ目が満たされないなら、ルーティングか変換の問題です。二つ目が満たされないなら、ピアとの取り決めの問題です。三つ目が不明なら、設定をやめてください。

まず外側ピアの記録を作る

何かに触れる前に、仮想システム、ソフトウェアのリリース、インストール済みの更新レベルを書き留めます。そのうえで、外側インターフェース、遠隔ピアへ向かうルート、NAT の前後で期待される送信元アドレス、遠隔ピアに設定されたエンドポイントを記録します。

内側の保護対象プレフィックスは、その記録の別の部分に置きます。外側の送信元を変えることと、保護された LAN アドレスを変えることは別の操作であり、たまたま同じポリシーの中に同居しているだけです。

保存するキャプチャには必ず方向を付けます。ローカルで開始したネゴシエーションと遠隔ピアへの応答とでは選択が異なることがあるため、ラベルのないキャプチャは弱い証拠です。ファイル名に仮想システムと開始側を付けます。

リンク選択が実際に何を分けているのかを読む

Check Point の R81.20 のリンク選択ガイド は、人が一つにまとめてしまいがちな三つを分けています。遠隔ピアがゲートウェイのアドレスをどう解決するか、どのルートが外向きのトラフィックを運ぶか、どの送信元 IP を使うかです。それぞれ別の問いに答えるもので、いずれもピアが認証する識別子を変えるものではありません。

この分離があるからこそ、ルート変更が IKE 識別子に触れずに外側の見えるアドレスを変えられるのですし、識別子の変更がルーティングの完璧なトンネルを壊すこともあるのです。

RFC 7296 は IKE 自体についても同じ線を引いています。識別ペイロードは転送アドレスではありません。ベンダーはこの分離を実装しており、定義し直してはいません。

設定画面ではなく証拠で決める

ピアが未知の、または一致しない識別子を報告するなら、送信元選択ではなくピアオブジェクトか識別子の設定を直します。ピアが何も報告せず、キャプチャでパケットが予期しないアドレスから出ているなら、まずルーティングか変換を直します。どちらも正しく見えるのにトンネルが失敗するなら、遠隔側でキャプチャし、何を受け取ったかを比べます。アドレスと識別子が一致し、それでも経路が誤っているときにだけ、リンク選択のオプションが候補になります。

VSX でそのオプションを設定する前に、該当リリースのサポート機能に関する指針か、仮想システムの文脈についてのベンダーの明示的な表明を入手します。ある機能が使えなかったという古い報告は履歴であって現在の禁止ではなく、設定画面はサポートの表明ではありません。

両端を突き合わせ、記録を残す

サポートされた設計が得られたら、外側への到達性、ピアのエンドポイント設定、識別子の合意をまとめて一つの契約として見直します。そのうえで三つのケースで受け入れを計画します。初回接続、遠隔側から開始される接続、そして経路が切れたときに想定する失敗です。

観測した外側アドレスは、稼働中の仮想システムの文脈の隣に保存します。そうすれば次にルートが変わったとき、誰かの記憶にある既定値ではなく、文書化された契約と比較できます。