Atvirame tinkle jūsų prieigos taškas paprasčiausiai neperduoda paketų internetui. Politikos taškas aukščiau tikrina, ar jūsų įrenginys jau autorizuotas, ir kol ne, beveik viskas išmetama. Jūsų VPN klientas tą tylą skaito kaip negyvą serverį. Jis retai tai pasako: WireGuard kartoja rankos paspaudimą į tuštumą, OpenVPN praneša apie ryšio laiko limitą, o IKEv2 grįžta su 809 klaida apie neatsakantį nuotolinį serverį.

Ką portalas iš tikrųjų kontroliuoja

Belaisvis portalas yra du suklijuoti dalykai: politikos sprendimo taškas ir peradresuotojas. Kai jūsų įrenginys prisijungia ir gauna DHCP nuomą, tinklas pastato jus į būseną prieš autorizaciją.

Ta būsena yra ugniasienės taisyklių rinkinys. Paprastai jis leidžia DNS ir leidžia HTTP arba HTTPS į trumpą portalo hostų sąrašą, o visa kita išmeta. Leidžiamas sąrašas yra aptvertas sodas, ir jame beveik niekada nėra VPN galinio taško.

Nė vienas iš šių išmetimų nėra mandagus. Į VPN serverį nukreipti paketai išmetami, o ne atmetami, todėl klientas negauna nei ICMP unreachable, nei TCP reset, tik atsakymo nebuvimą. Priklausomai nuo gamintojo, peradresuotojas gali atsakyti į 80 prievadą peradresavimu į prisijungimo puslapį, o 443 prievadas išmetamas arba perimamas. Peradresavimus lengva pastebėti, nes jie neša paprastą HTTP atsakymą; perėmimui 443 prievade reikia sertifikato, kuriuo jūsų naršyklė atsisakys pasitikėti.

Pati autorizacija paprastai susieta su įrenginio MAC adresu, kartais su išnuomotu IP, ir ji gyvena sesijų lentelėje su laikmačiu. Prisijungimas sukuria įrašą. Ugniasienės taisyklė, leidžianti jūsų srautui praeiti, egzistuoja tik tol, kol egzistuoja tas įrašas, ir todėl visa problema grįžta vėliau, niekam nepasikeitus jūsų pusėje.

Kodėl VPN rankos paspaudimas miršta prieš prasidedant

Kiekvienas protokolas turi savo transportą, o ugniasienė prieš autorizaciją kiekvieną laužo skirtingai. IKEv2 Windows ir iOS sistemose keliauja per UDP 500 ir UDP 4500; išmetimas šiuose prievaduose pasireiškia kaip 809 arba kaip vardų sprendimo tipo gedimas klientuose, kurie etapus praneša atskirai. OpenVPN per UDP 1194 lieka jungimosi būsenoje, kol baigiasi jo laiko limitas. OpenVPN per TCP 443 yra įdomus atvejis, nes portalas gali užbaigti TCP rankos paspaudimą ir tada atsakyti savo peradresavimo puslapiu, todėl matote TLS klaidą, o ne laiko limitą.

WireGuard parodo mechanizmą aiškiausiai. Jis pagal dizainą yra tik UDP, be TCP atsarginio varianto, todėl ugniasienė, išmetanti nežinomą UDP, visiškai pašalina transportą. Klientas toliau siunčia rankos paspaudimo inicijavimus su didėjančia pauze ir praneša apie rankos paspaudimą, kuris niekada nebaigiamas. Niekas toje žinutėje nemini Wi-Fi, ir niekas joje nesiūlo atidaryti naršyklės.

Platformos stengiasi pastebėti būseną anksčiau nei jūsų VPN. Windows gauna žinomą URL, kad nuspręstų, ar rodyti prisijungimo pranešimą, Android prašo galinio taško, kuris turėtų atsakyti 204 No Content, o Apple įrenginiai atidaro mažą belaisvio tinklo langą. Tie zondai veikia todėl, kad portalas atsako peradresavimu, o ne laukiamu turiniu. Ta pati elgsena paaiškina, kaip portalas gali atrodyti visiškai sveikas, kai jūsų tunelis negyvas: zondas ir tunelis vertinami pagal skirtingas taisykles.

Ką sesijos pasibaigimas iš tikrųjų atstato

Vietos nutraukia sesijas dėl priežasčių, nesusijusių su jūsų VPN paskyra: neveiklumo laiko limitas, maksimali sesijos trukmė, nauja DHCP nuoma arba prisijungimas prie kito prieigos taško. Kai suveikia laikmatis, įrašas sesijų lentelėje dingsta, o taisyklių rinkinys prieš autorizaciją grįžta lygiai toks, koks buvo registruojantis.

Nustatytas tunelis dažnai išgyvena pakankamai ilgai, kad atrodytų sveikas. Gyvybės palaikymo pranešimai toliau išeina, o ar klientas tai pastebi, priklauso nuo to, kaip jis elgiasi su neatsakytu srautu, todėl būsenos lemputė gali kurį laiką likti žalia po to, kai kelias dingo. Tada tunelis krenta, ir kiekvienas bandymas prisijungti iš naujo nepavyksta tuose pačiuose užblokuotuose prievaduose.

Tuo metu kliento klaida pasako, kuriame etape esate, jei atidžiai perskaitysite:

