Hotellets portal vil se en nettleser før den slipper gjennom noen trafikk. VPN-en din nekter å slippe gjennom trafikk før tunnelen er oppe. Hver side venter på den andre, og begge oppfører seg nøyaktig som de er konfigurert. Bare to rekkefølger bryter denne dødlåsen, og de skiller seg i hva de avdekker mens gapet er åpent. Velg én med vilje i stedet for å slå av og på hvilken som helst innstilling som får nettleseren til å lastes.

To rekkefølger, én av dem fungerer

Enten slipper nettverket deg inn først og tunnelen kommer etterpå, eller så åpner du et smalt unntak for portalen og gjenoppretter blokkeringen etterpå. Begge er legitime. Det som ikke er legitimt, er å slå av blokkeringen og glemme å sette den tilbake.

OrderWhat it costsWhen it fails
Admit, then connectNothing extra; the block stays onThe client cannot reach the portal with the tunnel down
Exception, then restoreA timed window of direct accessThe window is left open, or scoped too broadly

De to rekkefølgene er ikke like gode i alle situasjoner. En administrert enhet med en pålagt opptaksprosess har ett svar, og en personlig bærbar PC på hotell-Wi-Fi har et annet. Sammenligningen handler om hva hvert alternativ gir avkall på.

Begynn med å vite hvilken av dem klienten og enhetspolicyen din faktisk støtter.

Alternativ A: slipp nettverket inn, koble deretter til tunnelen

Bekreft det forventede nettverksnavnet, og bruk deretter operativsystemets påloggingsforespørsel eller klientens støttede captive portal-flyt. På iPhone og iPad kan det å lukke påloggingsarket enten bryte tilknytningen eller beholde den med en advarsel om at nettverket ikke har internett, og det er forskjellige utgangspunkt. Fullfør opptakstrinnet først, og ta deretter opp tunnelen. Denne rekkefølgen holder blokkeringen intakt hele tiden mens tunnelen er nede.

Haken er at en portal som autoriserer internettilgang, ikke har autentisert VPN-kontoen din. Tunnelen må likevel koble til etterpå, og den kan mislykkes av sine egne grunner. Opptak og autentisering er separate hendelser som folk smelter sammen til én.

Hvis opptaket fortsetter å utløpe, noter om portalen spør igjen, om nettverket faller ut eller om bare VPN-en feiler.

Alternativ B: et smalt påloggingsunntak, og deretter gjenopprett blokkeringen

Alternativet er å tillate portalens trafikk mens blokkeringen ellers gjelder, logge på og deretter fjerne unntaket. Unntaket må være smalt: én destinasjon eller ett adresseområde, i påloggingens varighet, med blokkeringen gjenopprettet umiddelbart etterpå. Et bredt midlertidig vindu er hvordan en pålogging på to minutter blir en hel ettermiddag med ubeskyttet trafikk.

Vit hva klienten din faktisk implementerer. OpenVPN Connect på macOS dokumenterer captive portal-deteksjon atskilt fra alternativet som blokkerer internettilgang mens VPN-en er satt på pause eller kobler til på nytt. Å oppdage en portal og å tillate trafikken dens er beslektede oppgaver, ikke utskiftbare løfter.

På en administrert enhet følger du den konfigurerte opptaksprosessen i stedet for å finne på et unntak.

Hva gapet avdekker, og for hvem

Det interessante med dødlåsen er ikke nettleserfanen foran deg. Det er alt annet som begynner å bruke nettverket i det øyeblikket tilkoblingen dukker opp: e-post, fotosynk, oppdateringssjekker, en chatklient som kobler til på nytt, en sikkerhetskopiagent som gjenopptar.

Et stille nettleservindu sier deg ingenting om dette. Lukk eller sett følsomt arbeid på pause før hvert tillatte intervall med direkte tilgang, og sjekk hva som kjører ved pålogging. På Android er alltid på-VPN kombinert med blokkering av tilkoblinger utenfor VPN-en den relevante kontrollen, og et vilkårlig ruteunntak er ingen erstatning for å forstå den.

Dette er det eneste stedet der det eldre rådet om midlertidige tilgangsvinduer fortsatt holder. Bekymringen var riktig også der mekanismen ikke var det.

Hvordan velge og hvordan bekrefte det

Velg alternativ A når enheten eller klienten støtter en ekte portalflyt, fordi det holder blokkeringen intakt hele veien. Velg alternativ B når portalen ikke kan nås på annen måte, og behandl unntaket som en tidsbegrenset endring med en eier.

Bekreft deretter rekkefølgen i stedet for resultatet:

curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'

Fullfør opptaket, etabler den tiltenkte profilen, gjenopprett enhver midlertidig endret blokkeringskontroll, og gjør deretter en ny ufarlig forespørsel og bekreft at den følger tunnelen. En forespørsel som lykkes fordi blokkeringen fortsatt er av, beviser ingenting om tunnelen.

Å bytte VPN-utgang fornyer ikke en utløpt hotellsession. Det er forskjellige hendelser, og å blande dem sender deg til å lete på feil sted.

Relaterte artikler