WireGuard-Handshake funktioniert, aber kein Internet: das Paket verfolgen

Der Tunnel steht, wg show meldet einen frischen Handshake, du kannst die Tunneladresse des Servers anpingen, und nichts dahinter antwortet. Der Instinkt ist, Schlüssel neu zu erzeugen oder die Konfiguration erneut zu teilen. Das ändert genau den Teil des Pfads, der bereits nachweislich funktioniert.

Ein abgeschlossener Handshake sagt, dass sich beide Peers über die Schlüssel einig sind, dass UDP den Endpunkt erreicht und dass das Krypto-Routing das Paket akzeptiert. Er sagt nichts darüber, ob das Paket den Server danach verlassen kann.

Verfolge also ein Paket, statt zu raten. Es gibt vier Stellen, an denen es sterben kann, und jede hinterlässt eine andere Spur.

Was der Handshake tatsächlich beweist

WireGuard ist ein UDP-Protokoll, das mit einem Noise-Handshake eine Sitzung aufbaut und danach Pakete für einen Peer verschlüsselt. Wenn wg show einen Handshake von wenigen Sekunden und einen steigenden Übertragungszähler anzeigt, sind Endpunkt, Schlüssel und der öffentliche Schlüssel des Peers alle korrekt.

Was er nicht beweist: dass dein Client überhaupt internetgerichteten Verkehr in die Schnittstelle schickt, dass der Server bereit ist, ihn weiterzuleiten, oder dass eine Antwort den Weg zurückfindet. Das sind Routing- und Firewall-Entscheidungen des Kernels, und sie fallen außerhalb des Tunnels.

Deshalb ist der Ping auf die Tunneladresse des Servers ein so irreführender Test. Dieses Paket ist an den Server selbst adressiert, also endet es lokal. Es braucht nie Weiterleitung, nie Übersetzung und nie eine Rückroute aus dem Internet.

AllowedIPs ist eine Routing-Entscheidung

Auf dem Client erfüllt AllowedIPs zwei Aufgaben. Es ist die Krypto-Schlüssel-Routingtabelle, die entscheidet, welche Zieladressen in den Tunnel dieses Peers gehen, und es ist die Liste der Quelladressen, die der Peer von dir akzeptiert. Steht in der Client-Konfiguration nur 10.8.0.0/24, gelangen öffentliche Ziele nie in die Schnittstelle, und deine normale Standardroute führt sie am Tunnel vorbei. Dann funktioniert der Tunnel einwandfrei und tut nichts von dem, was du wolltest.

Schau, was der Client tatsächlich installiert hat, statt was in der Konfigurationsdatei steht:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Der zweite Befehl ist der entscheidende. Nennt die Antwort deine physische Schnittstelle und das normale Gateway, wird das Paket nicht getunnelt, und keine Änderung auf dem Server wird das beheben. Füge 0.0.0.0/0 für IPv4 und ::/0 für IPv6 getrennt hinzu; eine Regel, die alles für eine Familie abdeckt, lässt die andere auf ihrem ursprünglichen Pfad, und das ist eine häufige Ursache für einen funktionierenden IPv4-Tunnel und eine hängende IPv6-Auflösung.

Wo das Paket am Gateway stirbt

Ist die Route korrekt und das Paket geht trotzdem nirgendwohin, kommt es am Server an und bleibt dort stehen. Vier Prüfungen decken die meisten Gateways ab.

Weiterleitung. sysctl net.ipv4.ip_forward mit Rückgabe 0 ist die klassische Antwort, und viele Distributionen stehen weiterhin standardmäßig auf 0. Es muss 1 sein, dauerhaft gesetzt in einer sysctl-Datei statt per Befehl, der beim Neustart verschwindet. IPv6-Weiterleitung ist ein eigener Schalter.

Die Filterrichtlinie. Eine FORWARD-Kette mit Standard-Drop-Richtlinie verwirft tunnellierten Verkehr, erlaubt aber Verkehr zum Host selbst, was genau zum Symptom passt. Lies das laufende Regelset, nicht eine gespeicherte Datei: nft list ruleset oder iptables -S.

Übersetzung oder Routing. Clients mit privaten Tunneladressen brauchen entweder Quell-NAT am Ausgangsinterface des Servers oder ein geroutetes Präfix, das das vorgelagerte Netz zurückzuliefern weiß. Die Wahl dazwischen folgt dem Adressplan. MASQUERADE in einem Netz zu ergänzen, das dein Präfix bereits zurückroutet, ist harmlos, aber sinnlos, und es dort wegzulassen, wo keine Route existiert, lässt Antworten an einen nicht routbaren privaten Bereich adressiert.

Der Rückweg. In gerouteten Designs braucht der vorgelagerte Router eine Route, die auf deinen Server zeigt. Das Netz des Anbieters kann das ebenfalls blockieren: Mehrere Clouds aktivieren eine Quell- und Zielprüfung an der Instanz, die Pakete still verwirft, deren Quelle nicht die eigene Adresse der Instanz ist, bis diese Prüfung deaktiviert wird.

DNS scheitert anders als Routing

Ein Paket an eine bekannte Adresse und eine Namensauflösung sind zwei verschiedene Fehler, und die Fehlermeldungen führen in entgegengesetzte Richtungen irre. Wenn ping 1.1.1.1 funktioniert und ein Browser nichts laden kann, ist die Route in Ordnung und die Namensauflösung nicht. Scheitert der Ping selbst, ist DNS irrelevant, und du bist wieder im vorigen Abschnitt.

wg-quick kann einen Resolver aus der Zeile DNS = in der Konfiguration setzen, und systemd-resolved hat sein eigenes Verhalten pro Link. Ein VPN, das den Resolver mit einer Adresse überschreibt, die nur innerhalb des Tunnels erreichbar ist, wird jede Auflösung in dem Moment scheitern lassen, in dem der Tunnel fällt, was so aussieht, als ob der Tunnel das Internet kaputt macht.

Eine Reihenfolge, die Belege liefert

Führe zuerst die Prüfung auf der Client-Seite aus, denn sie ist ein Befehl und schließt die Hälfte der Möglichkeiten aus. Bestätige dann, ob der Server überhaupt als Internet-Ausgang gedacht ist; ein Gateway für privaten Zugriff ist nicht kaputt, wenn öffentliche Ziele scheitern.

Beobachte auf dem Server die Schnittstelle, während du vom Client ein Ping sendest: tcpdump -ni wg0 icmp sollte die Anfrage zeigen, und tcpdump -ni eth0 icmp sollte zeigen, dass sie hinausgeht, übersetzt oder nicht. Erscheint sie auf dem ersten und nie auf dem zweiten, sitzt der Stopp lokal auf dem Server. Geht sie hinaus und kommt keine Antwort zurück, liegt das Problem weiter oben, und das ist ein anderes Gespräch.

Mach zum Schluss, dass die Korrektur einen Neustart übersteht. Weiterleitung gehört in eine sysctl-Datei, Firewall-Regeln in den Dienst, der sie lädt, und Client-Routen in die Konfiguration, die die Schnittstelle hochbringt, statt in eine Shell, die du vergessen wirst. Verbinde neu, wiederhole dieselben zwei Tests und bestätige, dass sich die Zähler bewegen.