Zakaj portal z zajetjem blokira vaš VPN in kako se znova prijavite

V odprtem omrežju dostopovna točka paketov preprosto ne izroči internetu. Politična točka višje preveri, ali je naprava že pooblaščena, in dokler ni, se skoraj vse zavrže. Vaš odjemalec VPN to tišino bere kot mrtev strežnik. Redko to pove: WireGuard ponavlja rokovanje v prazno, OpenVPN sporoči potek časa povezave, IKEv2 pa se vrne kot napaka 809 o oddaljenem strežniku, ki se ne odziva.

Kaj portal v resnici nadzoruje

Portal z zajetjem sta dve stvari, zlepljeni skupaj: odločitvena točka politike in preusmerjevalnik. Ko se naprava pridruži in vzame najem DHCP, vas omrežje postavi v stanje pred pooblastitvijo.

To stanje je niz pravil požarnega zidu. Običajno spusti DNS in dovoli HTTP ali HTTPS na kratek seznam gostiteljev portala, vse drugo pa zavrže. Dovoljeni seznam je obzidan vrt in skoraj nikoli ne vsebuje končne točke VPN.

Nobeno od teh zavrženj ni vljudno. Paketi, namenjeni strežniku VPN, se zavržejo namesto zavrnejo, zato odjemalec ne prejme niti ICMP unreachable niti TCP reset, le odsotnost odgovora. Glede na proizvajalca lahko preusmerjevalnik na vratih 80 odgovori s preusmeritvijo na prijavno stran, medtem ko so vrata 443 zavržena ali prestrežena. Preusmeritve je lahko prepoznati, ker nosijo običajen odgovor HTTP; prestrezanje na 443 zahteva potrdilo, ki mu vaš brskalnik ne bo zaupal.

Sama pooblastitev je običajno vezana na naslov MAC naprave, včasih na najeto IP, in živi v tabeli sej s časovnikom. Prijava ustvari vnos. Pravilo požarnega zidu, ki spusti vaš promet, obstaja le toliko časa, kolikor obstaja ta vnos, zato se vsa težava pozneje vrne, ne da bi se na vaši strani karkoli spremenilo.

Zakaj rokovanje VPN umre, preden se začne

Vsak protokol ima svoj prenos, požarni zid pred pooblastitvijo pa vsakega pokvari drugače. IKEv2 v Windows in iOS gre po UDP 500 in UDP 4500; zavrženje na teh vratih se pokaže kot 809 ali kot odpoved v slogu razreševanja imen pri odjemalcih, ki faze sporočajo ločeno. OpenVPN po UDP 1194 ostane v stanju povezovanja, dokler mu ne poteče čas. OpenVPN po TCP 443 je zanimiv primer, ker lahko portal dokonča rokovanje TCP in nato odgovori s svojo preusmeritveno stranjo, zato vidite napako TLS namesto poteka časa.

WireGuard pokaže mehanizem najjasneje. Po zasnovi je samo UDP, brez rezerve TCP, zato požarni zid, ki zavrže neznani UDP, prenos povsem odstrani. Odjemalec še naprej pošilja začetke rokovanja z naraščajočim premorom in sporoča rokovanje, ki se nikoli ne dokonča. Nič v tem sporočilu ne omenja Wi-Fi in nič v njem ne namiguje, da bi morali odpreti brskalnik.

Platforme poskušajo stanje opaziti prej kot vaš VPN. Windows pridobi znan URL, da odloči, ali naj pokaže obvestilo o prijavi, Android zahteva končno točko, ki bi morala odgovoriti 204 No Content, naprave Apple pa odprejo majhno okno omrežja z zajetjem. Te sonde delujejo, ker portal odgovori s preusmeritvijo namesto s pričakovanim telesom. Enako vedenje pojasni, kako je lahko portal videti povsem zdrav, medtem ko je vaš tunel mrtev: sonda in tunel se ocenjujeta po različnih pravilih.

Kaj potek seje v resnici ponastavi

Mesta zaključijo seje iz razlogov, ki niso povezani z vašim računom VPN: časovna omejitev nedejavnosti, največja dolžina seje, nov najem DHCP ali ponovna pridružitev drugi dostopovni točki. Ko časovnik sproži, vnos v tabeli sej izgine in niz pravil pred pooblastitvijo se vrne natanko tak, kakršen je bil ob prijavi.

Vzpostavljen tunel pogosto preživi dovolj dolgo, da je videti zdrav. Sporočila za ohranjanje življenja še naprej odhajajo, ali jih odjemalec opazi, pa je odvisno od tega, kako ravna s prometom brez odgovora, zato lahko lučka stanja ostane zelena še nekaj časa po tem, ko je pot izginila. Nato tunel pade in vsak poskus ponovne povezave spodleti na istih blokiranih vratih.

