En TCP-Reset beweist net, datt däi VPN blockéiert gëtt

„Verbindung reset, nei starten“ erschéngt am Client-Log, an d’Konklusioun kënnt virun der Bewäis. Een entscheet, datt den Netzwierk de VPN blockéiert, oder datt den Zertifika falsch ass, oder datt e bestëmmt Land sech amescht. En Reset ass en TCP-Pak, deen eng Verbindung beendet, an d’Loglinn hält fest, datt däi Client ee kritt huet. Si nennt weder d’Apparat, deen en geschéckt huet, nach de Grond.

En Reset ass en Pak, keen Urteel

TCP definéiert d’Resetbehandlung: en Segment mam RST-Fändel beendet d’Verbindung direkt. Den Empfänger verhandelt net, probéiert net nach eng Kéier a freet net firwat. En mellt den Reset a geet virun.

Dat ass alles, wat de Client weess. Den RST konnt vum Server, vun engem Proxy, vun enger Firewall oder vun engem Load Balancer kommen, dee säin Zoustand verluer huet.

D’Zouuerdnung ass eng eege Übung. Eng schäinbar Quelladress an enger Opnam ass kee Bewäis fir den physikaleschen Ursprong an seet näischt iwwer d’Politiksentscheedung dohannert. Mëttelapparater kënnen Adressen fälschen, an Apparater mat Zoustand kënnen aus Zäitiwwerschreidung zrécksetzen an net aus Absicht. Wien den Reset als Urteel behandelt, iwwerspréngt deen Deel, wou een et erausfënnt.

Bestäteg, wéi eng Verbindung zréckgesat gouf

Kuck fir d’éischt no, ob de aktive Profil tatsächlech TCP benotzt. En Reset op engem UDP-Tunnel mécht kee Sënn, an e Log vun engem HTTP-Proxy kann eng aner TCP-Streck betreffen wéi de VPN selwer.

Notéier d’Destinatioun, de Port, d’Zäit vum Versuch an d’Etapp, déi de Client erreecht hat.

D’Etapp ass dat nëtzlechst Feld. En Reset während dem TLS-Handshake weist op eng Grupp Verdächteger; en Reset no der Authentifikatioun op eng aner. Ouni d’Etapp passt all Theorie.

Vergläich béid Enner vum Wee

Wann s de Server administréiers, vergläich seng Evenementer fir dee selwechte Versuch. Huet en d’Verbindung ugeholl? Huet en se bewosst zougemaach? Huet eng Äntwert eng Grenz verlooss an déi nächst ni erreecht?

Maach eng Opnam beim Client an beim Server, wann s de kanns. En Reset, deen beim Client erschéngt, awer net beim Server, ass net beim Server entstanen.

Kuck op RST-Segmenter a béid Richtungen:

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

Grenz et mat engem kontrolléierte Vergläich an

En zweet genehmegt Netzwierk kann der soen, ob de Feeler dem Client oder dem Wee follegt. Wann dee selwechte Profil soss ewéi funktionéiert, ass d’Clientkonfiguratioun wahrscheinlech an der Rei an de Wee ass d’Variabel.

Dat identifizéiert nach ëmmer keen eenzege Mëttelapparat. Et grenzt de Beräich op eng Route an, wat en nëtzlecht an éierlecht Resultat ass.

Hal den Ënnerscheed tëscht dëse Wee fält aus an dësen genannten Acteur huet et verursaacht. Dat éischt ass testbar; dat zweet meeschtens net vun engem eenzege Client.

Préif d’Korrektur, ouni Vertrauensastellungen ze änneren

Deaktivéier net d’TLS-Préifung, generéier net d’Authentifikatiounsdaten nei a verkënneg net eng Blockéierpoliitik op Basis vun enger eenzeger Resetlinn. Jiddwereen vun dësen Ännerungen ännert de getestene System a mécht den nächste Vergläich sënnlos.

Korrigéier de identifizéierte Komponent iwwer säin Eegentemer, an widderhuel dann dee selwechte Profil an déi selwecht Observatioun:

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

Dat nëtzlecht Resultat ass e besser lokaliséierte Feeler, keng méi selbstsécher Geschicht. Wann den Reset no enger Proxykorrektur verschwënnt, hues du eng Ursaach. Wann en op eng aner Etapp wiesselt, hues du eppes iwwer de Wee geléiert. Wéi och ëmmer, d’Bewäis sollt eng zweet Persoun hir Lektür iwwerstoen. Schréif op, wat s de observéiert hues, net wat s de ofgeleet hues.