Die öffentliche IP hat sich geändert und das VPN leitete keinen Verkehr mehr

Ein erneuter Verbindungsaufbau beim Anbieter oder eine Änderung in der Übersetzung weiter oben ändert die öffentliche Quelle einer VPN-Sitzung, während die lokale private Adresse des Clients meist genau so bleibt, wie sie war. Der Tunnel sieht dann verbunden aus, obwohl nichts Nützliches hindurchgeht. Beide Beobachtungen stimmen gleichzeitig, und genau das macht den Bericht verwirrend.

Arbeiten Sie die vier Prüfungen der Reihe nach durch und hören Sie bei der ersten auf, die fehlschlägt.

Welche Adresse sich tatsächlich geändert hat

Vergleichen Sie den Zustand der lokalen Schnittstelle mit der Quelle, die ein entferntes Gegenende sieht, an einem Punkt, an dem Sie nachsehen dürfen. Eine neue öffentliche Adresse bedeutet kein neues lokales Gateway, und eine Änderung der lokalen Schnittstelle garantiert auch nicht, dass sich die öffentliche Quelle bewegt hat. Die Übersetzung dazwischen bedeutet, dass beides unabhängige Tatsachen sind. Notieren Sie den genauen Pfad und den Zeitpunkt, zu dem Sie ihn beobachtet haben, denn ein aus einem alten Bericht kopiertes Geolokalisierungs-Label beantwortet eine andere Frage.

Fragen Sie gezielt, ob sich die äußere Quelle geändert hat, die innere Tunneladresse oder beides. Nur das Erste erklärt einen Peer, der weiterhin an einen Pfad sendet, der nicht mehr existiert.

Lassen Sie das Protokoll den Wechsel übernehmen

Protokolle unterscheiden sich darin, wie sie erfahren, dass ein Peer umgezogen ist, und der Unterschied entscheidet, ob Sie überhaupt eingreifen sollten. WireGuard aktualisiert den Endpunkt eines Peers, wenn es ein Paket empfängt, das sich mit dem Schlüssel dieses Peers authentifiziert, weshalb ein Adresswechsel ohne jede Konfiguration übernommen werden kann. IKEv2 hat MOBIKE für denselben Zweck, wo beide Seiten es unterstützen. Ältere Entwürfe erholen sich stattdessen durch einen Neuaufbau des Tunnels.

Was Sie nicht tun sollten, ist eine unauthentifizierte Nachricht als Beweis dafür zu nehmen, dass sich die Identität eines Peers verschoben hat. Ein Datagramm zu fälschen, das eine neue Adresse behauptet, ist trivial, und ein Client, der glaubt, man könne ihn zum Endpunkt eines Angreifers lenken. Das authentifizierte Protokoll ist der Mechanismus; eine Benachrichtigung ist es nicht.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Die veraltete äußere Bindung löschen

Wenn das Protokoll Roaming unterstützt und der Verkehr trotzdem scheitert, ist das Hindernis oft zustandsbehaftete Geräte auf dem Weg oder eine Richtlinie am fernen Ende. Eine Firewall, die den alten Fluss verfolgt hat, kann den veralteten Eintrag behalten, und eine serverseitige Zugriffsregel, die an die alte Quelle gebunden ist, verwirft die neue stillschweigend. Die Zuordnung zu bereinigen und die Regel erneut zu prüfen ist schneller, als Anmeldedaten zu ersetzen.

Halten Sie die erforderliche Sperre aufrecht, während Sie untersuchen. Die Richtlinie weit zu öffnen, um zu testen, ob sich der Tunnel erholt, lehrt Sie nichts über die Ursache und hinterlässt den Aufbau schlechter, als Sie ihn vorgefunden haben.

Mit einer frischen Anfrage erneut testen

Eine Anwendungssitzung, die vor der Änderung aufgebaut wurde, überlebt sie nicht, weil das Vier-Tupel, auf dem sie aufgebaut war, nicht mehr existiert. Erzeugen Sie nach der Wiederherstellung eine neue Anfrage und bestätigen Sie, dass sie abgeschlossen wird, statt zuzusehen, wie ein alter Download bei null steht, und daraus zu schließen, dass der Tunnel noch defekt ist. Genau diese Unterscheidung löst einen großen Teil dieser Berichte.

Notieren Sie dann beide Hälften der Diagnose: was sich weiter oben geändert hat und welcher unterstützte Wiederherstellungsschritt den Fluss zurückgebracht hat. Der nächste Vorfall wird schneller sein, und die Notiz ist das, was ihn schneller macht.

Wenn eine neue Anfrage gelingt und die alte nie wieder aufgenommen wird, war der Tunnel repariert, und die Anwendung muss sich lediglich neu verbinden.