Een TCP-reset bewijst niet dat je VPN wordt geblokkeerd

„Verbinding gereset, opnieuw starten“ verschijnt in de clientlog, en de conclusie komt vóór het bewijs. Iemand besluit dat het netwerk de VPN blokkeert, of dat het certificaat verkeerd is, of dat een bepaald land zich ermee bemoeit. Een reset is een TCP-pakket dat een verbinding beëindigt, en de logregel legt vast dat je client er een heeft ontvangen. Hij noemt niet het apparaat dat hem heeft verzonden of de reden.

Een reset is een pakket, geen vonnis

TCP definieert de afhandeling van een reset: een segment met de RST-vlag beëindigt de verbinding onmiddellijk. De ontvanger onderhandelt niet, probeert het niet opnieuw en vraagt niet waarom. Hij meldt de reset en gaat verder.

Dat is alles wat de client weet. De RST kan van de server, een proxy, een firewall of een load balancer die zijn toestand kwijt was, zijn gekomen.

Toeschrijving is een aparte oefening. Een schijnbaar bronadres in een opname is geen bewijs van de fysieke oorsprong en zegt niets over de beleidsbeslissing erachter. Tussenliggende apparaten kunnen adressen vervalsen, en stateful apparaten kunnen resetten door een time-out in plaats van met opzet. Een reset als vonnis behandelen slaat het deel over waarin je erachter komt.

Bevestig welke verbinding werd gereset

Controleer eerst of het actieve profiel echt TCP gebruikt. Een reset op een UDP-tunnel heeft geen zin, en een log van een HTTP-proxy kan een ander TCP-deel betreffen dan de VPN zelf.

Noteer de bestemming, de poort, het tijdstip van de poging en de fase die de client had bereikt.

De fase is het nuttigste veld. Een reset tijdens de TLS-handshake wijst op één groep verdachten; een reset na authenticatie op een andere. Zonder de fase past elke theorie.

Vergelijk beide uiteinden van het pad

Als je de server beheert, vergelijk dan de gebeurtenissen voor dezelfde poging. Accepteerde hij de verbinding? Sloot hij die met opzet? Verliet een antwoord de ene grens en bereikte het nooit de volgende?

Leg vast bij de client en bij de server als je kunt. Een reset die bij de client verschijnt maar niet bij de server, is niet bij de server ontstaan.

Let op RST-segmenten in beide richtingen:

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

Beperk met een gecontroleerde vergelijking

Een tweede goedgekeurd netwerk kan je vertellen of de fout de client of het pad volgt. Als hetzelfde profiel elders werkt, is de clientconfiguratie waarschijnlijk in orde en is het pad de variabele.

Dat identificeert nog geen enkele tussenliggend apparaat. Het beperkt de omvang tot een route, wat een nuttig en eerlijk resultaat is.

Houd het onderscheid tussen dit pad faalt en deze genoemde actor heeft het veroorzaakt. Het eerste is testbaar; het tweede meestal niet vanuit één client.

Controleer de oplossing zonder vertrouwensinstellingen te wijzigen

Schakel TLS-verificatie niet uit, genereer geen inloggegevens opnieuw en kondig geen blokkeerbeleid aan op basis van één resetregel. Elk van die wijzigingen verandert het systeem dat je test en maakt de volgende vergelijking zinloos.

Herstel het geïdentificeerde onderdeel via de eigenaar en herhaal daarna hetzelfde profiel en dezelfde waarneming:

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

Het nuttige resultaat is een beter gelokaliseerde fout, geen zelfverzekerder verhaal. Als de reset na een proxyherstel verdwijnt, heb je een oorzaak. Als hij naar een andere fase verschuift, heb je iets over het pad geleerd. Hoe dan ook, het bewijs moet een tweede lezer kunnen doorstaan. Schrijf op wat je hebt waargenomen, niet wat je hebt geconcludeerd.