V tistem trenutku vam napaka odjemalca pove, v kateri fazi ste, če jo pozorno preberete:

Ena podrobnost zavaja ljudi: ko je seja vezana na naslov MAC, ponovno nalaganje prijavne strani morda ne pomaga. Pridružitev morate spustiti in se znova pridružiti, da portal vidi nov poskus pooblastitve namesto poteklega.

Najprej se prijavite, nato dvignite tunel

Vrstni red, ki deluje, je: pooblastite napravo, dokažite pot, zaženite VPN, dokažite tunel in nato obnovite svoje običajno blokiranje. Ta zadnji korak je pomemben, ker je začasno stanje, ki ga potrebujete za dostop do portala, natanko tisto stanje, ki mu je varnostno stikalo namenjeno, da ga prepreči.

Odjemalec za namizje z možnostjo blokiranja zunaj tunela je treba začasno ustaviti, da se stran portala naloži, občutljive programe pa imejte zaprte v tem oknu zunaj tunela; to je edini interval, ko lokalni promet odhaja brez zaščite. Upravljana naprava, ki je vedno vklopljena, bi morala uporabiti postopek, ki ga je objavil lastnik, namesto da vi odstranite politiko. Če portal pokaže opozorilo o potrdilu, se ustavite: njegova sprejem vas usmeri skozi prestrezni posrednik mesta, ta posrednik pa lahko prebere vse, kar pošljete. V Androidu zaklep pod vedno vklopljenim VPN ustavi promet, preden se tunel dvigne, in nekatere gradnje ne morejo izvzeti toka portala; če vaša ne more, uporabite nadomestni dostop mesta ali drugo napravo, namesto da zaklep pustite izklopljen. Pravila on-demand podjetja Apple je mogoče napisati tako, da tunel zavrnejo, dokler sonda ne uspe, in to je vedenje, ki ga želite v hotelskih omrežjih.

Preverite po vrsti z orodji, ki jih že imate. Pred tunelom zaženite sondo tako, da so vidne glave in telo, in poglejte, ali prenos VPN sploh dobi kakšen odgovor:

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 pooblastitvijo običajen portal da enega od dveh odgovorov: 302, katerega Location kaže na prijavno stran, ali 200 s telesom HTML, ki je stran portala. Zapišite, katerega ste prejeli. Preusmeritev pred prijavo ni neuspeh; portal vam pove, kam naj greste. Ko portal sporoči uspeh, ponovite ukaz in pričakujte 200, katerega telo je dobesedno beseda Success. Prav ta niz naredi sondo smiselno. Če gostitelj odgovarja običajno, preden ste se kdaj prijavili, v tem omrežju ni prestreznega portala. V zajemu je zavrženje pred pooblastitvijo odhodni paketi, iz katerih se nič ne vrne, medtem ko delujoča pot pokaže odgovor na isti tok v približno eni sekundi. Povežite se in nato zajem ponovite.

Če tunel še vedno spodleti, potem ko portal reče da

Uspešna prijava ni isto kot dovoljen prenos. Mnoga mesta dovolijo portal in običajno brskanje, a popolnoma blokirajo UDP, kar pusti WireGuard in OpenVPN po UDP pokvarjena, TCP 443 pa deluje. Če TCP 443 prehaja in UDP ne, je to politika mesta in ne odjemalec, ki ste ga napačno nastavili, zato zamenjajte prenos ali sprejmite omejitev in nadaljujte. Če ponovna povezava tudi po tem spodleti, shranite točno napako; poimenuje fazo, v kateri ste obtičali.

Druge odpovedi živijo v napravi. Seja, še vedno vezana na star MAC, drugi vmesnik Wi-Fi z lastnim najemom ali odjemalec, ki je shranil izjemo potrdila portala, lahko vsak še naprej spodleti po čisti ponovni pooblastitvi. Spustite pridružitev, pooblastite znova in poskusite enkrat, preden se dotaknete nastavitev odjemalca. RFC 8952 je vredno branje, če želite arhitekturo za komponentami, ki jih opazujete.

Če sam portal zavrne pooblastitev, je težava v računu ali v dodelitvi naprave in nobena nastavitev VPN tega ne popravi. Sprememba izhodne države VPN ne ponastavi lokalnega stanja dostopa mesta; ta tabela je vezana na vašo napravo, ne na strežnik, ki ga izberete. Vprašajte upravljavca mesta in mu dajte čas, ker bo gledal tabelo sej.

Pred naslednjim potovanjem si zapišite tri stvari: stran portala kot ničti korak, korak začasne ustavitve blokiranja za vsako napravo, ki jo nesete, in en rezervni prenos, ki ste ga res preizkusili. Ko se tunel, ki je deloval pred desetimi minutami, znova ustavi, to obravnavajte kot poteklo pooblastitev in pred dotikom profila VPN znova preverite portal.