IPsecトンネルに3つのip xfrmポリシーだけが必要なのはなぜですか？

strongswan（v5.2.0）インスタンス（サイトA）とRouterOSルーター（サイトB）の間で稼働しているサイト間IPsecトンネルがあります。すべてが正常に機能し、サイトA（10.10.0.0/16）とB（10.50.0.0/16）の2つのプライベートサブネットセットアップ内のホストは、互いに正常に通信できます。

私が理解していないのは、ip xfrm policyサイトAのルーター（パブリックIPが難読化されている）の次の出力です。これらのポリシーはによって作成されましたがstrongswan、手動でインストールしたり変更したりしていません。

ip xfrm policy 
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir fwd priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir in priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.10.0.0/16 dst 10.50.0.0/16 
    dir out priority 2947 ptype main 
    tmpl src <PUBLIC_IP_A> dst <PUBLIC_IP_B>
        proto esp reqid 1 mode tunnel

入力と出力にはそれぞれポリシーがありますが、転送（サイトBからサイトAへ）には1つだけです。しかし、私はたとえば、次の場所10.50.4.11からpingを正常に実行できます10.10.0.89。

ping -R 10.50.4.11
PING 10.50.4.11 (10.50.4.11): 56 data bytes
64 bytes from 10.50.4.11: icmp_seq=0 ttl=62 time=10.872 ms
RR:     10.10.0.89
    10.50.0.1
    10.50.4.11
    10.50.4.11
    10.50.4.11
    10.10.0.2
    10.10.0.89

このルートトレースの興味深い部分は、サイトAのルーター（10.10.0.2）はpingターゲットから戻るルートにのみ表示され、サイトBのルーター（10.50.0.1）は発信ルートにのみ表示されることです。

これは、サイトAのルーターでIPsecトンネルを介して転送する転送ポリシーが実際には必要ないことを確認しているようですが、理由はわかりません。10.10.0.0/1610.50.0.0/16

説明ありがとうございます！

FWDポリシーがされていない自動的にカーネルによって生成されたが、代わりに合わせるデーモン（この場合はstrongSwanの）によってインストールされます。

これらは、トンネルモードのVPNゲートウェイの背後にあるホストとの間でトラフィックを転送できるようにするために必要です。

ゲートウェイ自体にインストールされていないIPをアドレスとするインバウンドパケットの場合、復号化後にfwdポリシーが検索されます。ローカルトラフィックの場合、ポリシーの一致が検索されます。何も見つからない場合、パケットはドロップされます。

VPNゲートウェイ自体で生成されなかったアウトバウンドトラフィックについては、fwdポリシーが検索されます。パケットが暗号化されていなかった場合、一致するfwdポリシーが見つからなければ、失敗にはなりません。トラフィックは2つのトンネル間で転送されている場合、着信FWD 1でインストールされたポリシーは、アウトバウンドとして機能しますFWD他の、またその逆のポリシー。その後、パケットをトンネリングするかどうかを決定するために、outポリシーが検索されます。そのため、発信方向のFWDポリシーは、多くの場合必要ありません。

ただし、すべてに一致する低優先度のドロップ/ブロックFWDポリシーがある場合（たとえば、トンネルが確立されていない場合にクリアテキストトラフィックがゲートウェイを通過しないようにするため）、ブロックポリシーは明示的に発信方向のFWDポリシーが必要です。それ以外の場合は、暗号化されていないトラフィックをすべてドロップします。それがstrongSwanが5.5.0で双方向のfwdポリシーのインストールを開始した理由です。

この回答の以前のバージョンでは、単一の（インバウンド）fwdポリシーは対称的である（つまり、srcとdstはどちらの方向でも機能する）と述べていました。これは真実ではありませんが、上記で説明したように、多くの状況でこれは問題になりません。