Proč vás zachytávací portál nepustí do VPN a jak se znovu přihlásit

V otevřené síti váš přístupový bod pakety do internetu jen tak nepředá. Politický bod výš po cestě kontroluje, zda už je vaše zařízení autorizované, a dokud není, téměř vše se zahazuje. Váš VPN klient čte to ticho jako mrtvý server. Málokdy to řekne: WireGuard znovu posílá handshake do prázdna, OpenVPN hlásí vypršení spojení a IKEv2 se vrací s chybou 809 o vzdáleném serveru, který neodpovídá.

Co portál vlastně řídí

Zachytávací portál jsou dvě věci spojené dohromady: rozhodovací bod politiky a přesměrovávač. Když se vaše zařízení připojí a získá DHCP pronájem, síť vás uvede do stavu před autorizací.

Tento stav je sada pravidel firewallu. Obvykle povoluje DNS a povoluje HTTP nebo HTTPS na krátký seznam hostitelů portálu a vše ostatní zahazuje. Povolený seznam je oplocená zahrada a téměř nikdy neobsahuje koncový bod VPN.

Žádné z těch zahazování není zdvořilé. Pakety mířící na VPN server se zahazují, místo aby byly odmítnuty, takže klient nedostane ani ICMP unreachable, ani TCP reset, jen absenci odpovědi. Podle výrobce může přesměrovávač odpovědět na port 80 přesměrováním na přihlašovací stránku, zatímco port 443 se zahazuje nebo zachytává. Přesměrování se snadno poznají, protože nesou obyčejnou HTTP odpověď; zachytávání na 443 potřebuje certifikát, kterému váš prohlížeč odmítne důvěřovat.

Samotná autorizace bývá vázaná na MAC adresu zařízení, někdy na pronajatou IP, a žije v tabulce relací s časovačem. Přihlášení vytvoří záznam. Pravidlo firewallu, které propouští váš provoz, existuje jen dokud existuje tento záznam, a proto se celý problém později vrací, aniž by se na vaší straně cokoli změnilo.

Proč handshake VPN umírá, než začne

Každý protokol má svůj transport a firewall před autorizací každý rozbíjí jinak. IKEv2 na Windows a iOS jede na UDP 500 a UDP 4500; zahození na těchto portech se projeví jako 809, nebo jako selhání ve stylu překladu jmen u klientů, kteří fáze hlásí odděleně. OpenVPN přes UDP 1194 zůstává ve stavu připojování, dokud nevyprší jeho časový limit. OpenVPN přes TCP 443 je zajímavý případ, protože portál může dokončit TCP handshake a pak odpovědět svou přesměrovací stránkou, takže vidíte chybu TLS místo vypršení limitu.

WireGuard ukazuje mechanismus nejčistěji. Je z principu jen UDP, bez TCP zálohy, takže firewall, který zahazuje neznámé UDP, transport úplně odstraní. Klient dál posílá začátky handshake s rostoucím odstupem a hlásí handshake, který se nikdy nedokončí. Nic v té zprávě nezmiňuje Wi-Fi a nic v ní nenaznačuje, že byste měli otevřít prohlížeč.

Platformy se snaží stav postřehnout dřív než vaše VPN. Windows načítá známou URL, aby rozhodl, zda zobrazit oznámení o přihlášení, Android žádá koncový bod, který by měl odpovědět 204 No Content, a zařízení Apple otevírají malé okno zachytávací sítě. Tyto sondy fungují, protože portál odpovídá přesměrováním místo očekávaného těla. Stejné chování vysvětluje, jak může portál vypadat naprosto zdravě, zatímco váš tunel je mrtvý: sonda a tunel se posuzují podle různých pravidel.

Co vypršení relace skutečně resetuje

Podniky ukončují relace z důvodů nesouvisejících s vaším VPN účtem: časový limit nečinnosti, maximální délka relace, nový DHCP pronájem nebo opětovné přidružení k jinému přístupovému bodu. Když časovač zabere, záznam v tabulce relací zmizí a sada pravidel před autorizací se vrátí přesně tak, jak byla při přihlášení.

Navázaný tunel často přežije dost dlouho, aby vypadal zdravě. Zprávy pro udržení spojení dál odcházejí a to, zda si toho klient všimne, závisí na tom, jak zachází s provozem bez odpovědi, takže stavové světlo může po zmizení cesty ještě chvíli zůstat zelené. Pak tunel spadne a každý pokus o opětovné připojení selže na stejných blokovaných portech.

V tu chvíli vám chyba klienta řekne, v jaké fázi jste, pokud ji pozorně přečtete:

