☰

Pakete von der xfrm-Schnittstelle werden nicht weitergeleitet, das Gegenteil funktioniert jedoch

tag-icon • tag-icon iptables vpn routing ipsec strongswan
Pakete von der xfrm-Schnittstelle werden nicht weitergeleitet, das Gegenteil funktioniert jedoch

Ich arbeite an einem Site-to-Site-VPN, bei dem ein Ende ein UDM und das andere Strongswan ist. Das Ziel ist, bidirektionales Routing in eine Cloud-Umgebung bereitzustellen. Ich bin völlig verblüfft, warum das nicht funktioniert.

Die gute Nachricht ist, dass Strongswan eine Verbindung herstellt und den Datenverkehr weiterleitet. Aber ich habe einige Routing-Probleme auf der Strongswan-Seite. Mein Strongswan-Host hat zwei Schnittstellen, eth0, das die öffentliche Internet-IP auf eth0 hat, und eine interne IP von 10.132.169.74 auf eth1

  • LAN-Netzwerk[e]: 10.87.0.0/24, 10.87.35.0/24, 10.87.235.0/24
  • Cloud-Netzwerk: 10.132.0.0/16
  • 10.87.0.1 = UDM
  • 10.132.169.74 = Strongswan eth1 und verbindet sich mit dem internen Cloud-Netzwerk 10.132.0.0/16
  • 10.87.0.33 = Testhost im LAN-Netzwerk
  • 10.132.40.82 = Testhost im Cloud-Netzwerk

momentane Situation:

  • Ping von 10.87.0.33 (Lan-Testhost) -> 10.132.169.74 (Strongswan) funktioniert
  • Ping von 10.132.169.74 (Strongswan) -> 10.87.0.33 (Lan-Testhost) funktioniert
  • Ping von 10.132.40.82 (Cloud-Testhost) -> 10.87.0.33 (Lan-Testhost) funktioniert
  • Ping von 10.87.0.33 (Lan-Testhost) -> 10.132.40.82 (Cloud-Testhost) Funktioniert nicht, was das Wichtigste an der ganzen Sache ist

Hier ist die Routing-Tabelle des Strongswan-Hosts 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

Hier ist die Routing-Tabelle auf dem Cloud-Testhost (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

Auf dem Strongswan-Host führe ich Folgendes aus:

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

Und hier ist schließlich meine Swan-Konfiguration:

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

und mein Sysctl auf dem Strongswan-Host:

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-saszeigt aktive Tunnel an und wenn ich pinge, kann ich sehen, wie die Zähler hochgehen. Darüber hinaus zeigt ein TCPdump, der auf dem Cloud-Testhost lauscht, keinen eingehenden Datenverkehr an, aber ein TCPdump auf dem Strongswan-Host in dem bestimmten Szenario zeigt den Datenverkehr an, sodass er dort gelöscht wird.

Jede Hilfe ist willkommen, danke!

Antwort1

Nach viel Headbangen (nicht die Art, die man bei Rockmusik macht) und Zähneknirschen habe ich es anhand dieser Antwort herausgefunden:https://www.digitalocean.com/community/questions/site-to-site-vpn-support-any-updates

Digital Ocean hat Pakete auf privaten Schnittstellen verloren. Also habe ich eine Firewall-Regel hinzugefügt, um Datenverkehr von 10.87.0.0/24 zuzulassen, und voilà! ES FUNKTIONIERT!!!

verwandte Informationen