En TCP-reset bevisar inte att din VPN blockeras

”Anslutningen återställs, startar om” visas i klientloggen, och slutsatsen kommer före beviset. Någon bestämmer att nätet blockerar VPN:en, eller att certifikatet är fel, eller att ett visst land blandar sig i. En reset är ett TCP-paket som avslutar en anslutning, och loggraden registrerar att din klient tog emot ett. Den namnger inte enheten som skickade det eller orsaken.

En reset är ett paket, inte en dom

TCP definierar reset-hantering: ett segment med RST-flaggan avslutar anslutningen omedelbart. Mottagaren förhandlar inte, försöker inte igen och frågar inte varför. Den rapporterar resetten och går vidare.

Det är allt klienten vet. RST kan ha kommit från servern, en proxy, en brandvägg eller en lastbalanserare som tappade sitt tillstånd.

Tillskrivning är en egen övning. En skenbar källadress i en inspelning är inte bevis för det fysiska ursprunget och säger ingenting om policybeslutet bakom. Mellanliggande enheter kan förfalska adresser, och tillståndsbaserade enheter kan återställa vid timeout i stället för med avsikt. Att behandla resetten som en dom hoppar över delen där du tar reda på det.

Bekräfta vilken anslutning som återställdes

Kontrollera först att den aktiva profilen verkligen använder TCP. En reset på en UDP-tunnel är meningslös, och en logg från en HTTP-proxy kan gälla ett annat TCP-ben än VPN:en själv.

Notera destination, port, tidpunkt för försöket och den fas klienten hade nått.

Fasen är det mest användbara fältet. En reset under TLS-handskakningen pekar på en grupp misstänkta; en reset efter autentisering pekar på en annan. Utan fasen passar vilken teori som helst.

Jämför båda ändarna av vägen

Om du administrerar servern, jämför dess händelser för samma försök. Tog den emot anslutningen? Stängde den den med avsikt? Lämnade ett svar en gräns och nådde aldrig nästa?

Fånga vid klienten och vid servern om du kan. En reset som syns vid klienten men inte vid servern uppstod inte vid servern.

Håll utkik efter RST-segment i båda riktningarna:

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

Begränsa med en kontrollerad jämförelse

Ett andra godkänt nät kan berätta om felet följer klienten eller vägen. Om samma profil fungerar någon annanstans är klientkonfigurationen förmodligen okej, och vägen är variabeln.

Det identifierar fortfarande inte en enda mellanliggande enhet. Det begränsar omfattningen till en rutt, vilket är ett användbart och ärligt resultat.

Behåll skillnaden mellan den här vägen misslyckas och den här namngivna aktören orsakade det. Det första är testbart; det andra vanligtvis inte från en enda klient.

Kontrollera åtgärden utan att ändra förtroendeinställningar

Stäng inte av TLS-verifieringen, generera inte om autentiseringsuppgifter och tillkännage inte en blockeringspolicy utifrån en enda resetrad. Var och en av dessa ändringar ändrar systemet som testas och gör nästa jämförelse meningslös.

Åtgärda den identifierade komponenten via dess ägare och upprepa sedan samma profil och samma observation:

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

Det användbara resultatet är ett bättre lokaliserat fel, inte en mer självsäker historia. Om resetten försvinner efter en proxyåtgärd har du en orsak. Om den flyttar till en annan fas har du lärt dig något om vägen. Oavsett vilket bör beviset klara att en andra person läser det. Skriv ner vad du observerade, inte vad du drog för slutsats.