Kvifor captive-portalen blokkerer VPN-en din, og korleis du loggar inn på nytt

På eit ope nettverk overlet ikkje tilgangspunktet ditt pakkar til internett av seg sjølv. Eit policy-punkt lenger oppe sjekkar om eininga di er autorisert enno, og til ho er det, blir nesten alt forkasta. VPN-klienten din les den stilla som ein død server. Han seier det sjeldan: WireGuard gientar eit handtrykk ut i tomme, OpenVPN rapporterer tidsavbrot for tilkoplinga, og IKEv2 kjem tilbake som feil 809 om ein ekstern server som ikkje svarar.

Kva portalen faktisk kontrollerer

Ein captive-portal er to ting limte saman: eit policy-avgjerdslpunkt og ein omdirigerar. Når eininga di assosierer og tek ein DHCP-lease, set nettverket deg i ein tilstand før autorisasjon.

Den tilstanden er eit sett brannmurreglar. Det slepp vanlegvis gjennom DNS og tillèt HTTP eller HTTPS til ei kort liste portalvertar, og det forkastar alt anna. Den tillatne lista er den inngjerda hagen, og ho inneheld nesten aldri eit VPN-endepunkt.

Ingen av desse forkastingane er høflege. Pakkar retta mot ein VPN-server blir forkasta i staden for å bli avviste, så klienten får korkje ICMP unreachable eller TCP reset, berre fråværet av eit svar. Avhengig av leverandøren kan omdirigeraren svare på port 80 med ei omdirigering til innloggingssida medan port 443 blir forkasta eller avlytta. Omdirigeringar er lette å oppdage fordi dei ber eit vanleg HTTP-svar; avlytting på 443 krev eit sertifikat som nettlesaren din vil nekte å stole på.

Sjølve autorisasjonen er vanlegvis knytt til MAC-adressa til eininga, stundom til den leasede IP-en, og han lever i ein sesjonstabell med ein timer. Innlogging opprettar ei oppføring. Brannmurregelen som slepp trafikken din gjennom, finst berre så lenge den oppføringa finst, og difor kjem heile problemet tilbake seinare utan at noko blir endra på di side.

Kvifor VPN-handtrykket døyr før det byrjar

Kvar protokoll har sin eigen transport, og brannmuren før autorisasjon øydelegg kvar av dei på ulike måtar. IKEv2 på Windows og iOS går over UDP 500 og UDP 4500; eit forkast på desse portane viser seg som 809, eller som ein namneoppløysingsliknande feil på klientar som rapporterer fasane separat. OpenVPN over UDP 1194 blir i tilkoplingstilstand til tidsavbrotet går ut. OpenVPN over TCP 443 er det interessante tilfellet, fordi portalen kan fullføre TCP-handtrykket og deretter svare med omdirigeringssida si, så du ser ein TLS-feil i staden for eit tidsavbrot.

WireGuard viser mekanismen tydelegast. Han er berre UDP av design, utan TCP-fallback, så ein brannmur som forkastar ukjend UDP fjernar transporten heilt. Klienten held fram med å sende handtrykksinitieringar med aukande pause og rapporterer eit handtrykk som aldri blir fullført. Ingenting i den meldinga nemner Wi-Fi, og ingenting i henne antydar at du bør opne ein nettlesar.

Plattformar prøver å merke seg tilstanden før VPN-en din gjer det. Windows hentar ein kjend URL for å avgjere om det skal vise innloggingsvarselet, Android ber om eit endepunkt som skal svare 204 No Content, og Apple-einingar opnar eit lite captive-nettverksvindauge. Desse probane verkar fordi portalen svarar med ei omdirigering i staden for den forventa kroppen. Den same åtferda forklarer korleis ein portal kan sjå heilt sunn ut medan tunnelen din er død: proben og tunnelen blir vurderte etter ulike reglar.

Kva eit sesjonsutløp eigentleg nullstiller

Stader lèt sesjonar gå ut av grunnar som ikkje har med VPN-kontoen din å gjere: eit inaktivitetstidsavbrot, ei maksimal sesjonslengd, ein ny DHCP-lease eller ei ny assosiering til eit anna tilgangspunkt. Når timeren slår ut, forsvinn oppføringa i sesjonstabellen, og regelsettet før autorisasjon kjem tilbake nøyaktig slik det var ved innsjekking.

Ein etablert tunnel overlever ofte lenge nok til å sjå sunn ut. Keepalive-meldingar held fram med å gå ut, og om klienten merkjer det avheng av korleis han behandlar trafikk utan svar, så statuslampa kan halde fram med å vere grøn ei stund etter at vegen er borte. Så fell tunnelen, og kvart gjenoppkoplingsforsøk feilar på dei same blokkerte portane.

