En TCP-reset beviser ikke at VPN-en din blokkeres

«Tilkoblingen nullstilles, starter på nytt» vises i klientloggen, og konklusjonen kommer før beviset. Noen bestemmer at nettet blokkerer VPN-en, eller at sertifikatet er feil, eller at et bestemt land blander seg inn. En reset er en TCP-pakke som avslutter en forbindelse, og logglinjen registrerer at klienten din mottok en. Den navngir ikke enheten som sendte den, eller årsaken.

En reset er en pakke, ikke en dom

TCP definerer resetbehandling: et segment med RST-flagget avslutter forbindelsen umiddelbart. Mottakeren forhandler ikke, prøver ikke på nytt og spør ikke hvorfor. Den rapporterer resetten og går videre.

Det er alt klienten vet. RST kan ha kommet fra serveren, en proxy, en brannmur eller en lastbalanserer som mistet tilstanden.

Tilskrivning er en egen øvelse. En tilsynelatende kildeadresse i en opptak er ikke bevis for den fysiske opprinnelsen og sier ingenting om politikkbeslutningen bak. Mellomliggende enheter kan forfalske adresser, og tilstandsbaserte enheter kan nullstille ved timeout i stedet for med vilje. Å behandle resetten som en dom hopper over delen der du finner det ut.

Bekreft hvilken forbindelse som ble nullstilt

Sjekk først at den aktive profilen faktisk bruker TCP. En reset på en UDP-tunnel gir ingen mening, og en logg fra en HTTP-proxy kan gjelde et annet TCP-bein enn VPN-en selv.

Noter destinasjon, port, tidspunkt for forsøket og fasen klienten hadde nådd.

Fasen er det mest nyttige feltet. En reset under TLS-håndtrykket peker på ett sett mistenkte; en reset etter autentisering peker på et annet. Uten fasen passer enhver teori.

Sammenlign begge ender av veien

Hvis du administrerer serveren, sammenlign hendelsene dens for samme forsøk. Godtok den forbindelsen? Lukket den den med vilje? Forlot et svar én grense og nådde aldri den neste?

Ta opp ved klienten og ved serveren hvis du kan. En reset som vises ved klienten men ikke ved serveren, oppsto ikke ved serveren.

Se etter RST-segmenter i begge retninger:

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

Begrens med en kontrollert sammenligning

Et annet godkjent nett kan fortelle deg om feilen følger klienten eller veien. Hvis samme profil virker andre steder, er klientkonfigurasjonen sannsynligvis i orden, og veien er variabelen.

Det identifiserer fortsatt ikke én mellomliggende enhet. Det begrenser omfanget til en rute, som er et nyttig og ærlig resultat.

Behold skillet mellom denne veien feiler og denne navngitte aktøren forårsaket det. Det første er testbart; det andre vanligvis ikke fra én klient.

Kontroller rettelsen uten å endre tillitsinnstillinger

Ikke slå av TLS-verifisering, generer ikke legitimasjon på nytt, og kunngjør ikke en blokkeringspolicy ut fra én resetlinje. Hver av disse endringene endrer systemet som testes og gjør den neste sammenligningen meningsløs.

Rett den identifiserte komponenten via eieren, og gjenta deretter samme profil og samme observasjon:

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

Det nyttige resultatet er en bedre lokalisert feil, ikke en mer selvsikker historie. Hvis resetten forsvinner etter en proxyrettelse, har du en årsak. Hvis den flytter til en annen fase, har du lært noe om veien. Uansett bør beviset tåle at en annen person leser det. Skriv ned det du observerte, ikke det du konkluderte.