Prečo portál s povolením prístupu blokuje váš VPN a ako sa znova prihlásiť

V otvorenej sieti prístupový bod jednoducho neodovzdáva pakety internetu. Politický bod vyššie kontroluje, či je zariadenie už autorizované, a kým nie je, takmer všetko sa zahadzuje. Váš VPN klient číta to ticho ako mŕtvy server. Zriedka to povie: WireGuard opakuje podanie ruky do prázdna, OpenVPN hlási vypršanie času spojenia a IKEv2 sa vracia ako chyba 809 o vzdialenom serveri, ktorý neodpovedá.

Čo portál skutočne kontroluje

Portál s povolením prístupu sú dve veci zlepené dokopy: rozhodovací bod politiky a presmerúvač. Keď sa zariadenie pridruží a vezme si DHCP prenájom, sieť vás postaví do stavu pred autorizáciou.

Ten stav je sada pravidiel firewallu. Zvyčajne prepúšťa DNS a povoľuje HTTP alebo HTTPS na krátky zoznam hostiteľov portálu a všetko ostatné zahadzuje. Povolený zoznam je ohradená záhrada a takmer nikdy neobsahuje koncový bod VPN.

Žiadne z týchto zahadzovaní nie je zdvorilé. Pakety smerované na server VPN sa zahadzujú namiesto odmietnutia, takže klient nedostane ani ICMP unreachable, ani TCP reset, len absenciu odpovede. Podľa výrobcu môže presmerúvač odpovedať na porte 80 presmerovaním na prihlasovaciu stránku, zatiaľ čo port 443 sa zahadzuje alebo zachytáva. Presmerovania sa dajú ľahko rozpoznať, pretože nesú obyčajnú odpoveď HTTP; zachytenie na 443 vyžaduje certifikát, ktorému váš prehliadač odmietne dôverovať.

Samotná autorizácia je zvyčajne naviazaná na MAC adresu zariadenia, niekedy na prenajatú IP, a žije v tabuľke relácií s časovačom. Prihlásenie vytvorí záznam. Pravidlo firewallu, ktoré prepúšťa váš tok, existuje len dovtedy, kým existuje ten záznam, a preto sa celý problém neskôr vráti bez toho, aby sa na vašej strane čokoľvek zmenilo.

Prečo podanie ruky VPN zomrie skôr, než začne

Každý protokol má vlastný transport a firewall pred autorizáciou každý rozbíja inak. IKEv2 v Windows a iOS ide cez UDP 500 a UDP 4500; zahodenie na týchto portoch sa prejaví ako 809 alebo ako zlyhanie typu rozlíšenia mien u klientov, ktoré hlásia fázy oddelene. OpenVPN cez UDP 1194 zostáva v stave pripájania, kým mu nevyprší čas. OpenVPN cez TCP 443 je zaujímavý prípad, pretože portál môže dokončiť TCP podanie ruky a potom odpovedať svojou stránkou presmerovania, takže vidíte chybu TLS namiesto vypršania času.

WireGuard ukazuje mechanizmus najjasnejšie. Je navrhnutý len na UDP, bez TCP zálohy, takže firewall zahadzujúci neznáme UDP transport úplne odstráni. Klient ďalej posiela začiatky podania ruky s rastúcou pauzou a hlási podanie ruky, ktoré sa nikdy nedokončí. Nič v tej správe nespomína Wi-Fi a nič v nej nenaznačuje, že by ste mali otvoriť prehliadač.

Platformy sa snažia všimnúť si stav skôr ako váš VPN. Windows si vyžiada známu URL, aby rozhodol, či zobrazí oznámenie o prihlásení, Android žiada koncový bod, ktorý by mal odpovedať 204 No Content, a zariadenia Apple otvárajú malé okno siete s povolením prístupu. Tie sondy fungujú preto, lebo portál odpovedá presmerovaním namiesto očakávaného tela. Rovnaké správanie vysvetľuje, ako môže portál vyzerať úplne zdravo, keď je váš tunel mŕtvy: sonda a tunel sa hodnotia podľa rôznych pravidiel.

Čo vypršanie relácie naozaj resetuje

Miesta ukončujú relácie z dôvodov nesúvisiacich s vaším VPN účtom: časový limit nečinnosti, maximálna dĺžka relácie, nový DHCP prenájom alebo opätovné pridruženie k inému prístupovému bodu. Keď časovač zaberie, záznam v tabuľke relácií zmizne a sada pravidiel pred autorizáciou sa vráti presne taká, aká bola pri prihlásení.

Nadviazaný tunel často prežije dosť dlho na to, aby vyzeral zdravo. Správy o udržiavaní spojenia stále odchádzajú a to, či si to klient všimne, závisí od toho, ako sa správa k toku bez odpovede, takže kontrolka stavu môže ešte chvíľu zostať zelená po tom, čo cesta zmizla. Potom tunel padne a každý pokus o opätovné pripojenie zlyhá na tých istých zablokovaných portoch.

V tej chvíli vám chyba klienta povie, v ktorej fáze ste, ak si ju pozorne prečítate:

