Captive portal og VPN-dødvande: hvem flytter sig først

Hotellets portal vil have en browser, før den slipper nogen trafik igennem. Din VPN nægter at slippe trafik igennem, før dens tunnel er oppe. Hver side venter på den anden, og begge opfører sig præcis som konfigureret. Kun to rækkefølger bryder det dødvande, og de adskiller sig i, hvad de blotlægger, mens hullet er åbent. Vælg en med vilje i stedet for at skifte den indstilling, der får browseren til at indlæse.

To rækkefølger, den ene virker

Enten lukker netværket dig ind først, og tunnelen kommer bagefter, eller du åbner en smal undtagelse for portalen og gendanner derefter blokeringen. Begge er legitime. Det, der ikke er legitimt, er at slå blokeringen fra og glemme at sætte den tilbage.

De to rækkefølger er ikke lige gode i alle situationer. En administreret enhed med en obligatorisk adgangsproces har ét svar, og en personlig bærbar computer på hotellets Wi-Fi har et andet. Sammenligningen handler om, hvad hver mulighed giver afkald på.

Begynd med at vide, hvilken af dem din klient og din enhedspolitik faktisk understøtter.

Mulighed A: luk netværket ind, og forbind så tunnelen

Bekræft det forventede netværksnavn, og brug derefter styresystemets login-anmodning eller klientens understøttede captive portal-flow. På iPhone og iPad kan en lukning af login-arket enten droppe forbindelsen eller beholde den med en advarsel om, at netværket ikke har internet, og det er forskellige udgangspunkter. Fuldfør først adgangstrinnet, og rejs derefter tunnelen. Denne rækkefølge holder blokeringen intakt hele den tid, tunnelen er nede.

Fidusen er, at en portal, der giver adgang til internettet, ikke har godkendt din VPN-konto. Tunnelen skal stadig forbinde bagefter, og den kan fejle af sine egne grunde. Adgang og godkendelse er adskilte hændelser, som folk smelter sammen til én.

Hvis adgangen bliver ved med at udløbe, så læg mærke til, om portalen spørger igen, om netværket falder, eller om kun VPN’en fejler.

Mulighed B: en smal login-undtagelse, og derefter gendan blokeringen

Alternativet er at tillade portalens trafik, mens blokeringen ellers gælder, logge ind og derefter fjerne undtagelsen. Undtagelsen skal være smal: én destination eller ét adresseområde, i loginets varighed, med blokeringen gendannet umiddelbart efter. Et bredt midlertidigt vindue er måden, hvorpå et login på to minutter bliver en eftermiddag med ubeskyttet trafik.

Vid, hvad din klient faktisk implementerer. OpenVPN Connect på macOS dokumenterer registrering af captive portal separat fra sin indstilling, der blokerer internetadgang, mens VPN’en er sat på pause eller genopretter forbindelsen. At registrere en portal og tillade dens trafik er beslægtede opgaver, ikke udskiftelige løfter.

På en administreret enhed skal du følge den konfigurerede adgangsproces i stedet for at opfinde en undtagelse.

Hvad hullet blotlægger, og for hvem

Den interessante del af dødvandet er ikke browserfanen foran dig. Det er alt det andet, der begynder at bruge netværket i det øjeblik, forbindelsen viser sig: mail, fotosynkronisering, opdateringstjek, en chatklient der genopretter forbindelsen, en backup-agent der genoptager.

Et stille browservindue fortæller dig intet om det. Luk eller sæt følsomt arbejde på pause før ethvert tilladt interval med direkte adgang, og kontroller, hvad der kører ved login. På Android er altid-slået VPN kombineret med blokering af forbindelser uden for VPN’en den relevante kontrol, og en vilkårlig ruteundtagelse er ikke en erstatning for at forstå den.

Dette er det eneste sted, hvor det ældre råd om midlertidige adgangsvinduer stadig holder. Bekymringen var rigtig, selv hvor mekanismen ikke var.

Sådan vælger du, og sådan bekræfter du det

Vælg mulighed A, når enheden eller klienten understøtter et rigtigt portal-flow, fordi det holder blokeringen intakt hele vejen igennem. Vælg mulighed B, når portalen ikke kan nås på nogen anden måde, og behandl undtagelsen som en tidsbegrænset ændring med en ejer.

Bekræft derefter rækkefølgen frem for resultatet:

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

Fuldfør adgangen, etabler den tilsigtede profil, gendan enhver midlertidigt ændret blokeringskontrol, og lav derefter en ny uskadelig anmodning og bekræft, at den følger tunnelen. En anmodning, der lykkes, fordi blokeringen stadig er slået fra, beviser intet om tunnelen.

At skifte VPN-udgang fornyer ikke en udløbet hotelsession. Det er forskellige hændelser, og at blande dem sender dig til at lede det forkerte sted.