SymptomWhat it meansNext check
Handshake times out with no replyPre-authorization drop on UDPLoad any HTTP page and see whether the portal appears
Immediate TLS error on 443The portal answered your TCP connectionAuthorize, then retry the same profile
Authentication rejectedYour credentials reached the serverThe network is fine, so treat this as an account problem
Connects, then drops repeatedlySession or lease churnWatch the portal timer and the lease time

Viena detalė klaidina žmones: kai sesija susieta su MAC adresu, prisijungimo puslapio perkrovimas gali nepadėti. Turite atjungti susiejimą ir prisijungti iš naujo, kad portalas matytų naują autorizacijos bandymą, o ne pasibaigusį.

Pirmiausia prisijunkite, tada kelkite tunelį

Veikianti tvarka: autorizuokite įrenginį, įrodykite kelią, paleiskite VPN, įrodykite tunelį, tada atkurkite savo įprastą blokavimą. Tas paskutinis žingsnis svarbus, nes laikina būsena, kurios reikia pasiekti portalą, yra būtent ta būsena, kurią avarinis jungiklis egzistuoja, kad užkirstų kelią.

Darbalaukio klientas su parinktimi blokuoti už tunelio turi būti pristabdytas, kad įkeltų portalo puslapį, o jautrias programas reikėtų laikyti uždarytas tame už tunelio esančiame intervale; tai vienintelis intervalas, kai vietinis srautas išeina neapsaugotas. Valdomas visada įjungtas įrenginys turėtų naudoti procedūrą, kurią paskelbė jo savininkas, o ne jūsų šalinamą politiką. Jei portalas rodo sertifikato įspėjimą, sustokite: jį priėmus sesija keliauja per vietos perėmimo tarpinį serverį, o tas tarpinis serveris gali skaityti viską, ką siunčiate. Android sistemoje užraktas su visada įjungtu VPN blokuoja srautą prieš pakeliant tunelį, o kai kurie rinkiniai negali išskirti portalo srauto; jei jūsų negali, naudokite alternatyvų vietos prisijungimą arba kitą įrenginį, o ne palikite užraktą išjungtą. Apple reikalavimo taisyklės gali būti parašytos taip, kad atmestų tunelį, kol zondas nepavyks, ir tai yra elgsena, kurios norite viešbučių tinkluose.

Tikrinkite iš eilės turimais įrankiais. Prieš tunelį paleiskite zondą su matomais ir antraštėmis, ir turiniu, ir stebėkite, ar jūsų VPN transportas apskritai gauna atsakymą:

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'

Prieš autorizaciją įprastas portalas duoda vieną iš dviejų atsakymų: 302, kurio Location rodo į prisijungimo puslapį, arba 200 su HTML turiniu, kuris yra portalo puslapis. Užsirašykite, kurį gavote. Peradresavimas prieš prisijungimą nėra gedimas; portalas jums sako, kur eiti. Kai portalas praneša apie sėkmę, pakartokite komandą ir tikėkitės 200, kurio turinys yra pažodžiui žodis Success. Būtent ši eilutė daro zondą prasmingą. Jei hostas atsako įprastai dar prieš jums kada nors prisijungus, šiame tinkle nėra perėmimo portalo. Įraše išmetimas prieš autorizaciją yra išeinantys paketai, iš kurių niekas negrįžta, o veikiantis kelias rodo atsakymą į tą patį srautą maždaug per sekundę. Prisijunkite ir pakartokite įrašą.

Jei tunelis vis tiek nepavyksta po to, kai portalas pasako taip

Prisijungimo sėkmė nėra tas pats, kas leidžiamas transportas. Daugelis vietų leidžia portalą ir įprastą naršymą, bet visiškai blokuoja UDP, todėl WireGuard ir UDP OpenVPN lieka sulaužyti, o TCP 443 veikia. Jei TCP 443 praeina, o UDP ne, tai yra vietos politika, o ne jūsų neteisingai sukonfigūruotas klientas, todėl pakeiskite transportą arba priimkite ribą ir eikite toliau. Jei prisijungimas iš naujo vis tiek nepavyksta, išsaugokite tikslią klaidą; ji įvardija etapą, kuriame įstrigote.

Kiti gedimai gyvena įrenginyje. Sesija, vis dar susieta su senu MAC, antras Wi-Fi adapteris su savo nuoma arba klientas, kuris išsaugojo portalo sertifikato išimtį, gali toliau nepavykti po švarios pakartotinės autorizacijos. Atjunkite susiejimą, autorizuokite iš naujo ir pabandykite kartą prieš liesdami kliento nustatymus. RFC 8952 verta perskaityti, jei norite architektūros, kuri yra už stebimų komponentų.

Jei pats portalas atsisako autorizuoti, problema yra paskyroje arba įrenginio paskirstyme, ir joks VPN nustatymas to nepataisys. VPN išėjimo šalies pakeitimas neatstato vietos vietinės prieigos būsenos; ta lentelė susieta su jūsų įrenginiu, o ne su pasirinktu serveriu. Paklauskite vietos operatoriaus ir duokite jam laiko, nes sesijų lentelė yra tai, į ką jis žiūrės.

Prieš kitą kelionę užsirašykite tris dalykus: portalo puslapį kaip nulinį žingsnį, blokavimo pristabdymo žingsnį kiekvienam vežamam įrenginiui ir vieną atsarginį transportą, kurį tikrai išbandėte. Kai tunelis, kuris veikė prieš dešimt minučių, vėl sustoja, traktuokite tai kaip pasibaigusią autorizaciją ir dar kartą patikrinkite portalą prieš liesdami VPN profilį.

Susiję straipsniai