Strongswan Roadwarrior routet nicht richtig

1008
Bogdan

Ich möchte, dass ein Linux-Client eine Verbindung zu einem Linux-Gateway herstellt, damit er von diesem Netzwerk aus auf die Hosts zugreifen kann (typische Road-Warrior-Konfiguration).

Ich habe diese Konfiguration auf der Serverseite:

conn vpnserver-ikev2 auto=add compress=no type=tunnel keyexchange=ikev2 fragmentation=yes forceencaps=yes ike=aes256-sha512-modp4096 esp=aes256-sha512 dpdaction=clear dpddelay=300s inactivity=5s rekey=no left=%any leftid=vpn-test.nimblex.com leftcert=/etc/ipsec.d/certs/vpn-server-cert-new.pem leftsendcert=always leftsubnet=172.31.0.0/16 right=%any rightid=%any rightauth=eap-radius rightsourceip=10.10.0.1/16 rightdns=8.8.8.8 rightsendcert=never eap_identity=%identity

Und das auf der Kundenseite:

conn ikev2-rw right=vpn-test.nimblex.com rightid=%vpn-test.nimblex.com rightsubnet=172.31.0.0/16 rightauth=pubkey leftsourceip=%config leftauth=eap eap_identity=123456789 auto=route

Die Authentifizierung scheint gut zu laufen, aber wenn ich versuche zu pingen, funktioniert das nicht.

Protokolle auf der Serverseite sehen folgendermaßen aus, wenn ich ping:

04[IKE] peer requested virtual IP %any 04[CFG] assigning new lease to '123456789' 04[IKE] assigning virtual IP 10.10.0.1 to peer '123456789' 04[IKE] CHILD_SA vpnserver-ikev2 established with SPIs c7b0a75b_i c5fed014_o and TS 172.31.0.0/16 === 10.10.0.1/32 04[CFG] sending RADIUS Accounting-Request to server '172.31.12.234' 04[CFG] received RADIUS Accounting-Response from server '172.31.12.234' 04[ENC] generating IKE_AUTH response 4 [ AUTH CPRP(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) ] 04[NET] sending packet: from 172.31.9.29[4500] to 82.76.67.8[4500] (304 bytes) 03[JOB] deleting CHILD_SA after 5 seconds of inactivity 03[IKE] closing CHILD_SA vpnserver-ikev2 with SPIs c7b0a75b_i (0 bytes) c5fed014_o (0 bytes) and TS 172.31.0.0/16 === 10.10.0.1/32 03[IKE] sending DELETE for ESP CHILD_SA with SPI c7b0a75b 03[ENC] generating INFORMATIONAL request 0 [ D ] 03[NET] sending packet: from 172.31.9.29[4500] to 82.76.67.8[4500] (96 bytes) 02[NET] received packet: from 82.76.67.8[4500] to 172.31.9.29[4500] (96 bytes) 02[ENC] parsed INFORMATIONAL response 0 [ D ] 02[IKE] received DELETE for ESP CHILD_SA with SPI c5fed014 02[IKE] CHILD_SA closed

... und auf der Kundenseite so:

09[IKE] installing DNS server 8.8.8.8 via resolvconf 09[IKE] installing new virtual IP 10.10.0.1 09[IKE] CHILD_SA ikev2-rw established with SPIs c5fed014_i c7b0a75b_o and TS 10.10.0.1/32 === 172.31.0.0/16 09[IKE] peer supports MOBIKE 07[NET] received packet: from 54.89.185.13[4500] to 192.168.1.4[4500] (96 bytes) 07[ENC] parsed INFORMATIONAL request 0 [ D ] 07[IKE] received DELETE for ESP CHILD_SA with SPI c7b0a75b 07[IKE] closing CHILD_SA ikev2-rw with SPIs c5fed014_i (0 bytes) c7b0a75b_o (0 bytes) and TS 10.10.0.1/32 === 172.31.0.0/16 07[IKE] sending DELETE for ESP CHILD_SA with SPI c5fed014 07[IKE] CHILD_SA closed 07[ENC] generating INFORMATIONAL response 0 [ D ] 07[NET] sending packet: from 192.168.1.4[4500] to 54.89.185.13[4500] (96 bytes)

