Waarom het captive portal je VPN blokkeert en hoe je opnieuw inlogt

Op een open netwerk geeft je accesspoint pakketten niet zomaar door aan het internet. Een beleidspunt stroomopwaarts controleert of je apparaat al is geautoriseerd, en tot die tijd wordt bijna alles weggegooid. Je VPN-client leest die stilte als een dode server. Zelden zegt hij dat: WireGuard herhaalt een handshake in het niets, OpenVPN meldt een verbindingstime-out, en IKEv2 komt terug als fout 809 over een externe server die niet reageert.

Wat het portaal werkelijk beheert

Een captive portal zijn twee dingen aan elkaar gelijmd: een beleidsbeslispunt en een omleider. Wanneer je apparaat verbindt en een DHCP-lease neemt, zet het netwerk je in een toestand vóór autorisatie.

Die toestand is een set firewallregels. Meestal staat DNS toe en staat HTTP of HTTPS toe naar een korte lijst portaalhosts, en al het andere wordt weggegooid. De toegestane lijst is de ommuurde tuin, en die bevat bijna nooit een VPN-eindpunt.

Geen van die weggooiingen is beleefd. Pakketten naar een VPN-server worden weggegooid in plaats van geweigerd, dus de client krijgt geen ICMP unreachable en geen TCP reset, alleen het ontbreken van een antwoord. Afhankelijk van de leverancier kan de omleider poort 80 beantwoorden met een omleiding naar de inlogpagina terwijl poort 443 wordt weggegooid of onderschept. Omleidingen zijn makkelijk te herkennen omdat ze een gewoon HTTP-antwoord dragen; onderschepping op 443 vereist een certificaat dat je browser weigert te vertrouwen.

De autorisatie zelf is meestal gekoppeld aan het MAC-adres van het apparaat, soms aan het geleasete IP, en ze leeft in een sessietabel met een timer. Inloggen maakt een vermelding aan. De firewallregel die jouw verkeer doorlaat bestaat alleen zolang die vermelding bestaat, en daarom komt het hele probleem later terug zonder dat er aan jouw kant iets verandert.

Waarom de VPN-handshake sterft voordat hij begint

Elk protocol heeft zijn eigen transport, en de firewall vóór autorisatie breekt elk ervan anders. IKEv2 op Windows en iOS loopt over UDP 500 en UDP 4500; een weggooiing op die poorten verschijnt als 809, of als een naamresolutie-achtige fout bij clients die fasen apart melden. OpenVPN over UDP 1194 blijft in verbindingstoestand tot zijn time-out verloopt. OpenVPN over TCP 443 is het interessante geval, omdat het portaal de TCP-handshake kan voltooien en dan met zijn omleidingspagina kan antwoorden, zodat je een TLS-fout ziet in plaats van een time-out.

WireGuard toont het mechanisme het duidelijks. Het is ontworpen als alleen UDP, zonder TCP-terugval, dus een firewall die onbekend UDP weggooit verwijdert het transport volledig. De client blijft handshake-initiaties sturen met groeiende wachttijd en meldt een handshake die nooit voltooid wordt. Niets in dat bericht noemt wifi, en niets erin suggereert dat je een browser moet openen.

Platformen proberen de toestand eerder op te merken dan je VPN. Windows haalt een bekende URL op om te beslissen of het zijn inlogmelding toont, Android vraagt een eindpunt op dat 204 No Content zou moeten antwoorden, en Apple-apparaten openen een klein captive-netwerkvenster. Die probes werken omdat het portaal antwoordt met een omleiding in plaats van de verwachte body. Hetzelfde gedrag verklaart hoe een portaal volkomen gezond kan lijken terwijl je tunnel dood is: de probe en de tunnel worden volgens verschillende regels beoordeeld.

Wat een sessieverloop werkelijk reset

Locaties laten sessies verlopen om redenen die niets met je VPN-account te maken hebben: een time-out bij inactiviteit, een maximale sessieduur, een nieuwe DHCP-lease of een herverbinding met een ander accesspoint. Wanneer de timer afgaat, verdwijnt de vermelding in de sessietabel en komt de regelset vóór autorisatie precies terug zoals hij bij het inchecken was.

Een opgezette tunnel overleeft vaak lang genoeg om gezond te lijken. Keepalives blijven uitgaan, en of de client het merkt hangt af van hoe hij onbeantwoord verkeer behandelt, dus het statuslampje kan nog een tijdje groen blijven nadat het pad weg is. Dan valt de tunnel weg en elke herverbinding mislukt op dezelfde geblokkeerde poorten.

Op dat punt vertelt de clientfout je in welke fase je zit, als je hem aandachtig leest:

