Miért blokkolja az elfogó portál a VPN-jét, és hogyan jelentkezzen be újra

Nyílt hálózaton a hozzáférési pontja nem egyszerűen átadja a csomagokat az internetnek. Egy felsőbb házirend-pont ellenőrzi, hogy az eszköze már engedélyezve van-e, és amíg nincs, szinte minden eldobásra kerül. A VPN-kliense ezt a csendet halott szervernek olvassa. Ritkán mondja ki: a WireGuard kézfogást ismétel a semmibe, az OpenVPN kapcsolódási időtúllépést jelent, az IKEv2 pedig 809-es hibával tér vissza egy nem válaszoló távoli szerverről.

Mit irányít a portál valójában

Az elfogó portál két összetűzött dolog: egy házirend-döntési pont és egy átirányító. Amikor az eszköze csatlakozik és DHCP-bérletet kap, a hálózat engedélyezés előtti állapotba helyezi.

Ez az állapot egy tűzfalszabály-készlet. Általában engedélyezi a DNS-t és engedélyezi a HTTP-t vagy HTTPS-t a portál hosztjainak rövid listájára, minden mást pedig eldob. Az engedélyezett lista a fallal körülvett kert, és szinte soha nem tartalmaz VPN-végpontot.

Egyik eldobás sem udvarias. A VPN-szerver felé irányuló csomagok eldobásra kerülnek, nem elutasításra, így a kliens sem ICMP unreachable-t, sem TCP resetet nem kap, csak a válasz hiányát. A gyártótól függően az átirányító a 80-as porton átirányítással válaszolhat a bejelentkező oldalra, míg a 443-as portot eldobja vagy elfogja. Az átirányításokat könnyű észrevenni, mert egyszerű HTTP-választ hordoznak; a 443-as elfogásához olyan tanúsítvány kell, amelyet a böngészője nem fog megbízhatónak elfogadni.

Maga az engedélyezés általában az eszköz MAC-címéhez kötődik, néha a bérelt IP-hez, és egy időzítővel ellátott munkamenet-táblában él. A bejelentkezés bejegyzést hoz létre. A tűzfalszabály, amely átengedi a forgalmát, csak addig létezik, amíg ez a bejegyzés létezik, és ezért tér vissza később az egész probléma anélkül, hogy az Ön oldalán bármi változna.

Miért hal meg a VPN kézfogás, mielőtt elkezdődne

Minden protokollnak megvan a maga átvitele, és az engedélyezés előtti tűzfal mindegyiket másképp töri meg. Az IKEv2 Windows és iOS alatt UDP 500-on és UDP 4500-on jár; az ezeken a portokon történő eldobás 809-ként vagy névfeloldás jellegű hibaként jelenik meg azoknál a klienseknél, amelyek a fázisokat külön jelentik. Az OpenVPN UDP 1194 felett kapcsolódó állapotban marad, amíg le nem jár az időkorlátja. Az OpenVPN TCP 443 felett az érdekes eset, mert a portál befejezheti a TCP kézfogást, majd az átirányító oldalával válaszolhat, így TLS-hibát lát időtúllépés helyett.

A WireGuard mutatja meg legtisztábban a mechanizmust. Tervezés szerint csak UDP, TCP-tartalék nélkül, így az ismeretlen UDP-t eldobó tűzfal teljesen eltávolítja az átvitelt. A kliens növekvő várakozással küldi tovább a kézfogás-kezdeményeket, és soha be nem fejeződő kézfogásról számol be. Semmi sem említi ebben az üzenetben a Wi-Fi-t, és semmi sem utal arra, hogy böngészőt kellene nyitnia.

A platformok a VPN-jénél előbb próbálják észrevenni az állapotot. A Windows egy ismert URL-t kér le, hogy eldöntse, megjelenítse-e a bejelentkezési értesítését, az Android egy olyan végpontot kér, amelynek 204 No Content választ kellene adnia, az Apple-eszközök pedig egy kis elfogóhálózat-ablakot nyitnak. Ezek a próbák azért működnek, mert a portál átirányítással válaszol a várt törzs helyett. Ugyanez a viselkedés magyarázza, hogyan tűnhet teljesen egészségesnek egy portál, miközben az alagútja halott: a próbát és az alagutat különböző szabályok szerint ítélik meg.

Mit állít vissza valójában egy munkamenet lejárta

A helyszínek a VPN-fiókjától független okokból járatják le a munkameneteket: tétlenségi időkorlát, maximális munkamenet-hossz, új DHCP-bérlet vagy egy másik hozzáférési pontra való újracsatlakozás. Amikor az időzítő lejár, eltűnik a munkamenet-tábla bejegyzése, és az engedélyezés előtti szabálykészlet pontosan úgy tér vissza, ahogy a bejelentkezéskor volt.

A kiépített alagút gyakran elég sokáig él ahhoz, hogy egészségesnek tűnjön. Az életben tartó üzenetek tovább mennek, és hogy a kliens észreveszi-e, attól függ, hogyan kezeli a válasz nélküli forgalmat, így az állapotlámpa még egy ideig zöld maradhat, miután az útvonal eltűnt. Aztán leesik az alagút, és minden újracsatlakozási kísérlet ugyanazokon a blokkolt portokon hiúsul meg.

Ezen a ponton a kliens hibája megmondja, melyik szakaszban van, ha figyelmesen elolvassa:

