Ein TCP-Reset beweist nicht, dass dein VPN blockiert wird

„Connection reset, restarting“ erscheint im Client-Log, und die Schlussfolgerung kommt vor dem Beweis. Jemand entscheidet, das Netz blockiere das VPN, oder das Zertifikat sei falsch, oder ein bestimmtes Land funke dazwischen. Ein Reset ist ein TCP-Paket, das eine Verbindung beendet, und die Logzeile hält fest, dass dein Client eines empfangen hat. Sie nennt weder das Gerät, das es gesendet hat, noch den Grund.

Ein Reset ist ein Paket, kein Urteil

TCP definiert die Reset-Behandlung: Ein Segment mit dem RST-Flag beendet die Verbindung sofort. Der Empfänger verhandelt nicht, versucht es nicht erneut und fragt nicht warum. Er meldet den Reset und macht weiter.

Mehr weiß der Client nicht. Der RST kann vom Server, von einem Proxy, von einer Firewall oder von einem Load Balancer kommen, der seinen Zustand verloren hat.

Die Zuordnung ist eine eigene Übung. Eine scheinbare Quelladresse in einem Mitschnitt ist kein Beweis für den physischen Ursprung und sagt nichts über die Richtlinienentscheidung dahinter. Middleboxen können Adressen fälschen, und zustandsbehaftete Geräte können bei Zeitüberschreitung zurücksetzen statt absichtlich. Wer den Reset als Urteil behandelt, überspringt den Teil, in dem man es herausfindet.

Bestätige, welche Verbindung zurückgesetzt wurde

Prüfe zuerst, ob das aktive Profil tatsächlich TCP verwendet. Ein Reset auf einem UDP-Tunnel ergibt keinen Sinn, und ein Log eines HTTP-Proxys kann ein anderes TCP-Teilstück betreffen als das VPN selbst.

Halte Ziel, Port, Zeitpunkt des Versuchs und die Phase fest, die der Client erreicht hatte.

Die Phase ist das nützlichste Feld. Ein Reset während des TLS-Handshakes deutet auf eine Gruppe von Verdächtigen; ein Reset nach der Authentifizierung auf eine andere. Ohne die Phase passt jede Theorie.

Vergleiche beide Enden des Pfads

Wenn du den Server administrierst, vergleiche seine Ereignisse für denselben Versuch. Hat er die Verbindung angenommen? Hat er sie absichtlich geschlossen? Hat eine Antwort eine Grenze verlassen und die nächste nie erreicht?

Zeichne beim Client und beim Server auf, wenn du kannst. Ein Reset, der beim Client erscheint, beim Server aber nicht, ist nicht beim Server entstanden.

Achte auf RST-Segmente in beide Richtungen:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Grenze es mit einem kontrollierten Vergleich ein

Ein zweites freigegebenes Netz kann dir sagen, ob der Fehler dem Client oder dem Pfad folgt. Wenn dasselbe Profil anderswo funktioniert, ist die Client-Konfiguration wahrscheinlich in Ordnung, und der Pfad ist die Variable.

Das benennt noch keine einzelne Middlebox. Es engt den Bereich auf eine Route ein, was ein nützliches und ehrliches Ergebnis ist.

Halte den Unterschied zwischen „dieser Pfad scheitert“ und „dieser benannte Akteur hat es verursacht“ fest. Ersteres ist prüfbar; Letzteres meist nicht von einem einzelnen Client aus.

Prüfe die Korrektur, ohne Vertrauenseinstellungen zu ändern

Deaktiviere nicht die TLS-Prüfung, erzeuge keine Anmeldedaten neu und verkünde keine Sperrrichtlinie aufgrund einer Reset-Zeile. Jede dieser Änderungen verändert das getestete System und macht den nächsten Vergleich bedeutungslos.

Behebe die identifizierte Komponente über ihren Eigentümer und wiederhole dann dasselbe Profil und dieselbe Beobachtung:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

Das nützliche Ergebnis ist ein besser lokalisierter Fehler, keine selbstsichere Geschichte. Wenn der Reset nach einer Proxy-Korrektur verschwindet, hast du eine Ursache. Wenn er in eine andere Phase wandert, hast du etwas über den Pfad gelernt. So oder so sollte der Beweis das Lesen durch eine zweite Person überstehen. Schreibe auf, was du beobachtet hast, nicht was du geschlossen hast.