Wireguard beendet den Handshake nicht

Question

Ich habe zwei Debian GNU/Linux-Systeme (bullseye/sid), die beide Wireguard auf Port 23456 ausführen, beide hinter NAT. Beide laufen mit einer Kernel-Version > 5.6 (wireguard mainlined).

System A ist der Server und aktualisiert dynamisch einen dedizierten „A-Eintrag“ im autorisierenden Nameserver für seine Internetdomäne mit der richtigen öffentlichen IP-Adresse, die seinem mit dem Internet verbundenen Router A (ZyWALL USG 100-Firewall) zugewiesen ist. Dies geschieht einmal pro Minute, aber die öffentliche IP-Adresse ändert sich tatsächlich nur beim Neustart des Routers/der Firewall, was im Grunde nie passiert.

System B befindet sich hinter VDSL-Router B und fungiert als Wireguard-Client, der auf den dynamisch aktualisierten „A-Eintrag“ und Port 33456 zeigt. Router B ist ein VDSL-Router der Verbraucherklasse und lässt alles in ausgehender Richtung zu, antwortet nur eingehend.

Router/Firewall A (ZyWALL USG 100) ist so konfiguriert, dass UDP-Pakete auf Port 23456 durchgelassen und an Server A weitergeleitet werden. Hier ist der entsprechende Konfigurationsbildschirm:

Hier ist die Server-A-Wireguard-Konfigurationsdatei (Schlüssel in diesem Snippet sind, obwohl sie gültig sind, nicht die echten):

[Interface]
Address = 10.31.33.100/24, fc00:31:33::1/64
ListenPort = 23456
PrivateKey = iJE/5Qy4uO55uUQg8nnDKQ/dFT1MEq+tDfFXrGNj3GY=
# PreUp = iptables -t nat -A POSTROUTING -s 10.31.33.0/24  -o enp1s0 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -s fc00:31:33::/64 -o enp1s0 -j MASQUERADE
# PostDown = iptables -t nat -D POSTROUTING -s 10.31.33.0/24  -o enp1s0 -j MASQUERADE; ip6tables -t nat -D POSTROUTING -s fc00:31:33::/64 -o enp1s0 -j MASQUERADE

# Simon
[Peer]
PublicKey = QnkTJ+Qd9G5EybA2lAx2rPNRkxiQl1W6hHeEFWgJ0zc=
AllowedIPs = 10.31.33.211/32, fc00:31:33::3/128

Und hier ist die Wireguard-Konfiguration von Client B (auch hier sind Schlüssel und Domain nicht die echten):

[Interface]
PrivateKey = YA9cRlF4DgfUojqz6pK89poB71UFoHPM6pdMQabWf1I=
Address = 10.31.33.211/32

[Peer]
PublicKey = p62kU3HoXLJACI4G+9jg0PyTeKAOFIIcY5eeNy31cVs=
AllowedIPs = 10.31.33.0/24, 172.31.33.0/24
Endpoint = wgsrv.example.com:33456
PersistentKeepalive = 25

Hier ist ein schmutziges Diagramm, das die Situation darstellt:

Client B -> LAN B -> VDSL Router B (NAT) -> the internet -> ZyWALL (NAT) -> LAN A -> Server A

Das Starten von wireguard auf beiden Systemen baut die VPN-Verbindung nicht auf. Wenn ich Debug-Meldungen auf dem Client aktiviere und eine LOG-Regel zu iptables hinzufüge, die OUTPUTPakete protokolliert, erhalte ich viele davon:

[414414.454367] IN= OUT=wlp4s0 SRC=10.150.44.32 DST=1.2.3.4 LEN=176 TOS=0x08 PREC=0x80 TTL=64 ID=2797 PROTO=UDP SPT=36883 DPT=33456 LEN=156 
[414419.821744] wireguard: wg0-simon: Handshake for peer 3 (1.2.3.4:33456) did not complete after 5 seconds, retrying (try 2)
[414419.821786] wireguard: wg0-simon: Sending handshake initiation to peer 3 (1.2.3.4:33456)

