Hvorfor captive-portalen blokerer din VPN, og hvordan du logger ind igen

På et åbent netværk overlader dit adgangspunkt ikke bare pakker til internettet. Et politikpunkt længere oppe kontrollerer, om din enhed er godkendt endnu, og indtil den er det, droppes næsten alt. Din VPN-klient læser den tavshed som en død server. Den siger det sjældent: WireGuard gentager et håndtryk ud i tomheden, OpenVPN rapporterer en forbindelsestimeout, og IKEv2 kommer tilbage som fejl 809 om en fjernserver, der ikke svarer.

Hvad portalen egentlig styrer

En captive-portal er to ting, der er klæbet sammen: et politikbeslutningspunkt og en omdirigering. Når din enhed associerer og får en DHCP-lease, placerer netværket dig i en tilstand før godkendelse.

Den tilstand er et regelsæt i firewallen. Det tillader normalt DNS og tillader HTTP eller HTTPS til en kort liste af portalværter, og det kasserer alt andet. Den tilladte liste er den indhegnede have, og den inkluderer næsten aldrig et VPN-endepunkt.

Ingen af de kasseringer er høflige. Pakker rettet mod en VPN-server kasseres i stedet for at blive afvist, så klienten får hverken ICMP unreachable eller TCP reset, kun fraværet af et svar. Afhængigt af leverandøren kan omdirigeringen svare på port 80 med en omdirigering til login-siden, mens port 443 kasseres eller opfanges. Omdirigeringer er nemme at se, fordi de bærer et almindeligt HTTP-svar; opsnapning på 443 kræver et certifikat, som din browser vil nægte at stole på.

Selve godkendelsen er normalt bundet til enhedens MAC-adresse, nogle gange til den leasede IP, og den lever i en sessionstabel med en timer. Login opretter en post. Firewallreglen, der lukker din trafik igennem, findes kun, så længe den post findes, og derfor vender hele problemet tilbage senere, uden at noget ændrer sig på din side.

Hvorfor VPN-håndtrykket dør, før det begynder

Hver protokol har sin egen transport, og firewallen før godkendelse ødelægger hver af dem forskelligt. IKEv2 på Windows og iOS kører på UDP 500 og UDP 4500; et drop på disse porte viser sig som 809, eller som en fejl af navneopløsningstypen på klienter, der rapporterer faser separat. OpenVPN over UDP 1194 bliver i forbindelsestilstanden, indtil dens timeout udløber. OpenVPN over TCP 443 er det interessante tilfælde, fordi portalen kan fuldføre TCP-håndtrykket og derefter svare med sin omdirigeringsside, så du ser en TLS-fejl i stedet for en timeout.

WireGuard viser mekanismen tydeligst. Den er kun UDP af design, uden TCP-fallback, så en firewall, der kasserer ukendt UDP, fjerner transporten helt. Klienten bliver ved med at sende håndtryksinitieringer med voksende backoff og rapporterer et håndtryk, der aldrig fuldføres. Intet i den besked nævner Wi-Fi, og intet i den antyder, at du skulle åbne en browser.

Platforme prøver at bemærke tilstanden, før din VPN gør. Windows henter en kendt URL for at afgøre, om det skal vise sin login-notifikation, Android anmoder om et endepunkt, der burde svare 204 No Content, og Apple-enheder åbner et lille vindue for captive-netværk. De prober virker, fordi portalen svarer med en omdirigering i stedet for det forventede indhold. Den samme adfærd forklarer, hvordan en portal kan se helt sund ud, mens din tunnel er død: proben og tunnelen vurderes efter forskellige regler.

Hvad en sessionens udløb egentlig nulstiller

Steder lader sessioner udløbe af grunde, der intet har med din VPN-konto at gøre: en inaktivitetstimeout, en maksimal sessionslængde, en ny DHCP-lease eller en ny associering til et andet adgangspunkt. Når timeren udløser, forsvinder posten i sessionstabellen, og regelsættet før godkendelse vender tilbage præcis, som det var ved check-in.

En etableret tunnel overlever ofte længe nok til at se sund ud. Keepalives bliver ved med at gå ud, og om klienten bemærker det, afhænger af, hvordan den behandler trafik uden svar, så statuslyset kan forblive grønt et stykke tid efter, at vejen er væk. Så falder tunnelen, og hvert genopkoblingsforsøg fejler på de samme blokerede porte.

