TCP-restarigo ne pruvas, ke via VPN estas blokata

«Konekto restarigita, restartigado» aperas en la klienta protokolo, kaj la konkludo alvenas antaŭ la pruvo. Iu decidas, ke la reto blokas la VPN-on, aŭ ke la atestilo estas malĝusta, aŭ ke difinita lando intervenas. Restarigo estas TCP-paketo, kiu finas konekton, kaj la protokola linio notiĝas, ke via kliento ricevis unu. Ĝi nomas nek la aparaton, kiu sendis ĝin, nek la kialon.

Restarigo estas paketo, ne verdikto

TCP difinas restarigan prilaboron: segmento kun la flago RST tuj finas la konekton. La ricevanto ne intertraktas, ne reprovas kaj ne demandas kial. Ĝi raportas la restarigon kaj daŭrigas.

Tio estas ĉio, kion la kliento scias. La RST povis veni de la servilo, de prokurilo, de fajroŝirmilo aŭ de ŝarĝa balancilo, kiu perdis sian staton.

Atribuo estas aparta ekzerco. Ŝajna fontadreso en kaptaĵo ne pruvas la fizikan originon kaj diras nenion pri la politika decido malantaŭ ĝi. Mezaj aparatoj povas falsi adresojn, kaj statohavaj aparatoj povas restarigi pro tempolimo anstataŭ intence. Trakti la restarigon kiel verdikton preterlasas la parton, kie oni malkovras ĝin.

Konfirmu, kiu konekto estis restarigita

Unue kontrolu, ĉu la aktiva profilo vere uzas TCP. Restarigo sur UDP-tunelo estas sensenca, kaj protokolo de HTTP-prokurilo povas koncerni alian TCP-parton ol la VPN mem.

Notu la celon, la pordon, la tempon de la provo kaj la etapon, kiun la kliento atingis.

La etapo estas la plej utila kampo. Restarigo dum la TLS-manpremo indikas unu aron da suspektatoj; restarigo post aŭtentikigo indikas alian. Sen la etapo taŭgas ĉiu teorio.

Komparu ambaŭ finojn de la vojo

Se vi administras la servilon, komparu ĝiajn eventojn por la sama provo. Ĉu ĝi akceptis la konekton? Ĉu ĝi fermis ĝin intence? Ĉu respondo forlasis unu limon kaj neniam atingis la sekvan?

Kaptu ĉe la kliento kaj ĉe la servilo, se vi povas. Restarigo, kiu aperas ĉe la kliento sed ne ĉe la servilo, ne originiĝis ĉe la servilo.

Atentu RST-segmentojn en ambaŭ direktoj:

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

Malvastigu per kontrolita komparo

Dua aprobita reto povas diri al vi, ĉu la malsukceso sekvas la klienton aŭ la vojon. Se la sama profilo funkcias aliloke, la klienta agordo verŝajne estas en ordo kaj la variablo estas la vojo.

Tio ankoraŭ ne identigas unu mezaparaton. Ĝi malvastigas la amplekson al itinero, kio estas utila kaj honesta rezulto.

Konservu la distingon inter «ĉi tiu vojo malsukcesas» kaj «ĉi tiu nomita aganto kaŭzis ĝin». La unua estas testebla; la dua kutime ne el unu kliento.

Kontrolu la riparon sen ŝanĝi fidoagordojn

Ne malŝaltu TLS-kontroladon, ne regeneru akreditaĵojn kaj ne anoncu blokadan politikon el unu restariga linio. Ĉiu el tiuj ŝanĝoj ŝanĝas la testatan sistemon kaj igas la sekvan komparon sensignifa.

Riparu la identigitan komponanton per ĝia posedanto, poste ripetu la saman profilon kaj la saman observon:

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

La utila rezulto estas pli bone lokigita malsukceso, ne pli certa rakonto. Se la restarigo malaperas post prokurila riparo, vi havas kaŭzon. Se ĝi moviĝas al alia etapo, vi lernis ion pri la vojo. Ĉiuokaze la pruvo devus elteni legadon de dua persono. Skribu, kion vi observis, ne kion vi konkludis.