WireGuard funktioniert erst, nachdem der Server sendet: Wissen über den Endpunkt

Der Tunnel scheint erst zu funktionieren, nachdem der Server zuerst etwas sendet. Starten Sie vom Client aus, und es passiert nichts, warten Sie ein paar Sekunden, versuchen Sie es erneut, und es klappt. Die übliche Diagnose ist ein defektes NAT, und die übliche Diagnose ist falsch. Geändert hat sich, dass ein Peer gelernt hat, wo der andere wohnt.

Wissen über den Endpunkt, nicht Erreichbarkeit

Ein WireGuard-Peer beginnt keinen Handshake, bis er weiß, wohin er ihn schicken soll. Die Konfiguration liefert das als Endpunkt aus Adresse und Port, und der laufende Zustand verfolgt den Endpunkt, an den er gerade glaubt.

wg show zeigt beide Seiten dieses Bildes, und ein Peer ohne Endpunkt in der Ausgabe kann nichts beginnen, so korrekt sein öffentlicher Schlüssel und seine erlaubten Präfixe auch sind. Vergleichen Sie die Sicht des Clients mit der des Servers, bevor Sie irgendeine Regel ändern, denn die beiden sind sich oft uneinig darüber, wer was weiß.

Wie ein Peer einen Endpunkt lernt

WireGuard ist bewusst still. Wenn ein korrekt authentifiziertes Paket von einer Adresse ankommt, die der Peer nicht erwartet hat, aktualisiert die Implementierung den Endpunkt dieses Peers auf die neue Quelle, und so funktioniert Roaming auf einem Laptop, der das Netz wechselt. Dieses Verhalten erklärt die Richtungsabhängigkeit: Wenn der Server zuerst sendet und sein Paket den Client erreicht, lernt der Client die aktuelle Adresse des Servers und kann antworten. Bis dahin hat er kein Ziel. Der Mechanismus ist authentifiziertes Roaming und keine Abkürzung nach dem Muster Vertrauen beim ersten Gebrauch, denn das Paket musste gültig sein, bevor sich der Endpunkt bewegte.

Die Werkzeugdokumentation zu wg beschreibt diese Aktualisierung, und sie lohnt sich einmal zu lesen, wenn Sie darum herum entwerfen wollen.

Zustandsbehaftete Übersetzung bringt ihre eigene Richtung mit

Wo UDP ein übersetzendes Gateway passiert, legt das Gateway Zustand für das erste Paket an, das es sieht. RFC 4787 beschreibt dieses Verhalten und die Zeitlimits, die die Zuordnung schließlich entfernen. Eine untätige Zuordnung läuft ab, und ein eingehendes Paket von der Gegenseite wird dann vom Gateway verworfen, bevor es den Host erreicht. Ein Tunnel, der den ganzen Vormittag lief, antwortet am Nachmittag genau aus diesem Grund nicht mehr.

Dies ist ein zweiter und unabhängiger Mechanismus, der dasselbe richtungsabhängige Symptom erzeugt. Wissen über den Endpunkt und Übersetzungszustand müssen beide stimmen, und das eine zu reparieren repariert das andere nicht.

Konfigurieren Sie die Richtung, die Sie tatsächlich wollen

Für einen Client, der die Verbindung beginnen muss, setzen Sie den Endpunkt des Servers in den Peer-Abschnitt des Clients und lassen ihn dort. Sich darauf zu verlassen, dass der Server zuerst sendet, heißt, sich auf einen Zufall in der Verkehrsreihenfolge zu verlassen, der sich in einem ruhigen Netz ändern wird. Die Konfiguration sollte die beabsichtigte Richtung angeben, nicht entdecken.

Für einen Peer hinter einer Übersetzung, der erreichbar bleiben muss, aktivieren Sie auf dieser Seite ein dauerhaftes Keepalive. Ein Keepalive alle 25 Sekunden ist der übliche Startwert, und sein Zweck ist, die Zuordnung offen zu halten, nicht den Tunnel zu testen. Wählen Sie eine Seite, die es trägt, denn die Aktivierung auf beiden Seiten verdoppelt den Verkehr und das Lograuschen, ohne das Ergebnis zu verbessern.

Vergleichen Sie den Zustand vor und nach dem Auslöser

Erfassen Sie die beiden Ansichten in dem Moment, in dem es scheitert, und dann erneut, nachdem der Server gesendet hat. Der erste Befehl zeigt Endpunkte und das Alter des Handshakes. Der zweite zeigt, ob für den Port ein Übersetzungseintrag existiert. Die Aufzeichnung zeigt, welche Richtung tatsächlich über die Leitung ging, und die Routenprüfung bestätigt, dass der Client diesen Verkehr nicht ganz woanders hin schickt.

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Notieren Sie die Endpunktspalte und den Übersetzungseintrag zusammen. Ein Peer ohne Endpunkt und ein Gateway ohne Zuordnung sind zwei verschiedene Fehler. Nur einer von ihnen wird durch ein Keepalive behoben.