VPN bricht bei großen Uploads ab: zuerst die Warteschlange lesen

Der Tunnel ist den ganzen Tag stabil und bricht dann ab, sobald ein großer Upload beginnt. Interaktive Anfragen stocken zuerst, der Client meldet eine Zeitüberschreitung, und die Verbindung kommt zurück, wenn die Übertragung endet. Dieses Muster deutet auf Warteschlangen und Verarbeitung hin und nicht auf einen ausgefallenen entfernten Server, denn dem Server wurde nie die Chance gegeben, rechtzeitig zu antworten. Die Aufgabe ist, das unter kontrollierter Last zu reproduzieren und die richtigen Zähler zu lesen.

Ändern Sie pro Lauf eine Variable und halten Sie den Endpunkt fest.

Einen wiederholbaren Lastvergleich aufbauen

Zeichnen Sie eine Grundlinie bei leerer Verbindung auf: Umlaufzeit, einige Anwendungsanfragen und das Ereignisprotokoll des Tunnels selbst. Starten Sie dann einen Upload bekannter Größe und wiederholen Sie genau diese Messungen, während er läuft. Halten Sie Endpunkt, Client und Testziel unverändert, denn zwei davon gleichzeitig zu ändern sagt Ihnen nichts.

Notieren Sie, welches Ereignis zuerst erscheint. Eine steigende Umlaufzeit vor jedem Fehler deutet auf Warteschlangen hin; eine harte Zeitüberschreitung bei stabiler Latenz deutet auf etwas anderes hin, etwa einen Schlüsselwechsel oder eine Maßnahme am Konto. Beide Muster führen zu unterschiedlichen nächsten Schritten. Schreiben Sie die Beobachtung auf, bevor Sie etwas ändern.

Speichern Sie die Ausgabe mit Zeitstempeln, damit sich der belastete und der leere Lauf Zeile für Zeile vergleichen lassen.

Die Warteschlange lesen, nicht die Geschwindigkeit

Consumer-Anschlüsse puffern Pakete in der Ausrüstung des Anbieters, und eine volle Upstream-Warteschlange verzögert alles, auch die kleinen Kontrollpakete, die einen Tunnel am Leben halten. Ein Geschwindigkeitstest mit hoher Zahl sagt wenig über diese Verzögerung, weshalb ein Test im Leerlauf besteht, während eine gesättigte Verbindung scheitert.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Vergleichen Sie die Latenzwerte unter Last mit denen im Leerlauf. Ein Sprung von Dutzenden Millisekunden auf Hunderte ohne Paketverlust ist Warteschlange; Verlust bei stabiler Latenz deutet auf einen anderen Fehler hin.

Gerät und Steuerpfad prüfen

Verschlüsselung und Weiterleitung kosten Prozessorzeit, und ein kleiner Router oder ein thermisch gedrosseltes Notebook kann Pakete verwerfen, während es beschäftigt ist. Beobachten Sie die Gesamtlast statt den Prozentwert eines Prozesses, denn Weiterleitung im Kernel und Interrupt-Behandlung erscheinen nicht dort, wo man gewöhnlich hinsieht.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Eine Client-Zeitüberschreitung kann auch mit einem geplanten Schlüsselwechsel oder mit einem Ereignis der Sitzungsrichtlinie zusammenfallen. Lesen Sie das eigene Protokoll des Clients für die Reihenfolge der Ereignisse, nicht nur die Fehlermeldung der Anwendung.

Eine Sache ändern und wiederholen

Wo die Plattform es unterstützt, begrenzen Sie die Upload-Rate oder klassifizieren Sie Massenverkehr unterhalb des interaktiven Verkehrs, damit die Warteschlange nie vollläuft. Wiederholen Sie dann die identische Arbeitslast und vergleichen Sie dieselben drei Zahlen wie zuvor. Eine Änderung, die einen Geschwindigkeitstest verbessert, aber die Zeitüberschreitung stehen lässt, hat nichts repariert.

Zeitüberschreitungen flächendeckend anzuheben und die Verschlüsselung zu schwächen sind die beiden Änderungen, die das Symptom verschwinden lassen, ohne die Grenze zu benennen, die versagt hat. Keine von beiden ist eine Reparatur. Beide verschieben den Fehler nach hinten, wo er schwerer zuzuordnen ist.

Schließen Sie ab, indem Sie eine frische Anfrage und das Wiederverbindungsverhalten testen, auf das der Nutzer tatsächlich angewiesen ist. Stabilität unter der Last, die die Beschwerde ausgelöst hat, ist das einzige Ergebnis, das es festzuhalten lohnt.