VPN trennt ständig: Prüfe das Funkmodul vor dem Server
Eine Trennung kann beginnen, lange bevor Verkehr den Server erreicht. Vergleiche Linkwechsel, Tunnelereignisse und einen alternativen Endpunkt, bevor du den Ausgang beschuldigst.
Eine VPN-Trennung kann lange beginnen, bevor irgendein Datenverkehr den Server erreicht. Wi-Fi-Verlust, ein Wechsel von Wi-Fi zu Mobilfunk, Überlastung am lokalen Zugangspunkt und ein Telefon, das einschläft, können den äußeren Pfad unterbrechen, während die Tunnelsoftware einen sauberen Fehler meldet. Arbeite dich vom Gerät nach außen: zuerst der Link, dann die Ereignisse des Clients selbst, dann ein kontrollierter Vergleich und erst danach der Server. Diese Reihenfolge bewahrt dich davor, Ausgangsknoten für ein Problem zu wechseln, das im Raum liegt.
Beobachte den Link, nicht das Signal-Symbol
Achte auf Linkwechsel statt auf Balken. Ein Gerät kann ein starkes Signal anzeigen, während der Zugangspunkt gesättigt ist, während ein Roaming-Wechsel läuft oder während eine Energiesparrichtlinie das Funkmodul bei ausgeschaltetem Bildschirm abschaltet.
Notiere den Zustand der Schnittstelle, das aktuelle Gateway und den Zeitpunkt jeder Änderung. Prüfe dann, ob die Trennung mit dem Wechsel zusammenfällt. Ein Abbruch, der jedes Mal passiert, wenn das Telefon zwischen Räumen wechselt, ist ein Linkproblem, bis das Gegenteil bewiesen ist, egal welchen Server die App anzeigt.
Lies die Wiederverbindungsereignisse des Clients
Die meisten Clients protokollieren einen Grund für die Trennung und einen Zeitstempel für den nächsten Versuch. Ein Tunnel, der innerhalb von Sekunden neu verhandelt und dann funktioniert, ist ein anderes Ereignis als einer, der unten bleibt, bis du ihn manuell umschaltest.
Wiederholte kurze Wiederverbindungen deuten auf den äußeren Pfad, weil der Client den Server ständig erreicht und die Sitzung verliert. Ein Tunnel, der unten bleibt, deutet auf Authentifizierung, einen Endpunktwechsel oder eine Richtlinie, weil der Client nicht weit genug kommt, um etwas zu verlieren. Lies die beiden Muster getrennt, bevor du die Konfiguration anfasst.
Vergleiche einen zweiten Endpunkt mit Bedacht
Ein zweiter Endpunkt ist ein nützlicher Vergleich und für sich genommen kein kontrolliertes Experiment. Er ändert die Route, die Infrastruktur und oft das Land, ein Unterschied zwischen zwei Endpunkten beweist also nicht, dass der erste Server fehlerhaft ist.
Halte Gerät, Zugangsnetz und Arbeitslast fest und notiere, was sich beim Wechsel sonst noch geändert hat. Scheitern beide Endpunkte zur selben Zeit am selben Ort, ist der lokale Pfad der gemeinsame Faktor. Scheitert nur einer, wird der Server oder die Route dorthin zur Spur. Schreibe die Störfaktoren auf, damit die Schlussfolgerung den Belegen nicht vorauseilt.
Korreliere mit dem Server, den du betreibst
Wenn du den Endpunkt administrierst, gleiche den Versuchszeitpunkt mit Listener- und Assoziationsprotokollen ab. Mehrere unabhängige Clients, die am selben Gateway scheitern, sind ein anderer Beleg als ein Telefon, das bei jeder Bewegung ausfällt.
Eine einzelne Peer-Antwort belegt keine dauerhafte Anwendungsgesundheit. Prüfe nach der Wiederherstellung die Ressource, die du wirklich brauchst, denn ein erfolgreicher Handshake und ein erreichbarer Server können mit einem kaputten Anwendungspfad zusammen bestehen.
Schreibe den Bericht, der es eingrenzt
Trenne vier Aussagen: lokaler Linkverlust, äußere Erreichbarkeit, Tunnelaushandlung und der eigene Zustand der Anwendung. Jede hat ihre eigenen Belege, und ein Bericht, der sie getrennt hält, sagt der nächsten Person, wo sie nachsehen soll.
Notiere auch die Grenzen des Vergleichs. Wenn eine Richtlinie einen Test des direkten Pfads verhindert hat, sage das, statt den Endpunktvergleich als Beweis darzustellen. Das Länderetikett in der App bezeichnet nicht die vollständige Route, und ein geografisch naher Server kann trotzdem über einen überlasteten Pfad erreichbar sein.
Die Seite des WireGuard-Projekts zu bekannten Einschränkungen ist eine nützliche Erinnerung daran, dass ein Protokoll korrekt sein und Linkverhalten trotzdem dem Betriebssystem überlassen kann. Wiederhole zum Schluss denselben Test nach der nächsten Trennung, denn ein einzelnes Ereignis ist ein Datenpunkt und ein Muster eine Diagnose.