Die 220 Routing-Tabelle sieht folgendermaßen aus: 172.31.0.0/16 via 192.168.1.1 dev wlp4s0 proto static src 192.168.1.4

iptables wird geleert und ip_forward ist 1.

Bei der Verbindung vom iPhone aus kann ich das VPN-Gateway anpingen, jedoch keine anderen Hosts im Netzwerk. Bei der Verbindung vom Linux-Host aus kann ich nicht einmal das VPN-Gateway pingen.

tcpdump auf dem VPN-Gateway, wenn Ping vom iPhone empfangen wird. Es sieht folgendermaßen aus:

19:54:17.865831 IP (tos 0x0, ttl 1, id 51961, offset 0, flags [none], proto ICMP (1), length 84) ip-10-10-0-1.ec2.internal > vpn-test: ICMP echo request, id 37673, seq 0, length 64

... wenn ich vom iPhone aus einen anderen Server im Netz ping:

19:55:04.220726 IP (tos 0x0, ttl 1, id 54334, offset 0, flags [none], proto ICMP (1), length 84) ip-10-10-0-1.ec2.internal > ip-172-31-15-66.ec2.internal: ICMP echo request, id 7727, seq 0, length 64

... und wenn ich vom Linux-Host aus ping, wird kein ICMP-Verkehr auf dem VPN-Server empfangen.

Auf meinem Linux-Client sieht tcpdump folgendermaßen aus:

23:01:21.492340 IP (tos 0x0, ttl 64, id 62233, offset 0, flags [DF], proto ICMP (1), length 84) 10.10.0.2 > 172.31.15.66: ICMP echo request, id 21102, seq 1, length 64

Was vermisse ich?

0
Die Route sieht falsch aus (falsche Quell-IP, sollte die virtuelle IP sein), die Ausgabe von tcpdump auf dem Client sieht falsch aus (warum 10.10.0.2, wenn 10.10.0.1 als virtuelle IP zugewiesen ist). Aufgrund des Inaktivitäts-Timeouts wird CHILD_SA ziemlich sofort zerstört. ecdsa vor 6 Jahren 0
Es war 10.10.0.2, da ich das Telefon angeschlossen und die IPs geändert habe, seit ich das Tcpdump-Ding im Abstand von wenigen Minuten kopiert / eingefügt habe. Ich glaube nicht, dass es wichtig ist, dass der CHILD_SA zerstört wird, da er bei Aktivitäten neu erstellt wird. Die zwei Hauptfragen hier: 1. Warum ist die Route unter Linux falsch? 2. Warum geht es unter iOS nur an den Router und kann keinen Server vom Netzwerk aus erreichen? Bogdan vor 6 Jahren 0
Erhöhen Sie den Log-Level für _knl_ auf 2. Lesen Sie auch [Forwarding und Split-Tunneling] (https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling). ecdsa vor 6 Jahren 0
Wie Sie in den configs sehen können, versuche ich bereits, Split-Tunneling zu verwenden, indem Sie rightsubnet auf dem Gateway und das gleiche leftsubnet auf dem Linux-Client einstellen. Der Ausgang mit knl auf 2 lautet: https://hastebin.com/abifimogec.log Bogdan vor 6 Jahren 0
Das ist mir vorher nicht aufgefallen, aber Sie können `auto = route` derzeit nicht mit` leftsourceip =% config '([# 2162] (https://wiki.strongswan.org/issues/2162)) kombinieren. Und Sie sollten die komplette Seite lesen, nicht nur den Titel. ecdsa vor 6 Jahren 1

1 Antwort auf die Frage

0
Bogdan

Wie von ecdsa vorgeschlagen, war es falsch, auto=routeif zu verwenden leftsourceip=%config.

Es hätte sein sollen auto=start.

Verwandte Probleme