På det tidspunktet fortel klientfeilen deg kva fase du er i, om du les han nøye:

Ein detalj lurar folk: når sesjonen er knytt til ei MAC-adresse, hjelper det kanskje ikkje å laste innloggingssida på nytt. Du må sleppe assosieringa og kople til på nytt, slik at portalen ser eit nytt autorisasjonsforsøk i staden for eit utløpt.

Logg inn først, hev deretter tunnelen

Rekkjefølgja som verkar, er: autoriser eininga, prov vegen, start VPN-en, prov tunnelen, og gjenopprett deretter den vanlege blokkeringa di. Det siste trinnet er viktig fordi den mellombelse tilstanden du treng for å nå portalen, er nøyaktig den tilstanden ein kill switch finst for å hindre.

Ein skrivebordsklient med alternativ for å blokkere utanfor tunnelen må setjast på pause for at portalsida skal laste, og du bør halde kjenslevare apper lukka i det vindauget utanfor tunnelen; det er det einaste intervallet der lokal trafikk går ut utan vern. Ei administrert eining som alltid er på, bør bruke prosedyren eigaren har publisert i staden for at du fjernar policy. Om portalen viser ei sertifikatåtvaring, stopp: å godta henne sender sesjonen din gjennom avlyttingsproxien til staden, og den proxien kan lese alt du sender. På Android blokkerer låsen under alltid-på-VPN trafikk før tunnelen er oppe, og nokre bygg kan ikkje unnta portalstraumen; om ditt ikkje kan, bruk den alternative tilgangen til staden eller ei anna eining i staden for å la låsen vere av. Apples on-demand-reglar kan skrivast slik at dei avviser tunnelen til ein probe lukkast, og det er åtferda du ønskjer på hotellnettverk.

Stadfest i rekkjefølgje med verktøya du allereie har. Før tunnelen køyrer du proben med både headarar og kropp synlege, og ser om VPN-transporten din får noko svar i det heile:

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 ein vanleg portal eitt av to svar: ein 302 der Location peikar på innloggingssida, eller ein 200 med ein HTML-kropp som er portalsida. Noter kva du fekk. Ei omdirigering er ikkje ein feil før innlogging; det er portalen som fortel deg kvar du skal gå. Etter at portalen rapporterer suksess, gienta kommandoen og vent ein 200 der kroppen er det bokstavelege ordet Success. Det er den strengen som gjer proben meiningsfull. Om verten svarar normalt før du nokon gong har logga inn, finst det ingen avlyttande portal på dette nettverket. I opptaket er eit forkast før autorisasjon utgåande pakkar der ingenting kjem tilbake, medan ein veg som verkar viser eit svar på same flyt innan omtrent eitt sekund. Kople til, og gienta deretter opptaket.

Om tunnelen framleis feilar etter at portalen seier ja

Innloggingssuksess er ikkje det same som tillaten transport. Mange stader tillèt portalen og vanleg surfing medan dei blokkerer UDP heilt, noko som lèt WireGuard og UDP-OpenVPN vere øydelagde og TCP 443 verke. Om TCP 443 går gjennom og UDP ikkje, er det policyen til staden og ikkje ein klient du har feilkonfigurert, så byt transport eller godta grensa og gå vidare. Om ein gjenoppkopling framleis feilar etter det, ta vare på den nøyaktige feilen; han namngir fasen du sit fast i.

Andre feil bur på eininga. Ein sesjon som framleis er knytt til ein gammal MAC, ein andre Wi-Fi-adapter med sin eigen lease, eller ein klient som har bufra portalens sertifikatunntak, kan kvar for seg halde fram med å feile etter ein rein ny autorisasjon. Slepp assosieringa, autoriser på nytt og prøv éin gong før du rører klientinnstillingane. RFC 8952 er verd å lese om du vil ha arkitekturen bak komponentane du følgjer med på.

Om portalen sjølv nektar å autorisere, ligg problemet i kontoen eller einingstildelinga, og ingen VPN-innstilling vil fikse det. Å byte utgangsland for VPN-en nullstiller ikkje den lokale tilgangstilstanden til staden; den tabellen er knytt til eininga di, ikkje til serveren du vel. Spør operatøren til staden og gi han tid, for sesjonstabellen er det han vil sjå på.

Før neste reise bør du skrive ned tre ting: portalsida som trinn null, pausen av blokkeringa for kvar eining du har med, og éin transportreserve du faktisk har testa. Når ein tunnel som verka for ti minutt sidan stoppar igjen, behandlar du det som ein utløpt autorisasjon og sjekkar portalen på nytt før du rører VPN-profilen.