WireGuard sendet Daten, erhält aber nichts zurück: welche Seite?

Sendezähler, die steigen, während der Empfangszähler auf null bleibt, beschreiben eine Richtung, keine Diagnose. Dieselbe Anzeige erscheint, wenn der Peer nie einen Handshake abgeschlossen hat, wenn das Ziel den falschen Peer gewählt hat, wenn die Gegenseite keine Route zurück hat und wenn ein Filter die Antwort auf dem Heimweg verwirft. Jeder dieser Fälle wird an einer anderen Stelle repariert.

Der Vergleich, der die Arbeit verkürzt, gilt einer Anfrage, die den Tunnel nie verließ, und einer Antwort, die nie zurückkam. Eine Aufzeichnung auf der richtigen Schnittstelle entscheidet zwischen beiden.

Zähler beschreiben Volumen, nicht die Richtung des Fehlers

Die Zähler von WireGuard halten fest, was die Schnittstelle an den Peer übergab und was sie von ihm empfing. Sie sagen nicht, welches Ziel, welcher Peer oder welche Hälfte eines Austauschs fehlgeschlagen ist. Hintergrundverkehr macht die Summen noch weniger aussagekräftig, da einige Bytes Keepalives oder unzusammenhängende Flüsse sein können. Lesen Sie sie als Hinweis, dass die Schnittstelle aktiv ist, und behandeln Sie sie danach nicht mehr als Beweis.

Der nützliche erste Befund ist, ob ein Handshake aktuell ist. Ohne ihn wurde für diesen Peer nichts verschlüsselt, und der Empfangszähler hat keinen Grund, sich zu bewegen.

Peer-Auswahl oder Rückweg der Antwort: zwei Erklärungen

Die erste Erklärung ist, dass das Paket den beabsichtigten Peer nie erreichte, weil die Route woanders hin zeigte oder die erlaubten Präfixe des Peers das Ziel nicht abdeckten. Die zweite ist, dass das Paket ankam und die Antwort nicht zurückkehren konnte, was ein Routingproblem am fernen Ende ist. Die Tabelle trennt beide danach, was Sie an jedem Punkt beobachten würden.

Lesen Sie die Tabelle von oben. Ein fehlender Handshake führt Sie zu Schlüsseln, Endpunkten und dem äußeren Weg, weil es sonst noch nichts zu untersuchen gibt. Ein aktueller Handshake mit sichtbarer Anfrage auf dem Server verlagert das Problem in die Rückrichtung, wo die eigene Routentabelle des Ziels entscheidet. Eine Anfrage, die nie auf dem Server erscheint, ist ein Auswahlproblem, und die erlaubten Präfixe auf beiden Peers sind das Erste, was zu vergleichen ist.

Zwei dieser vier Zeilen werden auf dem Client repariert und zwei auf dem Server. Zu wissen, in welchem Paar Sie stecken, ist der größte Teil der Arbeit.

Wo Antworten verschwinden

Eine Antwort verlässt das Ziel, erreicht die Tunnelschnittstelle des Servers und wird für den Peer verschlüsselt, dessen erlaubte Adressen zur inneren Adresse des Clients passen. Scheitert diese Übereinstimmung, wird die Antwort stillschweigend verworfen, was von der Clientseite genau wie ein Netzwerkfehler aussieht. Ist die Antwort verschlüsselt und lehnt der eigene Filter des Clients sie ab, ist das Symptom erneut identisch. Beide Fälle brauchen die Aufzeichnung statt des Zählers.

Die stärkste Form dieses Fehlers ist ein Server, der Pakete für den Client weiterleitet, aber keine Route zurück in den inneren Bereich des Clients hat. Er nimmt die Anfrage an, schickt die Antwort zu seinem Standard-Gateway, und der Tunnel sieht sie nie. Eine breite Übersetzungsregel auf dem Server verdeckt diesen Fehler, statt die Route zu reparieren.

Testen Sie ein Ziel von Ende zu Ende

Wählen Sie ein einzelnes Ziel innerhalb des Peer-Bereichs und testen Sie es, während ein Handshake nachweislich aktuell ist. Die folgenden Befehle lesen den Peer-Zustand, die gewählte Route und beide Seiten des Austauschs. Führen Sie die Aufzeichnung auf der Schnittstelle aus, die die verschlüsselten Pakete tatsächlich nutzen.

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

Eine Aufzeichnung, die die Anfrage auf der Tunnelschnittstelle zeigt, ohne dass etwas zurückkommt, ist eine Antwort von der Serverseite, und die Routentabelle des Ziels ist der nächste Ort zum Nachsehen. Erscheint überhaupt nichts, hat das Paket einen anderen Weg genommen, also ist die lokale Route verdächtig. Ein in beiden Aufzeichnungen sichtbarer Austausch ohne Fortschritt in der Anwendung verschiebt die Frage auf die Paketgröße oder auf einen Filter, den die Schnittstellenstatistik nie zeigt. Halten Sie ein Ziel und einen Client im Test, weil eine zweite Variable Belege wieder in einen Eindruck verwandelt.

Wenn Namen scheitern, während eine erlaubte Adresse funktioniert, liegt die Antwort im DNS und nicht im Tunnel. Wenn nur große Übertragungen stocken, prüfen Sie die Paketgröße getrennt.