VPN trennt ständig? Arbeiten Sie sich in dieser Reihenfolge durch

Notieren Sie das Intervall, den Client-Fehler und den Netzwerkzustand, bevor Sie etwas ändern. Der Abstand zwischen den Abbrüchen zeigt, welche von vier Ebenen Sie prüfen müssen.

Bevor Sie den Client neu installieren, notieren Sie drei Dinge: wie lange der Tunnel stand, was der Client beim Abbruch gesagt hat und ob der Rechner zwischendurch geschlafen oder das Netz gewechselt hat. Diese Notiz ist der einzige Beweis, den Sie später haben, und eine Neuinstallation löscht sie meist. Ein Abbruch in wiederkehrendem Intervall ist ein Timer oder ein ablaufender Zustand; ein Abbruch zu einem zufälligen Zeitpunkt ist ein Wegproblem. Die Reihenfolge unten bewahrt Sie davor, drei Dinge auf einmal zu ändern und nichts zu lernen.

Schritt eins: Intervall und Fehlertext festhalten

Beginnen Sie mit dem eigenen Log des Clients statt mit dem Dashboard des Anbieters. Auf einem Linux-Client decken das Dienst-Log plus der Live-Zustand des Tunnels das meiste ab:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Notieren Sie die Zeitstempel des letzten erfolgreichen Handshakes und den Moment, in dem der Verkehr stoppte, nicht nur den Moment, in dem das Symbol die Farbe wechselte. Ein GUI-Client, der im Nachhinein getrennt meldet, gibt möglicherweise einen Zustand an, den der Kernel Sekunden früher erreicht hat.

Behalten Sie den Wortlaut des Fehlers. Ein Timeout, eine abgelehnte Authentifizierung und ein Adapter- oder Treiberfehler zeigen auf drei verschiedene Ebenen, und der meiste verschwendete Aufwand in diesem Problem entsteht daraus, sie als eines zu behandeln. Kopieren Sie die Zeile wortgleich in Ihre Notiz.

Schritt zwei: eine Variable ändern, nicht das Profil

Halten Sie Gerät und Profil fest und bringen Sie den Rechner in ein anderes Zugangsnetz, etwa einen Handy-Hotspot. Das ist der billigste Test, der den Client vom Weg trennt. Lassen Sie ihn lange genug laufen, um das ursprüngliche Fehlerintervall abzudecken; zwei stabile Minuten beweisen nichts über einen Abbruch in der dreißigsten Minute.

Ein Laptop mit Ethernet-Port liefert einen zweiten Vergleich, der Wi-Fi völlig aus dem Bild nimmt. Hält der Tunnel auf beiden Alternativen, verdient das ursprüngliche Zugangsnetz Aufmerksamkeit: Roaming zwischen Access Points, ein Heimrouter mit ablaufender Übersetzungstabelle oder eine Upstream-Strecke, die langlebige Flüsse zurücksetzt.

Notieren Sie, welche Variable Sie geändert haben. Ein Vergleich zählt nur, wenn alles andere gleich geblieben ist, und das schließt den Server-Endpunkt und die Tageszeit ein.

Schritt drei: das Intervall einer Ebene zuordnen

Die Länge einer guten Sitzung ist die aussagekräftigste einzelne Zahl, die Sie haben. Lesen Sie sie gegen diese Liste, bevor Sie Timer anfassen:

  • Abbruch nach Ruhezustand oder Aufwachen: hat der Tunnelzustand das Aussetzen überlebt, die Schnittstelle aber nicht. Prüfen Sie das Wiederverbindungsverhalten des Clients beim Aufwachen und ob der Dienst den Tunnel neu startet oder auf Verkehr wartet.
  • Abbruch nur im Leerlauf: ist in der Mitte etwas abgelaufen, das den Fluss beendet hat. Genau für diesen Fall gibt es Keepalives.
  • Abbruch bei festem Sitzungsalter: ein Ereignis der erneuten Authentifizierung oder Schlüsselerneuerung, kein Wegfehler. Eine ausdrückliche Ablehnung im Log genau in diesem Intervall ist der Hinweis.
  • Abbruch bei großen Übertragungen oder großen Seiten: Verdacht auf MTU und Fragmentierung, nicht auf einen Leerlauftimer.

Für den Leerlauffall sind die Einstellungen protokollspezifisch und beide Seiten zählen. Das keepalive 10 60 von OpenVPN auf dem Server schickt alle 10 Sekunden einen Ping und startet die Verbindung nach 60 Sekunden ohne einen neu; WireGuard-Clients hinter NAT nutzen PersistentKeepalive = 25 im Peer-Block. OpenVPN handelt auch den Datenkanal per Timer neu aus, reneg-sec, der in 2.x standardmäßig 3600 Sekunden beträgt.

Kopieren Sie keine aggressiven Werte aus der Anleitung eines anderen Anbieters. Ein kurzer Timeout auf einer verlustbehafteten Mobilfunkstrecke erzeugt genau die Abbrüche, die er verhindern sollte, und vom Server gesendete Werte überschreiben, was Sie im Client-Profil setzen.

Schritt vier: eine unterstützte Alternative vergleichen

Wenn der Betreiber sowohl ein UDP- als auch ein TCP-Profil veröffentlicht, testen Sie dasselbe Gerät und Netz gegen das andere. Verwenden Sie die tatsächlich passende Datei, statt den Transport in einem kopierten Profil zu bearbeiten. Ein stabiles TCP-Profil auf einem Weg, auf dem UDP zurückgesetzt wird, engt das Problem auf diesen Weg ein; es beweist nicht, dass TCP überall der bessere Transport ist.

Dieselbe Logik gilt für Endpunkte. Probieren Sie einen anderen Server und legen Sie das ursprüngliche Ergebnis daneben. Wenn nur ein Ausgang Sitzungen zurücksetzt, ist das ein Beleg über diesen Endpunkt, kein Grund, jeden Adapter am Laptop neu aufzubauen.

Wiederholen Sie nach jedem Wechsel den ursprünglichen Auslöser und bestätigen Sie, wohin der Verkehr tatsächlich geht. Wiedergewonnener Internetzugang ist nicht dasselbe Ergebnis wie Verkehr im Tunnel, und ein Client, der still auf eine direkte Route zurückgefallen ist, wirkt im Browser gesund.

Prüfen Sie die Korrektur und behalten Sie den Rückweg

Eine Korrektur wird geprüft, indem der ursprüngliche Auslöser reproduziert wird, nicht durch eine erfolgreiche Verbindung. Lassen Sie den Tunnel über das alte Fehlerintervall hinaus im Leerlauf, setzen Sie ihn einmal aus und fort, und prüfen Sie danach das Alter des Handshakes und die Ausgangsadresse:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Behalten Sie das vorherige Profil und die vorherigen Timerwerte, bis das neue Verhalten einen vollen Arbeitstag übersteht. Kehren die Abbrüche zurück, stellen Sie die Sicherung wieder her und wenden Sie dann die Änderungen einzeln erneut an, damit der zweite Versuch von einem bekannten Zustand startet.

Bleibt das Log sauber und bricht der Tunnel weiterhin in wiederkehrendem Intervall ab, ist der nächste Halt die Serverseite für diese Sitzung. Nehmen Sie die Sitzungskennung des Clients und den genauen Abbruchzeitpunkt mit, denn genau dieses Paar macht ein Server-Log durchsuchbar. Die Link-Optionen des Protokolls sind im OpenVPN-2.6-Handbuch dokumentiert, wenn Sie die genaue Bedeutung eines Werts brauchen.

Ähnliche Artikel