WireGuard-Handshake funktioniert, aber das Büro-Subnetz antwortet nicht

Der Handshake ist abgeschlossen, wg show meldet aktuellen Transfer, und die Tunneladresse des Servers antwortet auf einen Ping. Ein Host im LAN des Servers nicht. Drei Bedingungen müssen gleichzeitig gelten: Der Client muss das LAN-Präfix in den Tunnel routen, der Server muss die Pakete weiterleiten, und die Antwort braucht einen Weg zurück. Fehlt eine der drei, ist das Symptom identisch.

AllowedIPs ist Zugriffsliste und Routing-Tabelle zugleich

Auf dem Client entscheidet die Liste AllowedIPs sowohl darüber, was an diesen Peer gesendet werden darf, als auch darüber, welche Routen WireGuard installiert. Ein Peer-Eintrag, der nur die Tunneladresse des Servers nennt, installiert eine Host-Route, sodass LAN-Ziele nie in den Tunnel gelangen. Das LAN-Präfix hinzuzufügen ist das Erste, was zu prüfen ist, und zugleich die Änderung, die nach einer kopierten Konfiguration am häufigsten fehlt. Ein Peer, der auf eine Standardroute erweitert wurde, ist ein anderes Design und verschiebt auch den Internetverkehr des Clients.

Halten Sie die Host-Route und das LAN-Präfix als getrennte Einträge. Hat das Büro zwei Subnetze, gehören beide in die Liste, und das fehlende zweite Präfix erzeugt einen Fehler, der selektiv statt vollständig wirkt.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Weiterleitung und Übersetzung gehören auf den Server

Der Server braucht aktivierte IP-Weiterleitung, eine Weiterleitungsregel, die Verkehr aus dem Tunnel annimmt, und eine Übersetzungsregel in Richtung seiner LAN-Schnittstelle. Die Übersetzung ist es, die das Design funktionieren lässt, ohne jeden Host im Büronetz anzufassen. Antworten kehren dann zum Server zurück statt an eine Adresse, von der das LAN nie gehört hat. Ohne sie braucht jeder Host eine Route für das Tunnel-Subnetz und eine Firewall-Regel, die sie erlaubt, was in einem Netz, das jemand anderes verwaltet, selten akzeptabel ist.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Von Hand hinzugefügte Regeln verschwinden beim Neustart, also binden Sie sie mit den Hook-Befehlen in der Serverkonfiguration an die Schnittstelle. Ein Regelsatz, der seine Schnittstelle überlebt, ist der Weg, auf dem eine Maschine am Ende Verkehr für einen Tunnel übersetzt, der nicht mehr existiert.

Als das LAN umzog und die Regel nicht

Der Routertausch, der das Büro-Subnetz neu nummeriert, ist die klassische Variante dieses Fehlers. Der Tunnel bleibt oben, der Handshake bleibt frisch, und hinter dem Server antwortet nichts, weil die Übersetzungsregel noch die alte Adresse nennt. Installationsskripte brennen die LAN-Adresse des Servers oft in eine POSTROUTING-Regel ein, und nach einer Neunummerierung existiert diese Adresse auf keiner Schnittstelle. Pakete werden dann auf ein Ziel umgeschrieben, das nicht antworten kann.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Vergleichen Sie die beiden Ausgaben. Ein Übersetzungsziel, das nicht in der Schnittstellenliste erscheint, ist der Fehler, und ihn zu beheben ist eine Änderung in einer Zeile, sobald man ihn gesehen hat. Die Regel kann in einer generierten Unit statt in der WireGuard-Konfiguration liegen, also laden Sie diese Unit nach der Bearbeitung neu und prüfen Sie, dass der nächste Start Ihre Änderung nicht überschreibt.

Zwei Standorte hinter NAT brauchen einen Treffpunkt

Wenn keine Seite eingehende Verbindungen annimmt, ist die praktische Antwort ein kleiner Host mit öffentlicher Adresse und zwei WireGuard-Schnittstellen. Jeder Standort verbindet sich nach außen, der mittlere Host führt das LAN jedes Peers in seinem eigenen AllowedIPs, und Weiterleitung trägt Pakete zwischen den beiden Tunneln. An der Firewall keines der beiden Standorte muss sich etwas ändern, weshalb sich dieses Design leicht verbreitet.

Das Routing zwischen den Standorten behält die ursprünglichen Quelladressen und hält damit die Protokollierung pro Host aussagekräftig. Übersetzung am mittleren Host ist einfacher, wenn sich die beiden LANs überlappen, kostet aber die Quellidentität in den Protokollen. Entscheiden Sie, welche Eigenschaft zählt, bevor Sie wählen.

Trennen Sie die Schichten mit vier Prüfungen

Führen Sie eine Prüfung pro Schicht durch, statt drei Dinge zu ändern und zu hoffen. Die erste zeigt Handshake-Alter und Zähler für jeden Peer. Die zweite zeigt, ob der Client dieses Ziel tatsächlich in den Tunnel routet. Die dritte und vierte sagen Ihnen, ob die Anfrage ankam und ob eine Richtlinie sie nach dem Eintreffen verworfen hat.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Eine Anfrage, die ankommt und keine Antwort auslöst, deutet auf den Antwortweg oder auf den LAN-Host. Eine Anfrage, die nie ankommt, deutet auf AllowedIPs oder auf die Route des Clients. Diese beiden Ausgänge brauchen unterschiedliche Korrekturen, und der Mitschnitt ist es, der sie unterscheidet.