Jeden detail ľudí mýli: keď je relácia naviazaná na MAC adresu, opätovné načítanie prihlasovacej stránky nemusí pomôcť. Musíte zrušiť pridruženie a znova sa pripojiť, aby portál videl nový pokus o autorizáciu namiesto vypršaného.

Najprv sa prihláste, potom zdvihnite tunel

Poradie, ktoré funguje, je: autorizujte zariadenie, dokážte cestu, spustite VPN, dokážte tunel a potom obnovte svoje obvyklé blokovanie. Ten posledný krok je dôležitý, pretože dočasný stav, ktorý potrebujete na dosiahnutie portálu, je presne ten stav, ktorému má núdzový vypínač zabrániť.

Klient pre stolný počítač s možnosťou blokovať mimo tunela musí byť pozastavený, aby sa stránka portálu načítala, a citlivé aplikácie držte zatvorené v tom okne mimo tunela; je to jediný interval, keď lokálny tok odchádza bez ochrany. Spravované zariadenie, ktoré je stále zapnuté, by malo použiť postup, ktorý zverejnil jeho vlastník, namiesto toho, aby ste politiku odstraňovali vy. Ak portál zobrazí upozornenie na certifikát, zastavte: jeho prijatie vedie reláciu cez zachytávajúcu proxy miesta a tá proxy môže čítať všetko, čo posielate. Na Androide blokovanie pod stále zapnutým VPN zastaví tok predtým, než tunel stúpne, a niektoré zostavy nevedia vylúčiť tok portálu; ak to vaša nevie, použite alternatívny prístup miesta alebo iné zariadenie namiesto toho, aby ste blokovanie nechali vypnuté. Pravidlá on-demand od Apple sa dajú napísať tak, aby tunel odmietli, kým sonda neuspeje, a to je správanie, ktoré chcete v hotelových sieťach.

Overte v poradí nástrojmi, ktoré už máte. Pred tunelom spustite sondu s viditeľnými hlavičkami aj telom a pozrite sa, či transport VPN dostáva vôbec nejakú odpoveď:

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'

Pred autorizáciou dá bežný portál jednu z dvoch odpovedí: 302, ktorého Location ukazuje na prihlasovaciu stránku, alebo 200 s telom HTML, ktoré je stránkou portálu. Poznamenajte si, ktorú ste dostali. Presmerovanie pred prihlásením nie je zlyhanie; portál vám hovorí, kam ísť. Keď portál nahlási úspech, zopakujte príkaz a očakávajte 200, ktorého telom je doslova slovo Success. Práve ten reťazec robí sondu zmysluplnou. Ak hostiteľ odpovedá normálne skôr, než ste sa niekedy prihlásili, v tejto sieti nie je zachytávajúci portál. V zázname je zahodenie pred autorizáciou odchádzajúce pakety, z ktorých sa nič nevráti, zatiaľ čo fungujúca cesta ukáže odpoveď na ten istý tok približne do sekundy. Pripojte sa a potom záznam zopakujte.

Ak tunel stále zlyháva, keď portál povie áno

Úspešné prihlásenie nie je to isté ako povolený transport. Mnohé miesta povoľujú portál a bežné prehliadanie, ale úplne blokujú UDP, čo nechá WireGuard a OpenVPN cez UDP pokazené a TCP 443 funguje. Ak TCP 443 prechádza a UDP nie, je to politika miesta a nie klient, ktorý ste zle nakonfigurovali, takže zmeňte transport alebo prijmite limit a pokračujte. Ak opätovné pripojenie potom stále zlyháva, uchovajte presnú chybu; pomenúva fázu, v ktorej ste uviazli.

Iné zlyhania žijú v zariadení. Relácia stále naviazaná na starú MAC, druhý Wi-Fi adaptér s vlastným prenájmom alebo klient, ktorý si uložil výnimku certifikátu portálu, môžu každý ďalej zlyhávať po čistej opätovnej autorizácii. Zrušte pridruženie, autorizujte znova a skúste raz, než sa dotknete nastavení klienta. RFC 8952 stojí za prečítanie, ak chcete architektúru za komponentmi, ktoré sledujete.

Ak samotný portál odmietne autorizovať, problém je v účte alebo v pridelení zariadenia a žiadne nastavenie VPN to neopraví. Zmena výstupnej krajiny VPN neresetuje lokálny stav prístupu miesta; tá tabuľka je naviazaná na vaše zariadenie, nie na server, ktorý si vyberiete. Spýtajte sa operátora miesta a dajte mu čas, pretože pozerať sa bude na tabuľku relácií.

Pred ďalšou cestou si zapíšte tri veci: stránku portálu ako nultý krok, krok pozastavenia blokovania pre každé zariadenie, ktoré si beriete, a jeden záložný transport, ktorý ste naozaj otestovali. Keď sa tunel, ktorý fungoval pred desiatimi minútami, znova zastaví, berte to ako vypršanú autorizáciu a pred dotykom profilu VPN portál znova skontrolujte.