Kial la kapta portalo baras vian VPN-on kaj kiel ensaluti denove

En malferma reto via alirpunkto ne simple transdonas paketojn al la interreto. Politika punkto pli supre kontrolas, ĉu via aparato jam estas rajtigita, kaj ĝis ĝi estos, preskaŭ ĉio estas forĵetata. Via VPN-kliento legas tiun silenton kiel mortan servilon. Ĝi malofte tion diras: WireGuard ripetas manpremon en la malplenon, OpenVPN raportas tempolimon de konekto, kaj IKEv2 revenas kiel eraro 809 pri fora servilo, kiu ne respondas.

Kion la portalo efektive regas

Kapta portalo estas du aferoj kunigitaj: politika decidpunkto kaj plusendilo. Kiam via aparato konektiĝas kaj prenas DHCP-luon, la reto metas vin en staton antaŭ rajtigo.

Tiu stato estas aro de fajroŝirmilaj reguloj. Ĝi kutime permesas DNS kaj permesas HTTP aŭ HTTPS al mallonga listo de portalaj gastigantoj, kaj ĝi forĵetas ĉion alian. La permesita listo estas la murita ĝardeno, kaj ĝi preskaŭ neniam inkluzivas VPN-finpunkton.

Neniu el tiuj forĵetoj estas ĝentila. Paketoj celantaj VPN-servilon estas forĵetataj anstataŭ rifuzataj, do la kliento ricevas nek ICMP unreachable nek TCP reset, nur la foreston de respondo. Laŭ la vendisto, la plusendilo povas respondi al pordo 80 per plusendo al la ensaluta paĝo, dum pordo 443 estas forĵetata aŭ interkaptata. Plusendoj estas facile rimarkeblaj ĉar ili portas ordinaran HTTP-respondon; interkapto ĉe 443 bezonas atestilon, kiun via retumilo rifuzos fidi.

La rajtigo mem kutime estas ligita al la MAC-adreso de la aparato, foje al la luigita IP, kaj ĝi vivas en sesia tabelo kun tempigilo. Ensaluto kreas enskribon. La fajroŝirmila regulo, kiu lasas vian trafikon tra, ekzistas nur dum tiu enskribo ekzistas, kaj tial la tuta problemo revenas poste sen ke io ajn ŝanĝiĝas ĉe vi.

Kial la VPN-manpremo mortas antaŭ ol komenciĝi

Ĉiu protokolo havas sian propran transporton, kaj la fajroŝirmilo antaŭ rajtigo rompas ĉiun malsame. IKEv2 ĉe Windows kaj iOS veturas sur UDP 500 kaj UDP 4500; forĵeto sur tiuj pordoj aperas kiel 809, aŭ kiel malsukceso de nomrezolva tipo ĉe klientoj, kiuj raportas etapojn aparte. OpenVPN super UDP 1194 restas en la konekta stato ĝis ĝia tempolimo finiĝas. OpenVPN super TCP 443 estas la interesa kazo, ĉar la portalo povas fini la TCP-manpremon kaj poste respondi per sia plusenda paĝo, do vi vidas TLS-eraron anstataŭ tempolimon.

WireGuard montras la mekanismon plej klare. Ĝi estas nur-UDP laŭ dizajno, sen TCP-rezervo, do fajroŝirmilo, kiu forĵetas nekonatan UDP, forigas la transporton tute. La kliento daŭre sendas manpremajn iniciatojn kun kreskanta paŭzo kaj raportas manpremon, kiu neniam finiĝas. Nenio en tiu mesaĝo mencias Wi-Fi, kaj nenio en ĝi sugestas, ke vi malfermu retumilon.

Platformoj provas rimarki la staton antaŭ ol via VPN. Windows prenas konatan URL por decidi, ĉu montri sian ensalutan sciigon, Android petas finpunkton, kiu devus respondi 204 No Content, kaj Apple-aparatoj malfermas malgrandan fenestron de kapta reto. Tiuj provoj funkcias ĉar la portalo respondas per plusendo anstataŭ la atendata korpo. La sama konduto klarigas, kiel portalo povas aspekti tute sana dum via tunelo estas morta: la provo kaj la tunelo estas juĝataj laŭ malsamaj reguloj.

Kion sesia finiĝo efektive restarigas

Lokoj finigas sesiojn pro kialoj ne rilataj al via VPN-konto: tempolimo de neaktiveco, maksimuma sesia longeco, nova DHCP-luo, aŭ rekonekto al alia alirpunkto. Kiam la tempigilo ekfunkcias, la sesia tabela enskribo malaperas kaj la regulo-aro antaŭ rajtigo revenas ĝuste tia, kia ĝi estis ĉe enregistriĝo.

Starigita tunelo ofte pluvivas sufiĉe longe por aspekti sana. Vivtenaj mesaĝoj daŭre eliras, kaj ĉu la kliento tion rimarkas dependas de kiel ĝi traktas sensrespondan trafikon, do la stata lumo povas resti verda dum iom da tempo post kiam la vojo malaperis. Poste la tunelo falas kaj ĉiu rekonekta provo malsukcesas sur la samaj baritaj pordoj.

En tiu punkto la klienta eraro diras al vi, en kiu etapo vi estas, se vi legas ĝin atente:

