Пакеты из интерфейса xfrm не маршрутизируются, но противоположное работает

. Я работаю над vpn типа "сеть-сеть", где один конец - UDM, а другой - Strongswan. Цель - обеспечить двунаправленную маршрутизацию в облачную среду. Я совершенно сбит с толку, почему это не работает.

Хорошая новость заключается в том, что Strongswan подключается и пропускает трафик. Но у меня есть некоторые проблемы с маршрутизацией на стороне Strongswan. У моего хоста Strongswan есть два интерфейса: eth0 с общедоступным IP-адресом в Интернете на eth0 и внутренний IP-адрес 10.132.169.74 на eth1

• Lan сети [s]: 10.87.0.0/24, 10.87.35.0/24, 10.87. 235.0 / 24
• Облачная сеть: 10.132.0.0/16
• 10.87.0.1 = UDM
• 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) работает
• пинг с 10.132.169.74 (Strongswan) -> 10.87.0.33 (тестовый хост Lan) работает
• пинг с 10.132.40.82 (облачный тестовый хост) -> 10.87.0.33 (Lan тестовый хост) работает
• пинг с 10.87. 0.33 (тестовый хост Lan) -> 10.132.40.82 (тестовый хост в облаке) Не работает, что является наиболее важным из всего этого

Вот таблица маршрутизации хоста 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

И, наконец, вот моя конфигурация swan:

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

и мой sysctl на хосте Strongswan:

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 показывает активные туннели, и когда я пингую, я вижу, что счетчики повышаются. Кроме того, tcpdump, прослушивающий на облачном тестовом хосте, показывает, что трафик не поступает, но tcpdump на хосте Strongswan в конкретном сценарии ДЕЙСТВИТЕЛЬНО показывает трафик, поэтому он будет там отброшен.

Любая помощь приветствуется, спасибо!