xfrmインターフェースからのパケットはルーティングされませんが、その逆は機能します

xfrmインターフェースからのパケットはルーティングされませんが、その逆は機能します

私はサイト間 VPN に取り組んでいます。一方の端は UDM、もう一方の端は Strongswan です。目標は、クラウド環境への双方向ルーティングを提供することです。なぜこれが機能しないのか、まったく理解できません。

良いニュースは、Strongswan が接続してトラフィックを通過させることです。しかし、Strongswan 側でルーティングの問題があります。私の Strongswan ホストには 2 つのインターフェイスがあり、eth0 にはパブリック インターネット IP があり、eth1 には内部 IP 10.132.169.74 があります。

  • LAN ネットワーク: 10.87.0.0/24、10.87.35.0/24、10.87.235.0/24
  • クラウドネットワーク: 10.132.0.0/16
  • 10.87.0.1 = UD
  • 10.132.169.74 = Strongswan eth1 で、内部クラウド ネットワーク 10.132.0.0/16 に接続します。
  • 10.87.0.33 = LAN ネットワーク上のテストホスト
  • 10.132.40.82 = クラウド ネットワーク上のテスト ホスト

現在の状況:

  • 10.87.0.33 (Lan テストホスト) -> 10.132.169.74 (Strongswan) への ping は動作します
  • 10.132.169.74 (Strongswan) -> 10.87.0.33 (Lan テストホスト) への ping は機能する
  • 10.132.40.82 (クラウド テスト ホスト) -> 10.87.0.33 (LAN テスト ホスト) への ping は機能します
  • 10.87.0.33 (LAN テストホスト) -> 10.132.40.82 (クラウドテストホスト) への ping は機能しません。これが最も重要なことです。

以下は Strongswan ホスト 10.132.169.74 のルーティング テーブルです。

default via x.x.x.x dev eth0 proto static 
10.17.0.0/16 dev eth0 proto kernel scope link src 10.17.0.21 
10.19.49.0/24 dev wg0 proto kernel scope link src 10.19.49.1 
10.87.0.0/16 dev ipsec0 scope link src 10.132.169.74 
10.132.0.0/16 dev eth1 proto kernel scope link src 10.132.169.74 
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z

クラウド テスト ホスト (10.132.40.82) のルーティング テーブルは次のとおりです。

default via x.x.x.x dev eth0 proto static 
10.17.0.0/16 dev eth0 proto kernel scope link src 10.17.0.24 
10.87.0.0/16 via 10.132.169.74 dev eth1 
10.132.0.0/16 dev eth1 proto kernel scope link src 10.132.40.82 
x.x.x.y/20 dev eth0 proto kernel scope link src x.x.x.z 

Strongswan ホストでは、これを実行しています:

sudo ip link add ipsec0 type xfrm dev eth0 if_id 4242
sudo ip link set ipsec0 up
sudo ip route add 10.87.0.0/16 dev ipsec0 src 10.132.169.74

最後に、私のスワンの設定は次のとおりです。

sudo tee /etc/strongswan.d/charon-systemd.conf  << "EOF"
charon-systemd {
  load=pem pkcs1 x509 revocation constraints pubkey openssl random random nonce aes sha1 sha2 hmac pem pkcs1 x509 revocation curve25519 gmp curl kernel-netlink socket-default updown vici
  journal {
    default=0
    # enc=1
    # asn=1
  }
}
EOF

sudo tee /etc/swanctl/conf.d/xyz.conf << "EOF"
connections {
  vpn-cloud-udm-lan {
    version=2
    proposals=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
    unique=replace
    encap=yes
    local {
      id=x.x.x.x
      auth=psk
    }
    remote {
      auth=psk
    }
    children {
      net {
        local_ts=10.132.0.0/16
        remote_ts=10.87.0.0/16
        esp_proposals=aes128gcm16-sha256-modp2048,aes128-sha256-modp2048
        start_action=trap
        if_id_in=4242
        if_id_out=4242
      }
    }
  }
}
secrets {
  ike-1 {
    id-vpn-cloud=x.x.x.x
    secret="somesecret"
  }
  ike-2 {
    id-udm-lan=y.y.y.y
    secret="somesecret"
  }
}
EOF

Strongswan ホスト上の sysctl は次のとおりです。

net.ipv4.ip_forward=1
net.ipv4.conf.all.forwarding=1
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0

sudo swanctl --list-sasアクティブなトンネルが表示され、ping を実行するとカウンターが上昇しているのがわかります。さらに、クラウド テスト ホストでリッスンしている tcpdump ではトラフィックが到着していないことが示されていますが、特定のシナリオの Strongswan ホストでの tcpdump ではトラフィックが表示されるため、そこでドロップされます。

どのような助けでも大歓迎です、ありがとうございます!

答え1

そこで、頭を激しく振ったり(ロック音楽を聴くときのような頭振りではない)、歯ぎしりをしたりした後、私はこの答えから理解しました。https://www.digitalocean.com/community/questions/site-to-site-vpn-support-any-updates

Digital Ocean はプライベート インターフェイスでパケットをドロップしていました。そこで、10.87.0.0/24 からのトラフィックを許可するファイアウォール ルールを追加したら、なんと、うまくいきました!!!

関連情報