Hvorfor captive-portalen blokkerer VPN-en din, og hvordan du logger inn igjen

På et åpent nettverk overleverer ikke tilgangspunktet ditt pakker til internett av seg selv. Et policy-punkt lenger oppe sjekker om enheten din er autorisert ennå, og til den er det, blir nesten alt forkastet. VPN-klienten din leser den stillheten som en død server. Den sier det sjelden: WireGuard gjentar et håndtrykk ut i tomme, OpenVPN rapporterer tidsavbrudd for tilkoblingen, og IKEv2 kommer tilbake som feil 809 om en ekstern server som ikke svarer.

Hva portalen faktisk kontrollerer

En captive-portal er to ting limt sammen: et policy-beslutningspunkt og en omdirigerer. Når enheten din assosierer og tar en DHCP-lease, setter nettverket deg i en tilstand før autorisasjon.

Den tilstanden er et sett brannmurregler. Det slipper vanligvis gjennom DNS og tillater HTTP eller HTTPS til en kort liste portalverter, og det forkaster alt annet. Den tillatte listen er den inngjerdede hagen, og den inneholder nesten aldri et VPN-endepunkt.

Ingen av disse forkastelsene er høflige. Pakker rettet mot en VPN-server forkastes i stedet for å avvises, så klienten får verken ICMP unreachable eller TCP reset, bare fraværet av et svar. Avhengig av leverandør kan omdirigereren svare på port 80 med en omdirigering til innloggingssiden mens port 443 forkastes eller avlyttes. Omdirigeringer er lette å oppdage fordi de bærer et vanlig HTTP-svar; avlytting på 443 krever et sertifikat som nettleseren din vil nekte å stole på.

Selve autorisasjonen er vanligvis knyttet til enhetens MAC-adresse, noen ganger til den leasede IP-en, og den lever i en sesjonstabell med en timer. Innlogging oppretter en oppføring. Brannmurregelen som slipper trafikken din gjennom, finnes bare så lenge den oppføringen finnes, og derfor kommer hele problemet tilbake senere uten at noe endres på din side.

Hvorfor VPN-håndtrykket dør før det begynner

Hver protokoll har sin egen transport, og brannmuren før autorisasjon ødelegger hver av dem på ulike måter. IKEv2 på Windows og iOS går over UDP 500 og UDP 4500; et forkast på disse portene viser seg som 809, eller som en navneoppløsningslignende feil på klienter som rapporterer fasene separat. OpenVPN over UDP 1194 blir i tilkoblingstilstand til tidsavbruddet utløper. OpenVPN over TCP 443 er det interessante tilfellet, fordi portalen kan fullføre TCP-håndtrykket og deretter svare med omdirigeringssiden sin, så du ser en TLS-feil i stedet for et tidsavbrudd.

WireGuard viser mekanismen tydeligst. Den er bare UDP av design, uten TCP-fallback, så en brannmur som forkaster ukjent UDP fjerner transporten helt. Klienten fortsetter å sende håndtrykksinitieringer med økende pause og rapporterer et håndtrykk som aldri fullføres. Ingenting i den meldingen nevner Wi-Fi, og ingenting i den antyder at du bør åpne en nettleser.

Plattformer prøver å merke seg tilstanden før VPN-en din gjør det. Windows henter en kjent URL for å avgjøre om det skal vise innloggingsvarselet, Android ber om et endepunkt som skal svare 204 No Content, og Apple-enheter åpner et lite captive-nettverksvindu. Disse probene virker fordi portalen svarer med en omdirigering i stedet for den forventede kroppen. Den samme oppførselen forklarer hvordan en portal kan se helt sunn ut mens tunnelen din er død: proben og tunnelen vurderes etter forskjellige regler.

Hva en sesjonsutløp egentlig nullstiller

Steder lar sesjoner utløpe av grunner som ikke har med VPN-kontoen din å gjøre: en inaktivitetstimeout, en maksimal sesjonslengde, en ny DHCP-lease eller en ny assosiering til et annet tilgangspunkt. Når timeren slår ut, forsvinner oppføringen i sesjonstabellen, og regelsettet før autorisasjon kommer tilbake nøyaktig slik det var ved innsjekking.

En etablert tunnel overlever ofte lenge nok til å se sunn ut. Keepalive-meldinger fortsetter å gå ut, og om klienten merker det avhenger av hvordan den behandler trafikk uten svar, så statuslampen kan forbli grønn en stund etter at veien er borte. Så faller tunnelen, og hvert gjenoppkoblingsforsøk feiler på de samme blokkerte portene.

