Houd Wi-Fi-portal- en VPN-aanmeldingen uit elkaar
Twee verschillende systemen vragen om een aanmelding: de Wi-Fi van de locatie en je VPN-gateway. Ze lijken op het scherm op elkaar en machtigen totaal verschillende dingen. Vraag bij elk venster: wie kan dit geheim werkelijk verifiëren?
Twee verschillende systemen vragen je om in te loggen voordat je iets nuttigs bereikt op een openbaar netwerk: de Wi-Fi van de locatie en je VPN-gateway. Ze zien er op het scherm hetzelfde uit en machtigen totaal verschillende dingen. Het portaal bepaalt of dit apparaat het lokale netwerk mag gebruiken; de VPN bepaalt of jij een privénetwerk elders mag bereiken. Ik houd ze uit elkaar door bij elk venster één vraag te stellen: wie kan dit geheim werkelijk verifiëren? Wat volgt is de checklist die ik in hotels, op luchthavens en bij conferentielocaties doorloop, inclusief de punten waarop ik stop met typen.
Koppel elke aanmelding aan de dienst die hem controleert
Eén hotelverbinding kan vier afzonderlijke controles omvatten, en slechts enkele daarvan vragen om jouw invoer. Zet ze eerst in volgorde, want het scherm zegt zelden bij welke fase het hoort.
| Stage | Who checks it | What you give it | What it proves |
|---|---|---|---|
| Wi-Fi association | The access point | WPA2 passphrase or 802.1X credentials | That the device may join this SSID |
| Portal authorization | The venue or its portal provider | Room number, booking name, voucher, email or access code | That a guest may use local access |
| VPN authentication | Your gateway or identity provider | Client certificate, password, one-time code or SSO approval | That the user or device may enter the private network |
| Application login | Each internal service | That service's own account | That you may use that service |
802.1X-netwerken, gangbaar op kantoren en universiteiten, vervagen de eerste twee rijen. Daar is de Wi-Fi-aanmelding zelf een identiteitscontrole tegen een RADIUS-server, en de client kan een routeringsidentiteit presenteren terwijl het echte account binnen de versleutelde uitwisseling reist. Zelfs dan gaat de controle over het toetreden tot het netwerk; ze machtigt de tunnel niet, en de VPN-gateway accepteert haar niet als bewijs van iets.
De volgorde is belangrijker dan de labels. Captive portals bestaan omdat toegang na de associatie kan worden verleend, waardoor een locatie de pagina aan een gespecialiseerde provider kan geven. RFC 8952 van de IETF behandelt de portal als een eigen component, dus een onbekend domein is een reden om te verifiëren, niet op zichzelf bewijs van fraude. Vergelijk het domein met de schriftelijke instructies van de locatie, en de velden met de tabel.
Controleer waar een portal om mag vragen
Portaalvelden gaan over recht, niet over identiteit: kamernummer, achternaam van de boeking, vouchercode, de code op de sleutelhoes, een e-mailadres voor een tijdelijke pas, acceptatie van voorwaarden. De locatie weet al wie de kamer heeft geboekt, dus kan die feiten vergelijken zonder iets te leren dat haar in staat zou stellen elders als jou te handelen.
Alles buiten die lijst verdient een pauze. Een hotspotpagina kan je domeinwachtwoord niet verifiëren, en die kan ook je eenmalige VPN-code, een herstelcode of een privésleutel niet verifiëren, en heeft geen reden ze te willen. De enige legitieme uitzondering is een door een organisatie beheerd netwerk: een gast-SSID op kantoor of conferentie-Wi-Fi kan je doorsturen naar de identiteitsprovider die je al voor werk gebruikt. Het blijft herkenbaar: de inloghost is je dagelijkse, het toestemmingsscherm noemt je tenant, en de flow opent in een zichtbaar browsertabblad.
Marketing-e-mail staat apart: een reisalias vult het veld in zonder je werkidentiteit weg te geven.
Controleer of de VPN-client eigen inloggegevens wil
De client vraagt precies wat zijn profiel is geconfigureerd om te gebruiken, dus het verwachte venster is een eigenschap van het profiel en niet van het netwerk waarop je toevallig zit. Certificaatprofielen tonen meestal een profielkeuze en verbinden dan stil. Gebruikersnaam- en wachtwoordprofielen vragen beide, vaak met een eenmalige code. SSO-profielen openen je browser bij de identiteitsprovider en keren terug met een token. WireGuard is weer anders: het authenticeert apparaten met een publieke sleutel en heeft geen gebruikerslogin, dus een venster dat een WireGuard-gebruikersnaam en -wachtwoord biedt, beschrijft WireGuard niet.
Lees het profiel voordat je reist. In OpenVPN vertelt auth-user-pass je dat een wachtwoordvraag wordt verwacht, terwijl cert, key of pkcs12 betekent dat een certificaat het werk hoort te doen. Als een profiel dat normaal zonder vraag verbindt plotseling een wachtwoord vraagt, verdenk dan een profiel dat zijn certificaat niet kon laden of terugviel op een andere methode. Een vraag is geen uitnodiging om je werk-wachtwoord in welk venster dan ook te typen.
Geen enkele legitieme VPN-client vraagt het kamernummer, de portalvoucher of de Wi-Fi-wachtwoordzin als authenticatie-invoer. Als dat gebeurt, is de client ofwel niet wat hij beweert te zijn, of een captive portal onderschept verkeer voordat de tunnel ontstaat en je leest een HTML-pagina die als een login is opgemaakt.
Stop bij deze vijf voorwaarden
Dit zijn de punten waarop ik stop in plaats van door te gaan met een plausibele omweg. Elk is goedkoop te controleren en duur om fout te doen.
- Op het portaal of de SSO-pagina verschijnt een certificaat- of TLS-waarschuwing. Klik er niet doorheen om het netwerk te bereiken.
- De pagina vraagt een geheim dat alleen de VPN-gateway of de identiteitsprovider kan verifiëren: domeinwachtwoord, eenmalige code, herstelcode, privésleutel.
- Het domein komt niet overeen met de gedrukte instructies van de locatie of met de inloghost die je organisatie voor haar eigen diensten documenteert.
- Je wordt gevraagd een rootcertificaat, een configuratieprofiel of een hulpprogramma te installeren dat niet uit je apparaatbeheer komt.
- Er komt een MFA-goedkeuring binnen die je niet hebt gestart, of de VPN-client vraagt om hotelgegevens.
Het alternatief is geen ander wachtwoord. Gebruik een telefoonhotspot, vraag bij de receptie naar de exacte netwerknaam en toegangsmethode, en meld de pagina bij wie het netwerk beheert of bij je IT-desk. Niets daarvan vereist het testen van inloggegevens tegen een pagina die je niet kunt toeschrijven.
Wijs een storing toe aan de juiste fase
Nadat beide fasen zijn geslaagd, gebeuren er nog steeds fouten, en de fout noemt meestal de fase als je die op volgorde leest: associatie, adresuitgifte, portaalautorisatie, tunnelopbouw, dan de interne bron. Een VPN-wachtwoord wijzigen omdat een portaalcode is verlopen kost tijd en laat het echte probleem staan.
Een paar tests scheiden de fasen. Vraag na de portaallogin een gewone openbare HTTPS-pagina aan. Komt de portal in plaats daarvan terug, dan is de autorisatie op die laag nooit voltooid. Meldt de VPN-client dat hij de gateway niet bereikt, dan zit het probleem onder de tunnel: de portalsessie, naamresolutie of een netwerk dat de poort blokkeert. Komt de tunnel op en faalt één interne hostnaam, dan zijn naamresolutie of beleid binnen het privénetwerk de betere verdenking.
Portalsessies verlopen ook onafhankelijk van de tunnel. Als de locatie de toegang intrekt, valt een bestaande VPN-verbinding weg, ook al waren de inloggegevens nooit fout. Autoriseer de portal opnieuw, verbind daarna de VPN opnieuw en laat die opnieuw onderhandelen. Het VPN-wachtwoord dan roteren lost niets op en kan je buitensluiten.
Geef elk geheim alleen aan het systeem dat het kan verifiëren, en behandel een vraag die niet bij de tabel past als een stopteken en niet als een stap om te omzeilen. Als beide fasen slagen en de tunnel weigert nog steeds, leg dan de exacte clientfout vast voordat je inloggegevens wijzigt.