拠点間 VPN が片方向しか通らない：二種類の異なる障害

拠点 A は B に到達できるのに、B から A には到達せず、トンネルは両方向とも正常に見えます。トンネルに触れる前に、実際にどちらの障害なのかを決めてください。B で開始した新規接続が拒否される場合と、A で開始した接続への応答が戻ってこない場合は、同じような苦情を生みながら診断はまったく異なります。片方は経路上のポリシーかルートの問題で、もう片方はすでに許可された通信の戻り経路か状態の問題です。

この区別が、どのコマンドを実行する価値があるかを決めます。

同じに見える二つの障害

最初のケースでは B のホストが A に SYN を送り、何も戻ってきません。二番目では A のホストがセッションを正常に開き、応答が戻り経路で消えます。どちらの利用者もリンクが片方向だと言い、どちらも消えたパケットを説明しているので、説明だけでは両者を区別できません。

失敗した試行をどちら側が開始したのかを尋ねてください。その一つの事実だけで、考えられる原因の半分が消えます。

次に、テストが最後まで同じホストと同じサービスを使っていたことを確認します。片側からの ping と反対側からのファイル共有接続では別のものを試しており、ゲートウェイから実行した診断は利用者トラフィックが決して使わないトンネルアドレスを選ぶことがあります。

ケース一：戻り経路がない

別のデフォルトゲートウェイ経由で応答する遠隔サーバーは、要求を受け取って応答を別の場所へルーティングできます。すると状態を追跡するファイアウォールが非対称な応答を破棄します — 確立済みのフローに一致しないためで、これは一度も機能しなかった方向とまったく同じに見えます。変換はもう一つの型を加え、宛先は変換された送信元を見てそれに応答するため、元のアドレス向けに書かれたルールは決して一致しません。

変換後に宛先が実際に観測するアドレスを確認し、元のサブネットではなくそのアドレスに対する戻り経路を確認します。

ケース二：ポリシーが最初から許可していない

逆のケースは見た目より単純でよくあり、ある拠点は中央サービスを利用するだけで中央へ接続を開始しない設計です。その非対称性は意図的なアクセス判断であり、トンネルは設計どおり動作しています。トンネルの設定を変える前にアクセスポリシーを読んでください。どちらの方向が意図されたかはパケットキャプチャではなく文書が示します。キャプチャは起きたことしか示せず、許可されていたことは示せません。

双方向の開始が本当に必要なら、プラットフォームが対応するルールセットでその特定サービスの許可を追加します。一つのアプリケーションを直すためにすべてのサブネットを相互信頼にすると、狭い要件が広い許可に変わり、その取引は後から見直されることがほとんどありません。

同じホストで変更前と変更後を比較する

別々の試行ではなく、同じ試行の両端を観察します。開始するホストのゲートウェイと宛先でキャプチャし、何が入り、何が出て、遠い側がどのアドレスを見たかを比較します。

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

宛先でのキャプチャが予期しない送信元アドレスを示すなら、答えはトンネルのセキュリティポリシーではなく変換かルーティングにあります。宛先に要求がまったく現れないなら、パケットは保護経路を一度も通過していません。

修正後は同じホストから同じテストを繰り返し、無関係なアクセスが依然として拒否されることを確認します。トンネルの “established” という状態だけでは、どちらの結論も支えません。