Jeden detail lidi mate: když je relace vázaná na MAC adresu, obnovení přihlašovací stránky nemusí pomoci. Musíte zrušit přidružení a připojit se znovu, aby portál viděl nový pokus o autorizaci místo vypršelého.

Nejdřív se přihlaste, pak zvedněte tunel

Pořadí, které funguje, je: autorizujte zařízení, prokažte cestu, spusťte VPN, prokažte tunel a pak obnovte své obvyklé blokování. Poslední krok je důležitý, protože dočasný stav, který potřebujete k dosažení portálu, je přesně ten stav, který má bezpečnostní vypínač za úkol zabránit.

Desktopový klient s volbou blokovat mimo tunel se musí pozastavit, aby se stránka portálu načetla, a citlivé aplikace byste měli mít během toho okna mimo tunel zavřené; je to jediný interval, kdy lokální provoz odchází nechráněný. Spravované zařízení, které je stále zapnuté, by mělo použít postup, který zveřejnil jeho vlastník, místo abyste politiku odstraňovali vy. Pokud portál zobrazí varování o certifikátu, zastavte: přijetí přesměruje vaši relaci přes zachytávací proxy podniku a ta proxy může číst vše, co odešlete. Na Androidu zámek pod stále zapnutou VPN blokuje provoz dřív, než se tunel zvedne, a některé buildy nedokážou tok portálu vyjmout; pokud to ten váš nedokáže, použijte alternativní přístup podniku nebo jiné zařízení, místo abyste zámek nechali vypnutý. Pravidla Apple na vyžádání lze napsat tak, aby tunel odmítla, dokud sonda neuspěje, což je chování, které na hotelových sítích chcete.

Ověřujte popořadě nástroji, které už máte. Před tunelem spusťte sondu s viditelnými hlavičkami i tělem a sledujte, zda váš VPN transport dostane vůbec nějakou odpověď:

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'

Před autorizací dává normální portál jednu ze dvou odpovědí: 302, jehož Location ukazuje na přihlašovací stránku, nebo 200 s HTML tělem, které je stránkou portálu. Zapište si, kterou jste dostali. Přesměrování není před přihlášením selhání; je to portál, který vám říká, kam jít. Poté co portál ohlásí úspěch, zopakujte příkaz a očekávejte 200, jehož tělem je doslova slovo Success. Právě tento řetězec dělá sondu smysluplnou. Pokud hostitel odpovídá normálně dřív, než jste se vůbec přihlásili, na této síti žádný zachytávací portál není. V záznamu je zahození před autorizací odchozí pakety, ze kterých se nic nevrací, zatímco funkční cesta ukáže odpověď na stejný tok během zhruba sekundy. Připojte se a pak záznam zopakujte.

Pokud tunel stále selhává poté, co portál řekne ano

Úspěšné přihlášení není totéž jako povolený transport. Řada podniků povoluje portál a běžné brouzdání, zatímco UDP úplně blokuje, což nechá WireGuard a OpenVPN přes UDP rozbité a TCP 443 funkční. Pokud TCP 443 prochází a UDP ne, je to politika podniku, ne klient, kterého jste špatně nastavili, takže přepněte transport nebo omezení přijměte a jděte dál. Pokud opětovné připojení i potom selhává, uchovejte přesnou chybu; pojmenovává fázi, ve které jste uvízli.

Jiná selhání žijí v zařízení. Relace stále vázaná na starou MAC, druhý Wi-Fi adaptér s vlastním pronájmem nebo klient, který si uložil výjimku certifikátu portálu, každý z nich může po čisté opětovné autorizaci dál selhávat. Zrušte přidružení, znovu autorizujte a jednou to zkuste, než se dotknete nastavení klienta. RFC 8952 stojí za přečtení, pokud chcete architekturu za komponentami, které sledujete.

Pokud sám portál odmítne autorizovat, problém je v účtu nebo v přidělení zařízení a žádné nastavení VPN to nespraví. Změna výstupní země VPN neresetuje místní stav přístupu podniku; ta tabulka je vázaná na vaše zařízení, ne na server, který si vyberete. Zeptejte se provozovatele podniku a dejte mu čas, protože tabulka relací je to, na co se bude dívat.

Před příští cestou si zapište tři věci: stránku portálu jako nultý krok, krok pozastavení blokování pro každé zařízení, které vezete, a jeden záložní transport, který jste skutečně vyzkoušeli. Když se tunel, který před deseti minutami fungoval, znovu zastaví, berte to jako vypršelou autorizaci a znovu zkontrolujte portál, než se dotknete profilu VPN.