Ich habe dem Server eine LOG-iptables-Regel hinzugefügt, um Probleme mit der Router-Konfiguration zu diagnostizieren.

root@wgserver ~ # iptables -t nat -I INPUT 1 -p udp --dport 23456 -j LOG

Es protokolliert die vom Client empfangenen Wireguard-Pakete (aber ich kann nicht sagen, ob sie irgendwie ungültig oder unvollständig sind):

[ 1412.380826] IN=enp1s0 OUT= MAC=6c:62:6d:a6:5a:8e:d4:60:e3:e0:23:30:08:00 SRC=37.161.119.20 DST=10.150.44.188 LEN=176 TOS=0x08 PREC=0x00 TTL=48 ID=60479 PROTO=UDP SPT=8567 DPT=23456 LEN=156 
[ 1417.509702] IN=enp1s0 OUT= MAC=6c:62:6d:a6:5a:8e:d4:60:e3:e0:23:30:08:00 SRC=37.161.119.20 DST=10.150.44.188 LEN=176 TOS=0x08 PREC=0x00 TTL=48 ID=61002 PROTO=UDP SPT=8567 DPT=23456 LEN=156 

Daher neige ich zu der Annahme, dass der A-Router (ZyWALL USG 100) korrekt konfiguriert wurde, damit die Pakete in das lokale Netzwerk des Servers gelangen können. Um diese Annahme zu bestätigen, habe ich sogar versucht, die ZyWALL durch einen anderen Verbraucher-Router zu ersetzen und den Server über eine andere Internetverbindung zu verschieben, aber das Problem ist immer noch da, also bin ich mir sicher, dass das Problem nicht die Firewall oder ihre spezifische ist Internetverbindung.

Hier ist die Server-Netzwerkkonfiguration, falls es darauf ankommt:

auto lo
iface lo inet loopback

auto enp1s0
iface enp1s0 inet static
    address 10.150.44.188/24
    gateway 10.150.44.1

Darüber hinaus funktionieren andere Wireguard-VPN-Tunnel korrekt mit demselben Client, demselben VDSL-Router (clientseitig), derselben Internetverbindung, ähnlicher Serverkonfiguration (offensichtlich unterschiedliche Schlüssel und Domäne), ähnlicher Firewall-Konfiguration (serverseitig, unterschiedliche Firewall-Modell).

Answer 1

Es mag dumm sein, aber haben Sie versucht, neue Serverschlüssel, Clientschlüssel zu erstellen und es erneut zu versuchen? Wireguard kann genau so handeln, wenn die Profile falsch sind.

Answer 2

OK, Sie haben erwähnt, dass der Client auf VDSL ist, also vermute ich, dass Sie ein MTU-Problem haben.

Die normale MTU einer kabelgebundenen (und heutzutage drahtlosen) Netzwerkverbindung beträgt 1500 Byte, aber bei *DSL belegt die PPPoE-Schicht 8 Byte, sodass die nutzbare MTU tatsächlich 1492 beträgt. (Es ist auch möglich, dass Ihre Netzwerkverbindung auf eine eingestellt wurde noch niedrigere MTU.)

Der Paket-Overhead von Wireguard beträgt 80 Bytes, was bedeutet, dass die Tunnel-MTU standardmäßig 1420 beträgt. Versuchen Sie, dies um die gleichen 8 Byte auf 1412 zu verringern. (Oder niedriger, wenn Sie bereits eine niedrigere MTU als 1492 hatten.)

Außerdem muss der Client den Server anweisen, seine MTU für getunnelte Pakete zu verringern. Dies kann mit einer iptables-Regel erfolgen.

Auf der Client-Seite wg0.conf benötigen Sie so etwas wie:

[Interface]
MTU = 1412
PostUp = iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
;....the rest