På det tidspunkt fortæller klientfejlen dig, hvilken fase du er i, hvis du læser den omhyggeligt:

En detalje snyder folk: når sessionen er bundet til en MAC-adresse, hjælper det måske ikke at genindlæse login-siden. Du er nødt til at slippe associeringen og forbinde igen, så portalen ser et nyt godkendelsesforsøg i stedet for et udløbet.

Log ind først, løft derefter tunnelen

Den rækkefølge, der virker, er: godkend enheden, bevis vejen, start VPN'en, bevis tunnelen, og gendan derefter din normale blokering. Det sidste trin er vigtigt, fordi den midlertidige tilstand, du har brug for for at nå portalen, er præcis den tilstand, en kill switch findes for at forhindre.

En desktop-klient med en indstilling til at blokere uden for tunnelen skal sættes på pause, for at portalsiden kan indlæses, og du bør holde følsomme apps lukket i det vindue uden for tunnelen; det er det eneste interval, hvor lokal trafik går ud ubeskyttet. En administreret enhed, der altid er tændt, bør bruge den procedure, dens ejer har offentliggjort, i stedet for at du fjerner politik. Hvis portalen viser en certifikatadvarsel, så stop: at acceptere den sender din session gennem stedets opfangningsproxy, og den proxy kan læse alt, hvad du sender. På Android blokerer lockdown under altid-tændt VPN trafik, før tunnelen er oppe, og nogle builds kan ikke undtage portalflowet; hvis din ikke kan, så brug stedets alternative adgang eller en anden enhed i stedet for at lade lockdown være slået fra. Apples on-demand-regler kan skrives til at afvise tunnelen, indtil en probe lykkes, og det er den adfærd, du ønsker på hotelnetværk.

Verificer i rækkefølge med de værktøjer, du allerede har. Før tunnelen kører du proben med både headere og body synlige, og ser, om din VPN-transport overhovedet får et svar:

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'

Før godkendelse giver en normal portal et af to svar: et 302, hvis Location peger på login-siden, eller et 200 med en HTML-body, der er portalsiden. Noter, hvilket du fik. En omdirigering er ikke en fejl før login; det er portalen, der fortæller dig, hvor du skal hen. Når portalen rapporterer succes, gentager du kommandoen og forventer et 200, hvis body er det bogstavelige ord Success. Den streng er det, der gør proben meningsfuld. Hvis værten svarer normalt, før du overhovedet har logget ind, er der ingen opfangende portal på dette netværk. I optagelsen er et drop før godkendelse udgående pakker, hvor intet kommer tilbage, mens en vej, der virker, viser et svar på samme flow inden for omkring et sekund. Forbind, og gentag derefter optagelsen.

Hvis tunnelen stadig fejler, efter at portalen siger ja

Login-succes er ikke det samme som tilladt transport. Mange steder tillader portalen og almindelig browsing, mens de blokerer UDP helt, hvilket efterlader WireGuard og UDP-OpenVPN brudt og TCP 443 fungerende. Hvis TCP 443 går igennem og UDP ikke, er det stedets politik og ikke en klient, du har konfigureret forkert, så skift transport eller accepter grænsen og kom videre. Hvis en genopkobling stadig fejler efter det, så gem den præcise fejl; den navngiver den fase, du sidder fast i.

Andre fejl bor på enheden. En session, der stadig er bundet til en gammel MAC, en anden Wi-Fi-adapter med sin egen lease, eller en klient, der har cachelagret portalens certifikatundtagelse, kan hver især blive ved med at fejle efter en ren gen-godkendelse. Slip associeringen, godkend igen, og prøv én gang, før du rører klientindstillingerne. RFC 8952 er værd at læse, hvis du vil have arkitekturen bag de komponenter, du kigger på.

Hvis portalen selv nægter at godkende, er problemet konto eller enhedstildeling, og ingen VPN-indstilling vil løse det. At skifte VPN'ens udgangsland nulstiller ikke stedets lokale adgangstilstand; den tabel er bundet til din enhed, ikke til den server, du vælger. Spørg stedets operatør og giv dem tid, for sessionstabellen er det, de vil kigge på.

Før din næste rejse skal du skrive tre ting ned: portalsiden som trin nul, pausen af blokeringen for hver enhed, du har med, og en transportreserve, du faktisk har testet. Når en tunnel, der virkede for ti minutter siden, stopper igen, skal du behandle det som en udløbet godkendelse og tjekke portalen igen, før du rører VPN-profilen.