Ein TCP-reset beviser ikkje at VPN-en din blir blokkert

«Tilkoplinga blir nullstilt, startar på nytt» viser seg i klientloggen, og konklusjonen kjem før beviset. Nokon avgjer at nettet blokkerer VPN-en, eller at sertifikatet er feil, eller at eit bestemt land blandar seg inn. Ein reset er ein TCP-pakke som avsluttar ei tilkopling, og logglinja registrerer at klienten din tok imot ein. Ho nemner ikkje eininga som sende han, eller årsaka.

Ein reset er ein pakke, ikkje ein dom

TCP definerer resethandsaming: eit segment med RST-flagg avsluttar tilkoplinga med det same. Mottakaren forhandlar ikkje, prøver ikkje på nytt og spør ikkje kvifor. Han rapporterer resetten og går vidare.

Det er alt klienten veit. RST kan ha kome frå serveren, ein proxy, ein brannmur eller ein lastbalanserar som mista tilstanden.

Tilskriving er ei eiga øving. Ei tilsynelatande kjeldeadresse i eit opptak er ikkje bevis for den fysiske opphavet og seier ingenting om politikkavgjerda bak. Mellomliggande einingar kan forfalske adresser, og tilstandsbaserte einingar kan nullstille ved timeout i staden for med vilje. Å handsame resetten som ein dom hoppar over delen der du finn det ut.

Stadfest kva tilkopling som vart nullstilt

Sjekk først at den aktive profilen faktisk brukar TCP. Ein reset på ein UDP-tunnel gir ingen meining, og ein logg frå ein HTTP-proxy kan gjelde eit anna TCP-bein enn VPN-en sjølv.

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

Fasen er det mest nyttige feltet. Ein reset under TLS-handtrykket peikar på eitt sett mistenkte; ein reset etter autentisering peikar på eit anna. Utan fasen passar kvar teori.

Samanlikn begge endane av vegen

Viss du administrerer serveren, samanlikn hendingane hans for same forsøket. Godtok han tilkoplinga? Lukka han ho med vilje? Forlét eit svar éi grense og nådde aldri den neste?

Ta opp ved klienten og ved serveren viss du kan. Ein reset som viser seg ved klienten men ikkje ved serveren, oppstod ikkje ved serveren.

Sjå etter RST-segment i begge retningar:

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

Avgrens med ein kontrollert samanlikning

Eit anna godkjent nett kan fortelje deg om feilen følgjer klienten eller vegen. Viss same profil verkar andre stader, er klientkonfigurasjonen truleg i orden, og vegen er variabelen.

Det identifiserer framleis ikkje éi mellomliggande eining. Det avgrensar omfanget til ein rute, som er eit nyttig og ærleg resultat.

Hald skiljet mellom denne vegen feilar og denne namngjetne aktøren forårsaka det. Det første er testbart; det andre vanlegvis ikkje frå éin klient.

Kontroller rettinga utan å endre tillitsinnstillingar

Ikkje slå av TLS-verifisering, generer ikkje legitimasjon på nytt, og kunngjer ikkje ein blokkeringspolicy ut frå éi resetlinje. Kvar av desse endringane endrar systemet som blir testa og gjer den neste samanlikninga meiningslaus.

Rett den identifiserte komponenten via eigaren, og gjenta deretter same profil og same observasjon:

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

Det nyttige resultatet er ein betre lokalisert feil, ikkje ei meir sjølvsikker historie. Viss resetten forsvinn etter ei proxyretting, har du ei årsak. Viss han flyttar til ein annan fase, har du lært noko om vegen. Uansett bør beviset tole at ein annan person les det. Skriv ned det du observerte, ikkje det du konkluderte.