Captive portal och VPN i dödläge: vem rör sig först
Hotellportalen kräver trafik innan tunneln finns; VPN:n blockerar tills tunneln är uppe. Jämför de två ordningarna och vad var och en exponerar i glappet.
Hotellets portal vill se en webbläsare innan den släpper igenom någon trafik. Din VPN vägrar släppa igenom trafik innan dess tunnel är uppe. Varje sida väntar på den andra, och båda beter sig exakt som de är konfigurerade. Bara två ordningar bryter dödläget, och de skiljer sig i vad de exponerar medan glappet är öppet. Välj en medvetet i stället för att växla vilken inställning som helst som får webbläsaren att laddas.
Två ordningar, en av dem fungerar
Antingen släpper nätverket in dig först och tunneln kommer sedan, eller så öppnar du ett snävt undantag för portalen och återställer blockeringen efteråt. Båda är legitima. Det som inte är legitimt är att stänga av blockeringen och glömma att sätta tillbaka den.
| Order | What it costs | When it fails |
|---|---|---|
| Admit, then connect | Nothing extra; the block stays on | The client cannot reach the portal with the tunnel down |
| Exception, then restore | A timed window of direct access | The window is left open, or scoped too broadly |
De två ordningarna är inte lika bra i alla situationer. En hanterad enhet med en obligatorisk antagningsprocess har ett svar, och en personlig laptop på hotell-Wi-Fi har ett annat. Jämförelsen handlar om vad varje alternativ ger upp.
Börja med att veta vilken av dem din klient och din enhetspolicy faktiskt stöder.
Alternativ A: släpp in nätverket, anslut sedan tunneln
Bekräfta det förväntade nätverksnamnet och använd sedan operativsystemets inloggningsförfrågan eller klientens stödda captive portal-flöde. På iPhone och iPad kan det att stänga inloggningsarket antingen bryta associationen eller behålla den med en varning om att nätverket saknar internet, och det är olika utgångspunkter. Slutför antagningssteget först och ta sedan upp tunneln. Den här ordningen håller blockeringen intakt hela tiden tunneln är nere.
Haken är att en portal som godkänner internetåtkomst inte har autentiserat ditt VPN-konto. Tunneln måste ändå ansluta efteråt, och den kan misslyckas av sina egna skäl. Antagning och autentisering är separata händelser som människor slår ihop till en.
Om antagningen fortsätter att gå ut, notera om portalen frågar igen, om nätverket tappas eller om bara VPN:n misslyckas.
Alternativ B: ett snävt inloggningsundantag, återställ sedan blockeringen
Alternativet är att tillåta portalens trafik medan blockeringen i övrigt gäller, logga in och sedan ta bort undantaget. Undantaget måste vara snävt: en destination eller ett adressområde, under inloggningens varaktighet, med blockeringen återställd omedelbart efteråt. Ett brett tillfälligt fönster är hur en inloggning på två minuter blir en eftermiddag av oskyddad trafik.
Vet vad din klient faktiskt implementerar. OpenVPN Connect på macOS dokumenterar captive portal-detektering separat från sitt alternativ som blockerar internetåtkomst medan VPN:n är pausad eller återansluter. Att upptäcka en portal och att tillåta dess trafik är närliggande uppgifter, inte utbytbara löften.
Följ den konfigurerade antagningsprocessen på en hanterad enhet i stället för att hitta på ett undantag.
Vad glappet exponerar, och för vem
Det intressanta med dödläget är inte fliken i webbläsaren framför dig. Det är allt annat som börjar använda nätverket i samma stund som anslutningen dyker upp: mejl, fotosynk, uppdateringskontroller, en chattklient som återansluter, en säkerhetskopieringsagent som återupptar.
Ett tyst webbläsarfönster säger ingenting om det. Stäng eller pausa känsligt arbete före varje tillåtet intervall med direktåtkomst, och kontrollera vad som körs vid inloggning. På Android är alltid på-VPN kombinerat med blockering av anslutningar utanför VPN:n den relevanta kontrollen, och ett godtyckligt route-undantag ersätter inte förståelsen av den.
Det här är den enda platsen där det äldre rådet om tillfälliga åtkomstfönster fortfarande håller. Oron var riktig även där mekanismen inte var det.
Hur du väljer och hur du bekräftar det
Välj alternativ A när enheten eller klienten stöder ett riktigt portalflöde, eftersom det håller blockeringen intakt hela tiden. Välj alternativ B när portalen inte kan nås på något annat sätt, och behandla undantaget som en tidsbegränsad ändring med en ägare.
Bekräfta sedan ordningen i stället för resultatet:
curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'Slutför antagningen, upprätta den avsedda profilen, återställ varje tillfälligt ändrad blockeringskontroll och gör sedan en ny ofarlig begäran och bekräfta att den följer tunneln. En begäran som lyckas eftersom blockeringen fortfarande är av bevisar ingenting om tunneln.
Att byta VPN-utgång förnyar inte en utgången hotellsession. Det är olika händelser, och att blanda ihop dem skickar dig att leta på fel ställe.