Zwei Sekunden Hänger: VPN oder WLAN?
Ein zwei Sekunden langer Stillstand und eine neue VPN-Sitzung sind verschiedene Ereignisse. Legen Sie den Zugangsweg und den Tunnel auf getrennte Zeitachsen, bevor Sie einen Timer ändern.
Ein Hänger von zwei Sekunden, der sich von selbst erholt, sieht identisch aus, egal ob der Tunnel neu verhandelt wurde oder das Funkmodul gestockt hat. Es ist auch möglich, dass überhaupt nichts abgebrochen ist, und diese Möglichkeit sollte man zuerst prüfen. Ein kurzer Paketverlust, eine Neuverhandlung und ein Anwendungsstau fühlen sich für die Person an der Tastatur gleich an. Nur einer dieser drei Fälle wird durch Ändern der Tunnelkonfiguration behoben.
Zwei Protokolle statt einem
Notieren Sie, was mit der Verbindung darunter geschah, und getrennt davon, was der Tunnel selbst tat. Dann legen Sie die Pause der Anwendung an beide Aufzeichnungen an. Das sind unabhängige Ereignisreihen, die manchmal zusammenfallen, und alle drei als Verbindungsabbruch zu bezeichnen, setzt die Antwort schon am Anfang voraus.
Eine Überwachung, die einmal pro Minute prüft, kann eine Unterbrechung von zwei Sekunden nicht sehen. Den Tag als gesund zu melden ist technisch korrekt und praktisch nutzlos. Schreiben Sie das Abtastintervall neben jedes Ergebnis, das Sie zitieren.
Was der Zugangsweg tat, während die App hing
Abtastintervall und Timeout legen fest, was die Überwachung überhaupt beobachtet haben kann; halten Sie beides neben dem Ergebnis fest. Eine festgehaltene Abwesenheit von Ausfällen bedeutet wenig, wenn das Messinstrument alle sechzig Sekunden abtastet. Prüfen Sie dann drei Stellen mit Zeitstempeln: den lokalen Router, einen freigegebenen externen Host über den einfachen Pfad und eine Ressource hinter dem Tunnel.
Bestätigen Sie zuerst die Routen, denn ein öffentliches Ziel kann selbst durch den Tunnel geroutet sein und misst dann den Tunnel statt des Zugangswegs. Die Belege, die den Ausfall wirklich datieren, liegen eine Ebene tiefer: Link-Ereignisse am Router, Resync-Einträge am Modem und eine WAN-Adresse, die sich geändert hat. Ein kumulativer Fehlerzähler sagt Ihnen, dass etwas schiefging, nie wann. Bringen Sie diese Aufzeichnungen mit dem Vorfallfenster in Zusammenhang, statt sie isoliert zu lesen.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showEin Zähler, der gestern gestiegen ist, erklärt nichts über einen Hänger heute Morgen. Begrenzen Sie die Korrelation auf das Fenster, das der Nutzer gemeldet hat.
Suchen Sie den Neustart-Eintrag
Ein verlorenes UDP-Datagramm allein bringt Community OpenVPN nicht dazu, eine neue TLS-Aushandlung zu beginnen. Das Neustartverhalten folgt ping-restart, und der wirksame Wert kann vom Server vorgegeben worden sein; das Handbuch zu 2.6 definiert diese Timer. Die Zustellung bricht kurz ab, der Schwellenwert wird nie erreicht, und das Log bleibt leer. Suchen Sie daher im Log um die Pause herum nach einer Neustartzeile, einem neuen Verbindungsaufbau oder einer geänderten Sitzungskennung. Wenn keines der drei auftaucht, hat der Tunnel wahrscheinlich nichts getan und der Timer war nie das Problem.
Jedes Keepalive zu kürzen lässt die Erkennung schneller wirken und verschiebt die Grenze, an der ein Aussetzer zum Neuverbinden wird. Jedes Neuverbinden kostet eine Authentifizierungsrunde und das Neuinstallieren der Routen. Den Timer zu verlängern bringt nichts außer einem längeren Fenster, in dem ein toter Pfad noch lebendig aussieht. Beides sind Abstimmungsentscheidungen mit einem Preis, keine kostenlosen Verbesserungen.
Auch ein fehlendes Ereignis ist ein Beleg, und es ist die Art, die man gern überspringt, weil nichts im Log darauf aufmerksam macht. Halten Sie die Suche fest, die Sie ausgeführt haben, nicht nur ihr Ergebnis.
Lassen Sie den Vergleich entscheiden, was zu reparieren ist
Liegen beide Aufzeichnungen nebeneinander, ergibt sich die Zuordnung meist von selbst. Ein Router-Link-Ereignis auf beiden Pfaden bedeutet, dass die Zugangsverbindung das Thema ist. Ein stiller Tunnel und ein brauchbarer einfacher Pfad bedeuten, dass die Aushandlung das Thema ist.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
Jede Zeile ist ein Hinweis, kein Urteil: Endpunkte stufen ICMP herab, und zwei Ziele teilen sich nicht zwangsläufig einen Pfad. Halten Sie die Uhren von Client, Gateway und Anwendung gleich, damit der Vergleich überhaupt möglich ist. Eine Zeile, die auf zwei Spalten passt, braucht eine weitere Beobachtung, keine Entscheidung.
Ein Bericht, der eine Prüfung übersteht, beantwortet vier Dinge: wie lange der Hänger dauerte, welche Pfade weiter antworteten, was der Tunnel in dieser Sekunde protokollierte und wie oft die Überwachung abtastet. Diese vier Fakten erlauben dem nächsten Leser, die Beobachtung nachzuvollziehen, statt einer Zusammenfassung zu vertrauen. Eine Verfügbarkeitsquote verbirgt genau das Intervall, das Sie interessiert, und der Satz „die VPN ist abgefallen“ ebenso.