En TCP-reset beviser ikke, at din VPN bliver blokeret

Forbindelsen nulstilles, genstarter står i klientloggen, og konklusionen kommer før beviset. Nogen beslutter, at netværket blokerer VPN’en, eller at certifikatet er forkert, eller at et bestemt land blander sig. En reset er en TCP-pakke, der afslutter en forbindelse, og loglinjen registrerer, at din klient modtog en. Den navngiver ikke enheden, der sendte den, eller årsagen.

En reset er en pakke, ikke en dom

TCP definerer resetbehandling: et segment med RST-flaget afslutter forbindelsen med det samme. Modtageren forhandler ikke, prøver ikke igen og spørger ikke hvorfor. Den rapporterer resetten og går videre.

Det er alt, klienten ved. RST kan være kommet fra serveren, en proxy, en firewall eller en load balancer, der mistede tilstand.

Tilskrivning er en separat øvelse. En tilsyneladende kildeadresse i en optagelse er ikke bevis for den fysiske oprindelse og siger intet om den politikbeslutning, der ligger bag. Mellemliggende enheder kan forfalske adresser, og stateful enheder kan nulstille ved timeout i stedet for med vilje. At behandle resetten som en dom springer den del over, hvor du finder ud af det.

Bekræft, hvilken forbindelse der blev nulstillet

Kontrollér først, at den aktive profil faktisk bruger TCP. En reset på en UDP-tunnel giver ingen mening, og en log fra en HTTP-proxy kan vedrøre et andet TCP-ben end VPN’en selv.

Notér destination, port, forsøgstidspunkt og den fase, klienten havde nået.

Fasen er det mest nyttige felt. En reset under TLS-håndtrykket peger på ét sæt mistænkte; en reset efter godkendelse peger på et andet. Uden fasen passer enhver teori.

Sammenlign begge ender af ruten

Hvis du administrerer serveren, sammenlign så dens hændelser for det samme forsøg. Accepterede den forbindelsen? Lukkede den den med vilje? Forlod et svar én grænse og nåede aldrig den næste?

Optag ved klienten og ved serveren, hvis du kan. En reset, der vises ved klienten men ikke ved serveren, opstod ikke ved serveren.

Hold øje med RST-segmenter i begge retninger:

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

Indsnævr med en kontrolleret sammenligning

Et andet godkendt netværk kan fortælle, om fejlen følger klienten eller ruten. Hvis den samme profil virker andre steder, er klientkonfigurationen sandsynligvis i orden, og ruten er variablen.

Det identificerer stadig ikke én mellemliggende enhed. Det indsnævrer omfanget til en rute, hvilket er et nyttigt og ærligt resultat.

Bevar forskellen mellem denne rute fejler og denne navngivne aktør forårsagede det. Det første er testbart; det andet normalt ikke fra én klient.

Kontrollér rettelsen uden at ændre tillidsindstillinger

Slå ikke TLS-verifikation fra, genopret ikke legitimationsoplysninger, og annoncer ikke en blokeringspolitik ud fra én resetlinje. Hver af disse ændringer ændrer det system, der testes, og gør den næste sammenligning meningsløs.

Ret den identificerede komponent via dens ejer, og gentag derefter den samme profil og den samme observation:

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

Det nyttige resultat er en bedre lokaliseret fejl, ikke en mere selvsikker historie. Hvis resetten forsvinder efter en proxyrettelse, har du en årsag. Hvis den flytter til en anden fase, har du lært noget om ruten. Uanset hvad bør beviset kunne overleve, at en anden person læser det. Skriv ned, hvad du observerede, ikke hvad du konkluderede.