På det tidspunktet forteller klientfeilen deg hvilken fase du er i, hvis du leser den nøye:

En detalj lurer folk: når sesjonen er knyttet til en MAC-adresse, hjelper det kanskje ikke å laste innloggingssiden på nytt. Du må slippe assosieringen og koble til på nytt, slik at portalen ser et nytt autorisasjonsforsøk i stedet for et utløpt.

Logg inn først, hev deretter tunnelen

Rekkefølgen som virker, er: autoriser enheten, bevis veien, start VPN-en, bevis tunnelen, og gjenopprett deretter din vanlige blokkering. Det siste trinnet er viktig fordi den midlertidige tilstanden du trenger for å nå portalen, er nøyaktig den tilstanden en kill switch finnes for å forhindre.

En skrivebordsklient med alternativ for å blokkere utenfor tunnelen må settes på pause for at portalsiden skal lastes, og du bør holde følsomme apper lukket i det vinduet utenfor tunnelen; det er det eneste intervallet der lokal trafikk går ut ubeskyttet. En administrert enhet som alltid er på, bør bruke prosedyren eieren har publisert i stedet for at du fjerner policy. Hvis portalen viser en sertifikatadvarsel, stopp: å godta den sender sesjonen din gjennom stedets avlyttingsproxy, og den proxyen kan lese alt du sender. På Android blokkerer låsen under alltid-på-VPN trafikk før tunnelen er oppe, og noen bygg kan ikke unnta portalstrømmen; hvis ditt ikke kan, bruk stedets alternative tilgang eller en annen enhet i stedet for å la låsen være av. Apples on-demand-regler kan skrives slik at de avviser tunnelen til en probe lykkes, og det er oppførselen du ønsker på hotellnettverk.

Verifiser i rekkefølge med verktøyene du allerede har. Før tunnelen kjører du proben med både headere og kropp synlige, og ser om VPN-transporten din får noe svar i det hele tatt:

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 autorisasjon gir en vanlig portal ett av to svar: en 302 der Location peker på innloggingssiden, eller en 200 med en HTML-kropp som er portalsiden. Noter hvilket du fikk. En omdirigering er ikke en feil før innlogging; det er portalen som forteller deg hvor du skal gå. Etter at portalen rapporterer suksess, gjenta kommandoen og forvent en 200 der kroppen er det bokstavelige ordet Success. Det er den strengen som gjør proben meningsfull. Hvis verten svarer normalt før du noen gang har logget inn, finnes det ingen avlyttende portal på dette nettverket. I opptaket er et forkast før autorisasjon utgående pakker der ingenting kommer tilbake, mens en vei som virker viser et svar på samme flyt innen omtrent et sekund. Koble til, og gjenta deretter opptaket.

Hvis tunnelen fortsatt feiler etter at portalen sier ja

Innloggingssuksess er ikke det samme som tillatt transport. Mange steder tillater portalen og vanlig surfing mens de blokkerer UDP helt, noe som lar WireGuard og UDP-OpenVPN være ødelagt og TCP 443 virke. Hvis TCP 443 går gjennom og UDP ikke, er det stedets policy og ikke en klient du har feilkonfigurert, så bytt transport eller godta grensen og gå videre. Hvis en gjenoppkobling fortsatt feiler etter det, ta vare på den nøyaktige feilen; den navngir fasen du sitter fast i.

Andre feil bor på enheten. En sesjon som fortsatt er knyttet til en gammel MAC, en andre Wi-Fi-adapter med sin egen lease, eller en klient som har bufret portalens sertifikatunntak, kan hver for seg fortsette å feile etter en ren ny autorisasjon. Slipp assosieringen, autoriser på nytt og prøv én gang før du rører klientinnstillingene. RFC 8952 er verdt å lese hvis du vil ha arkitekturen bak komponentene du følger med på.

Hvis portalen selv nekter å autorisere, ligger problemet i kontoen eller enhetstildelingen, og ingen VPN-innstilling vil fikse det. Å bytte VPN-ens utgangsland nullstiller ikke stedets lokale tilgangstilstand; den tabellen er knyttet til enheten din, ikke til serveren du velger. Spør stedets operatør og gi dem tid, for sesjonstabellen er det de vil se på.

Før neste reise bør du skrive ned tre ting: portalsiden som trinn null, pausen av blokkeringen for hver enhet du har med, og én transportreserve du faktisk har testet. Når en tunnel som virket for ti minutter siden stopper igjen, behandler du det som en utløpt autorisasjon og sjekker portalen på nytt før du rører VPN-profilen.