Hindi pinatutunayan ng TCP reset na naka-block ang VPN mo

Lumilitaw sa client log ang «connection reset, restarting», at dumarating ang konklusyon bago ang ebidensya. May nagpapasyang hinaharangan ng network ang VPN, o mali ang certificate, o may isang partikular na bansa na nakikialam. Ang reset ay isang TCP packet na nagtatapos ng connection, at itinatala ng log line na nakatanggap ang client mo ng isa. Hindi nito pinapangalanan ang device na nagpadala nito o ang dahilan.

Ang reset ay isang packet, hindi hatol

Tinutukoy ng TCP ang pagproseso ng reset: isang segment na may RST flag ang nagtatapos ng connection agad. Hindi nakikipagnegosasyon ang receiver, hindi na nagtatangkang muli at hindi nagtatanong kung bakit. Iniulat nito ang reset at nagpapatuloy.

Iyon lang ang alam ng client. Maaaring nagmula ang RST sa server, sa isang proxy, sa isang firewall o sa isang load balancer na nawalan ng state.

Ang pag-attribute ay hiwalay na pagsasanay. Ang maliwanag na source address sa isang capture ay hindi patunay ng pisikal na pinagmulan at walang sinasabi tungkol sa desisyon sa patakaran sa likod nito. Maaaring magpeke ng address ang mga intermediate device, at ang mga device na may state ay maaaring mag-reset dahil sa timeout kaysa sa sinasadya. Ang ituring na hatol ang reset ay lumalaktaw sa bahagi kung saan mo ito nalalaman.

Tiyakin kung aling connection ang na-reset

Unang tingnan kung talagang gumagamit ng TCP ang aktibong profile. Walang saysay ang reset sa isang UDP tunnel, at ang log mula sa isang HTTP proxy ay maaaring tungkol sa ibang TCP leg kaysa sa VPN mismo.

Itala ang destinasyon, port, oras ng pagtatangka at ang yugtong naabot ng client.

Ang yugto ang pinakakapaki-pakinabang na field. Ang reset habang nagaganap ang TLS handshake ay tumuturo sa isang grupo ng mga suspek; ang reset pagkatapos ng authentication ay tumuturo sa iba. Kung walang yugto, lahat ng teorya ay umaangkop.

Ihambing ang dalawang dulo ng landas

Kung ikaw ang nag-aadministra ng server, ihambing ang mga kaganapan nito para sa parehong pagtatangka. Tinanggap ba nito ang connection? Sinadya ba nitong isara ito? Umalis ba ang isang tugon sa isang hangganan at hindi kailanman umabot sa susunod?

Kumuha ng capture sa client at sa server kung kaya mo. Ang reset na lumilitaw sa client ngunit wala sa server ay hindi nagmula sa server.

Magbantay sa mga RST segment sa dalawang direksyon:

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

Paliitin gamit ang kontroladong paghahambing

Ang isang pangalawang aprubadong network ay makapagsasabi kung ang kabiguan ay sumusunod sa client o sa landas. Kung gumagana ang parehong profile sa ibang lugar, malamang maayos ang configuration ng client at ang landas ang variable.

Hindi pa nito tinutukoy ang isang partikular na intermediate device. Pinapaliit nito ang saklaw sa isang ruta, na kapaki-pakinabang at tapat na resulta.

Panatilihin ang pagkakaiba ng «nabibigo ang landas na ito» at «ang pinangalanang aktor na ito ang naging dahilan». Ang una ay masusubok; ang pangalawa ay karaniwang hindi mula sa isang client.

Suriin ang pagtatama nang hindi binabago ang mga setting ng pagtitiwala

Huwag i-disable ang TLS verification, huwag muling gumawa ng credentials at huwag magpahayag ng patakaran sa pagharang batay sa isang linya ng reset. Binabago ng bawat isa sa mga pagbabagong iyon ang sistemang sinusubukan at ginagawang walang saysay ang susunod na paghahambing.

Ayusin ang natukoy na component sa pamamagitan ng may-ari nito, pagkatapos ulitin ang parehong profile at parehong obserbasyon:

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

Ang kapaki-pakinabang na resulta ay isang mas mahusay na lokasyon ng kabiguan, hindi isang mas kumpiyansang kuwento. Kung mawala ang reset pagkatapos ng pagtatama sa proxy, mayroon kang dahilan. Kung lumipat ito sa ibang yugto, may natutunan ka tungkol sa landas. Alinman sa dalawa, dapat makayanan ng ebidensya ang pagbasa ng pangalawang tao. Isulat ang iyong naobserbahan, hindi ang iyong hinihinuha.