Egy részlet megtéveszti az embereket: amikor a munkamenet MAC-címhez kötődik, a bejelentkező oldal újratöltése talán nem segít. Meg kell szüntetnie a csatlakozást, és újra kell csatlakoznia, hogy a portál új engedélyezési kísérletet lásson a lejárt helyett.

Először jelentkezzen be, aztán emelje fel az alagutat

A működő sorrend: engedélyezze az eszközt, bizonyítsa az útvonalat, indítsa el a VPN-t, bizonyítsa az alagutat, majd állítsa vissza a szokásos blokkolását. Az utolsó lépés azért fontos, mert az ideiglenes állapot, amelyre a portál eléréséhez szüksége van, pontosan az az állapot, amelynek megakadályozására egy vészkapcsoló létezik.

Az asztali kliensnek, amelynél van alagúton kívüli blokkolási lehetőség, szüneteltetni kell, hogy a portáloldal betöltődjön, és az érzékeny alkalmazásokat érdemes zárva tartania ebben az alagúton kívüli ablakban; ez az egyetlen időszak, amikor a helyi forgalom védelem nélkül megy ki. A felügyelt, mindig bekapcsolt eszköznek a tulajdonosa által közzétett eljárást kell használnia, nem annak a helyett, hogy Ön eltávolítja a házirendet. Ha a portál tanúsítványfigyelmeztetést mutat, álljon meg: elfogadása a helyszín elfogó proxyján keresztül vezeti a munkamenetét, és az a proxy mindent el tud olvasni, amit küld. Androidon a mindig bekapcsolt VPN alatti zárolás még az alagút felállása előtt blokkolja a forgalmat, és egyes buildek nem tudják kivenni a portál folyamát; ha az Öné nem tudja, használja a helyszín alternatív hozzáférését vagy egy másik eszközt, ahelyett hogy a zárolást kikapcsolva hagyná. Az Apple igény szerinti szabályai úgy írhatók meg, hogy elutasítsák az alagutat, amíg egy próba nem sikerül, és ez az a viselkedés, amelyet szállodai hálózatokon szeretne.

Ellenőrizze sorrendben a már meglévő eszközökkel. Az alagút előtt futtassa a próbát úgy, hogy a fejlécek és a törzs is látható legyen, és figyelje, kap-e egyáltalán választ a VPN-átvitele:

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'

Engedélyezés előtt egy normál portál két válasz egyikét adja: egy 302-t, amelynek Location fejléce a bejelentkező oldalra mutat, vagy egy 200-at HTML-törzzsel, amely a portáloldal. Jegyezze fel, melyiket kapta. Az átirányítás nem hiba a bejelentkezés előtt; a portál mondja meg, hova menjen. Miután a portál sikert jelent, ismételje meg a parancsot, és várjon egy 200-at, amelynek törzse szó szerint a Success szó. Ez a karakterlánc teszi értelmessé a próbát. Ha a hoszt már a bejelentkezés előtt normálisan válaszol, ezen a hálózaton nincs elfogó portál. A rögzítésben az engedélyezés előtti eldobás kimenő csomagokat jelent, amelyekből semmi sem jön vissza, míg egy működő útvonal választ mutat ugyanarra a folyamra nagyjából egy másodpercen belül. Csatlakozzon, majd ismételje meg a rögzítést.

Ha az alagút továbbra is meghiúsul, miután a portál igent mond

A sikeres bejelentkezés nem ugyanaz, mint az engedélyezett átvitel. Sok helyszín engedélyezi a portált és a szokásos böngészést, miközben az UDP-t teljesen blokkolja, ami a WireGuardot és az UDP-s OpenVPN-t törve hagyja, a TCP 443-at pedig működőképesen. Ha a TCP 443 átmegy, az UDP viszont nem, az a helyszín házirendje, nem egy rosszul beállított kliens, ezért váltson átvitelt, vagy fogadja el a korlátot, és lépjen tovább. Ha egy újracsatlakozás ezután is meghiúsul, őrizze meg a pontos hibát; az megnevezi azt a szakaszt, ahol elakadt.

Más hibák az eszközön élnek. Egy még mindig régi MAC-hez kötött munkamenet, egy második Wi-Fi-adapter saját bérlettel, vagy egy kliens, amely gyorsítótárazta a portál tanúsítvány-kivételét, mindegyik továbbra is meghiúsulhat egy tiszta újraengedélyezés után. Szüntesse meg a csatlakozást, engedélyezze újra, és próbálja meg egyszer, mielőtt a kliens beállításaihoz nyúlna. RFC 8952 érdemes elolvasni, ha a figyelt összetevők mögötti architektúrát szeretné.

Ha maga a portál tagadja meg az engedélyezést, a probléma a fiókban vagy az eszközkiosztásban van, és semmilyen VPN-beállítás nem javítja meg. A VPN kilépési országának megváltoztatása nem állítja vissza a helyszín helyi hozzáférési állapotát; az a tábla az eszközéhez kötődik, nem a választott szerverhez. Kérdezze meg a helyszín üzemeltetőjét, és adjon neki időt, mert a munkamenet-táblát fogja megnézni.

A következő utazása előtt írjon fel három dolgot: a portáloldalt nulladik lépésként, a blokkolás szüneteltetésének lépését minden magával vitt eszközre, és egy tartalék átvitelt, amelyet valóban kipróbált. Amikor egy tíz perccel ezelőtt működő alagút újra leáll, kezelje lejárt engedélyezésként, és ellenőrizze újra a portált, mielőtt a VPN-profilhoz nyúlna.