Captive portal en VPN in patstelling: wie beweegt eerst

Het portaal van het hotel wil een browser zien voordat het verkeer doorlaat. Je VPN weigert verkeer door te laten voordat zijn tunnel actief is. Elke kant wacht op de ander, en beide gedragen zich precies zoals ingesteld. Alleen twee volgordes doorbreken die patstelling, en ze verschillen in wat ze blootleggen terwijl de tussenruimte open is. Kies er bewust een in plaats van te sleutelen aan welke instelling dan ook waardoor de browser laadt.

Twee volgordes, een ervan werkt

Of het netwerk laat je eerst binnen en de tunnel komt daarna, of je opent een smalle uitzondering voor het portaal en herstelt daarna de blokkade. Beide zijn legitiem. Wat niet legitiem is, is de blokkade uitzetten en vergeten hem terug te zetten.

De twee volgordes zijn niet in elke situatie even goed. Een beheerd apparaat met een verplicht toelatingsproces heeft een antwoord, een persoonlijke laptop op hotel-Wi-Fi een ander. De vergelijking gaat over wat elke optie opgeeft.

Begin met te weten welke van de twee je client en je apparaatbeleid werkelijk ondersteunen.

Optie A: laat het netwerk je toe, verbind daarna de tunnel

Bevestig de verwachte netwerknaam en gebruik dan de aanmeldvraag van het besturingssysteem of de door de client ondersteunde captive-portalstroom. Op iPhone en iPad kan het sluiten van het aanmeldblad de associatie verbreken of hem behouden met een waarschuwing dat het netwerk geen internet heeft, en dat zijn verschillende startpunten. Rond eerst de toelatingsstap af en breng daarna de tunnel op. Deze volgorde houdt de blokkade ongeschonden zolang de tunnel down is.

De addertje onder het gras is dat een portaal dat internettoegang autoriseert, je VPN-account niet heeft geauthenticeerd. De tunnel moet daarna alsnog verbinden, en kan om zijn eigen redenen mislukken. Toelating en authenticatie zijn afzonderlijke gebeurtenissen die mensen tot een geheel samensmelten.

Als de toelating blijft verlopen, let dan op of het portaal opnieuw vraagt, het netwerk wegvalt of alleen de VPN faalt.

Optie B: een smalle aanmelduitzondering, daarna de blokkade herstellen

Het alternatief is het verkeer van het portaal toe te staan terwijl de blokkade verder van kracht blijft, je aan te melden en daarna de uitzondering te verwijderen. De uitzondering moet smal zijn: een bestemming of een adresbereik, voor de duur van de aanmelding, met de blokkade direct daarna hersteld. Een breed tijdelijk venster is hoe een aanmelding van twee minuten een middag onbeschermd verkeer wordt.

Weet wat je client werkelijk implementeert. OpenVPN Connect op macOS documenteert captive-portaldetectie apart van zijn optie die internettoegang blokkeert terwijl de VPN is gepauzeerd of opnieuw verbindt. Een portaal detecteren en zijn verkeer toestaan zijn verwante taken, geen uitwisselbare beloftes.

Volg op een beheerd apparaat het ingestelde toelatingsproces in plaats van een uitzondering te verzinnen.

Wat de tussenruimte blootlegt, en aan wie

Het interessante deel van de patstelling is niet het browsertabblad voor je. Het is al het andere dat het netwerk gaat gebruiken op het moment dat er verbinding verschijnt: mail, fotosynchronisatie, updatecontroles, een chatclient die opnieuw verbindt, een back-upagent die hervat.

Een stil browservenster vertelt je daar niets over. Sluit of pauzeer gevoelig werk voor elk toegestaan interval met directe toegang, en controleer wat er bij het inloggen draait. Op Android is always-on VPN gecombineerd met het blokkeren van verbindingen buiten de VPN de relevante beheersmaatregel, en een willekeurige route-uitzondering is geen vervanging voor begrip ervan.

Dit is de enige plek waar het oudere advies over tijdelijke toegangsvensters nog steeds geldt. De zorg klopte, ook waar het mechanisme dat niet deed.

Hoe je kiest en hoe je het bevestigt

Kies optie A wanneer het apparaat of de client een echte portaalstroom ondersteunt, want die houdt de blokkade doorlopend ongeschonden. Kies optie B wanneer het portaal op geen andere manier bereikbaar is, en behandel de uitzondering als een tijdelijke wijziging met een eigenaar.

Bevestig daarna de volgorde in plaats van de uitkomst:

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

Rond de toelating af, breng het bedoelde profiel tot stand, herstel elke tijdelijk gewijzigde blokkeringsmaatregel en doe dan een nieuw onschadelijk verzoek en bevestig dat het de tunnel volgt. Een verzoek dat slaagt omdat de blokkade nog uit staat, bewijst niets over de tunnel.

Het wisselen van de VPN-uitgang verlengt een verlopen hotelsessie niet. Dat zijn verschillende gebeurtenissen, en ze door elkaar halen stuurt je naar de verkeerde plek.