拠点間 VPN：実際にルールが必要なのはどちらの方向か？

両端ともトンネルが確立したと報告し、遠隔の支店はゲートウェイから応答しているのに、一方の側のユーザーではアプリケーションが依然としてタイムアウトします。よくある助言は、両方向にファイアウォールルールを追加することです。それが正しいこともあれば、既存のルールを重複させることもあり、二つ目のルールが状態を壊すこともあります。どれに当たるかは、ファイアウォールがパケットをどこで見るかによって決まります。

ステートフルな戻りトラフィックは数を変える

ステートフルファイアウォールは要求を記録し、二つ目のルールなしで応答を通すため、一つのルールだけで足りる設計は正常です。ステートレスなアクセスリストにはそのような記憶がなく、応答は明示的に許可する必要があります。どちらもそれぞれのプラットフォームでは正しく、だから助言が食い違うのです。

目の前のプラットフォームの転送に関するドキュメントを読み、編集しているポリシーがパケットを見る場所でステートフルかどうかを確認します。確立済みトラフィックに対する明示的な拒否、または状態テーブルより先に応答を評価するルール順序は、動作する設計を不可解なものに変えます。ルールの数は実装の詳細であり、要件は許可された会話の両方向が完了できることです。

ファイアウォールが復号済みパケットを見る場所

ポリシーベースのトンネルでは、ファイアウォールが復号前の暗号化パケットと復号後のパケットを、異なるインターフェースで評価することがあります。誤った側に書かれたルールは存在し、正しく、決して一致しません。こうして、動作する展開からコピーしたルールセットが同一のハードウェアで失敗することがあります。

ルートベースの IPsec とほとんどの現代的な実装はトンネルインターフェースを提供するため、復号済みパケットはそこに到着し、通常のインターフェースルールが適用されます。もう一方のために書かれたガイドからルールセットをコピーする前に、展開がどちらのモデルを使うかを確認してください。トンネルインターフェースは、パケットがそもそも復号されたのかを知りたいときに見る場所でもあります。

非対称ルーティングは前提を壊す

ステートフルファイアウォールは会話の両半分を見ていると想定します。応答が別のゲートウェイを通って戻ると、その機器は要求の状態を保持せず、独自のポリシーに従って破棄します。症状は、送信側のどのルールでも修復できない一方向の失敗です。 応答の経路をたどる 何かを編集する前に。

両側に広い許可ルールを追加する前に、応答のルートを確認してください。すべてのインターフェースですべてを許容すると、ルーティングの誤りが隠れ、同時にアクセスが広がりますが、これは利用可能な最悪の組み合わせです。

実際の送信元アドレスで両方向を確認する

変換によって送信元ルールが何にも一致しなくなることがあるため、遠隔側が実際に観測するアドレスでテストします。両方のゲートウェイで同時にキャプチャを実行します。

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

遠隔ゲートウェイに予期しない送信元アドレスで現れる要求は、決して一致しないルールを説明し、誤ったインターフェースに届く応答は状態の不一致を説明します。次に、承認された範囲内の宛先と範囲外の宛先を一つずつテストし、境界を想定ではなく実証します。

変換後の送信元アドレス、復号済みパケットが使ったインターフェース、一致したルールを記録します。この三つの事実が、調査全体を繰り返さずに次のチケットに答えます。