Unu detalo trompas homojn: kiam la sesio estas ligita al MAC-adreso, reŝargi la ensalutan paĝon eble ne helpos. Vi devas forigi la konekton kaj aliĝi denove, por ke la portalo vidu novan rajtigan provon anstataŭ finiĝintan.

Unue ensalutu, poste levu la tunelon

La ordo, kiu funkcias, estas: rajtigu la aparaton, pruvu la vojon, startigu la VPN-on, pruvu la tunelon, poste restarigu vian kutiman baradon. Tiu lasta paŝo gravas ĉar la provizora stato, kiun vi bezonas por atingi la portalon, estas ĝuste la stato, kiun mortigilo ekzistas por malhelpi.

Labortabla kliento kun opcio bari ekster la tunelo devas esti paŭzita por ke la paĝo de la portalo ŝarĝiĝu, kaj vi devus teni sentemajn programojn fermitaj dum tiu fenestro ekster la tunelo; ĝi estas la sola intervalo, kiam loka trafiko eliras senprotekte. Administrata aparato, kiu estas ĉiam ŝaltita, devus uzi la proceduron, kiun ĝia posedanto publikigis, anstataŭ ke vi forigu politikon. Se la portalo montras atestilan averton, haltu: akcepti ĝin direktas vian sesion tra la interkapta prokura servilo de la loko, kaj tiu prokura servilo povas legi ĉion, kion vi sendas. Sur Android la ŝloso sub ĉiam-aktiva VPN baras trafikon antaŭ ol la tunelo leviĝas, kaj kelkaj versioj ne povas escepti la portalfluon; se via ne povas, uzu la alternativan aliron de la loko aŭ alian aparaton anstataŭ lasi la ŝloson malŝaltita. La laŭpetaj reguloj de Apple povas esti skribitaj tiel, ke ili rifuzas la tunelon ĝis provo sukcesos, kaj tio estas la konduto, kiun vi volas en hotelaj retoj.

Kontrolu laŭ ordo per iloj, kiujn vi jam havas. Antaŭ la tunelo, rulu la provon kun kaj kaplinioj kaj korpo videblaj, kaj observu, ĉu via VPN-transporto ricevas ajnan respondon:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Antaŭ rajtigo, normala portalo donas unu el du respondoj: 302, kies Location montras al la ensaluta paĝo, aŭ 200 kun HTML-korpo, kiu estas la paĝo de la portalo. Notu, kiun vi ricevis. Plusendo ne estas malsukceso antaŭ ensaluto; ĝi estas la portalo, kiu diras al vi, kien iri. Post kiam la portalo raportas sukceson, ripetu la komandon kaj atendu 200, kies korpo estas la laŭvorta vorto Success. Tiu ĉeno estas tio, kio faras la provon senchava. Se la gastiganto respondas normale antaŭ ol vi iam ensalutis, ne ekzistas interkapta portalo en ĉi tiu reto. En la kaptaĵo, forĵeto antaŭ rajtigo estas eliraj paketoj, el kiuj nenio revenas, dum vojo, kiu funkcias, montras respondon al la sama fluo ene de proksimume sekundo. Konektiĝu, poste ripetu la kaptaĵon.

Se la tunelo ankoraŭ malsukcesas post kiam la portalo diras jes

Ensaluta sukceso ne samas kiel permesita transporto. Multaj lokoj permesas la portalon kaj ordinaran retumadon dum ili tute baras UDP, kio lasas WireGuard kaj UDP-OpenVPN rompitaj kaj TCP 443 funkcianta. Se TCP 443 trapasas kaj UDP ne, tio estas politiko de la loko, ne kliento, kiun vi misagordis, do ŝanĝu transporton aŭ akceptu la limon kaj pluiru. Se rekonekto ankoraŭ malsukcesas post tio, konservu la precizan eraron; ĝi nomas la etapon, en kiu vi estas blokita.

Aliaj malsukcesoj vivas en la aparato. Sesio ankoraŭ ligita al malnova MAC, dua Wi-Fi-adaptilo kun propra luo, aŭ kliento, kiu kaŝmemorigis la atestilan escepton de la portalo, ĉiu el ili povas daŭre malsukcesi post pura re-rajtigo. Forigu la konekton, re-rajtigu, kaj provu unufoje antaŭ ol tuŝi klientajn agordojn. RFC 8952 indas legi, se vi volas la arkitekturon malantaŭ la komponantoj, kiujn vi observas.

Se la portalo mem rifuzas rajtigi, la problemo estas konto aŭ aparata atribuo kaj neniu VPN-agordo riparos ĝin. Ŝanĝi la eliran landon de la VPN ne restarigas la lokan alirstaton de la loko; tiu tabelo estas ligita al via aparato, ne al la servilo, kiun vi elektas. Demandu la funkciigiston de la loko kaj donu al ĝi tempon, ĉar la sesia tabelo estas tio, kion ĝi rigardos.

Antaŭ via sekva vojaĝo, notu tri aferojn: la paĝon de la portalo kiel paŝon nulo, la paŝon paŭzi la baradon por ĉiu aparato, kiun vi portas, kaj unu rezervan transporton, kiun vi efektive testis. Kiam tunelo, kiu funkciis antaŭ dek minutoj, denove haltas, traktu ĝin kiel finiĝintan rajtigon kaj rekontrolu la portalon antaŭ ol tuŝi la VPN-profilo.