Eén detail misleidt mensen: wanneer de sessie aan een MAC-adres is gebonden, helpt het herladen van de inlogpagina misschien niet. Je moet de verbinding verbreken en opnieuw deelnemen, zodat het portaal een nieuwe autorisatiepoging ziet in plaats van een verlopen.

Log eerst in, til dan de tunnel op

De volgorde die werkt is: autoriseer het apparaat, bewijs het pad, start de VPN, bewijs de tunnel en herstel daarna je normale blokkering. Die laatste stap is belangrijk omdat de tijdelijke toestand die je nodig hebt om het portaal te bereiken precies de toestand is die een kill switch moet voorkomen.

Een desktopclient met de optie om buiten de tunnel te blokkeren moet worden gepauzeerd zodat de portaalpagina laadt, en je moet gevoelige apps gesloten houden tijdens dat venster buiten de tunnel; het is het enige interval waarin lokaal verkeer onbeschermd naar buiten gaat. Een beheerd, altijd ingeschakeld apparaat moet de procedure van zijn eigenaar gebruiken in plaats van dat jij het beleid verwijdert. Als het portaal een certificaatwaarschuwing toont, stop: die accepteren leidt je sessie door de onderscheppingsproxy van de locatie, en die proxy kan alles lezen wat je verstuurt. Op Android blokkeert de vergrendeling onder altijd-aan-VPN verkeer voordat de tunnel staat, en sommige builds kunnen de portaalstroom niet uitzonderen; als die van jou dat niet kan, gebruik dan de alternatieve toegang van de locatie of een ander apparaat in plaats van de vergrendeling uit te laten. Apples on-demand-regels kunnen zo worden geschreven dat ze de tunnel weigeren tot een probe slaagt, en dat is het gedrag dat je op hotelnetwerken wilt.

Verifieer op volgorde met de hulpmiddelen die je al hebt. Voer vóór de tunnel de probe uit met zowel headers als body zichtbaar, en kijk of je VPN-transport überhaupt een antwoord krijgt:

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'

Vóór autorisatie geeft een normaal portaal een van twee antwoorden: een 302 waarvan de Location naar de inlogpagina wijst, of een 200 met een HTML-body die de portaalpagina is. Noteer welke je kreeg. Een omleiding is vóór het inloggen geen fout; het portaal vertelt je waar je heen moet. Nadat het portaal succes meldt, herhaal je de opdracht en verwacht je een 200 waarvan de body het letterlijke woord Success is. Die tekenreeks maakt de probe zinvol. Als de host normaal antwoordt voordat je ooit hebt ingelogd, is er op dit netwerk geen onderscheppend portaal. In de opname is een weggooiing vóór autorisatie uitgaand verkeer waar niets van terugkomt, terwijl een pad dat werkt een antwoord op dezelfde stroom binnen ongeveer een seconde laat zien. Maak verbinding en herhaal dan de opname.

Als de tunnel blijft falen nadat het portaal ja zegt

Inlogsucces is niet hetzelfde als toegestaan transport. Veel locaties staan het portaal en gewoon browsen toe terwijl ze UDP volledig blokkeren, waardoor WireGuard en UDP-OpenVPN kapot blijven en TCP 443 werkt. Als TCP 443 doorkomt en UDP niet, is dat het beleid van de locatie en niet een client die je verkeerd hebt geconfigureerd, dus wissel van transport of accepteer de grens en ga verder. Als een herverbinding daarna nog steeds mislukt, bewaar dan de exacte fout; die noemt de fase waarin je vastzit.

Andere fouten leven op het apparaat. Een sessie die nog aan een oude MAC is gebonden, een tweede wifi-adapter met zijn eigen lease, of een client die de certificaatafwijking van het portaal heeft gecachet, kunnen elk na een schone herautorisatie blijven falen. Verbreek de verbinding, autoriseer opnieuw en probeer het één keer voordat je clientinstellingen aanraakt. RFC 8952 is de moeite waard als je de architectuur achter de componenten wilt die je observeert.

Als het portaal zelf weigert te autoriseren, zit het probleem in het account of de apparaattoewijzing en geen enkele VPN-instelling lost dat op. Het wijzigen van het uitgangsland van de VPN reset de lokale toegangstoestand van de locatie niet; die tabel is aan jouw apparaat gebonden, niet aan de server die je kiest. Vraag de exploitant van de locatie en geef hem de tijd, want de sessietabel is wat hij zal bekijken.

Schrijf vóór je volgende reis drie dingen op: de portaalpagina als stap nul, de stap om de blokkering te pauzeren voor elk apparaat dat je meeneemt, en één transportterugval die je echt hebt getest. Wanneer een tunnel die tien minuten geleden werkte weer stopt, behandel dat als een verlopen autorisatie en controleer het portaal opnieuw voordat je het VPN-profiel aanraakt.