Hotel-wifi: de VPN mislukt voordat hij de server ooit bereikt

De VPN-client draait, meldt dan dat hij de server niet kan bereiken, en iedereen concludeert dat het hotel VPN's blokkeert. Meestal is er niets zo dramatisch gebeurd: het netwerk heeft je nog niet naar buiten gelaten. Een captive portal houdt elke verbinding tegen tot je inlogt, en een tunnel kan niet tot stand komen zolang een inlogpagina zijn pakketten onderschept. Doorloop de inlog voordat je de tunnel de schuld geeft.

De mythe: het hotel blokkeert VPN's

De meeste hotelnetwerken filteren tunnels niet specifiek. Ze onderscheppen webverkeer tot de gast zich authenticieert, en ze kunnen ook apparaten beperken, sessies laten verlopen of de doorvoer knijpen. Elk daarvan levert een storing op die van binnenuit een VPN-client op een blokkade lijkt.

De tunnel is hier een slechte diagnose, want het is de enige toepassing die gegarandeerd mislukt zolang het portaal niet is geautoriseerd. Gewone webtoegang is de betere indicator, omdat die je de inlogpagina zelf kan tonen.

Die volgorde is om een andere reden belangrijk: een client met kill switch of always-on-modus weigert het portaal te laden, en de gebruiker concludeert dat het netwerk stuk is in plaats van de instelling. Beide feiten zijn tegelijk waar, en slechts een ervan kan in het hotel worden veranderd. Schakel de bescherming uit via de eigen bediening van de client, log in en zet hem daarna weer aan. Al het andere is een omweg die de echte volgorde verbergt.

Rond eerst het portaal af en test dan gewone HTTPS

Vraag het personeel naar de officiele netwerknaam en de inlogmethode. Een overtuigende SSID is geen bewijs van eigendom, en een tweede netwerk met een vergelijkbare naam is een veelvoorkomende truc op openbare plaatsen. Gebruik de eigen inlogvraag van het besturingssysteem waar die wordt geboden, of de gedocumenteerde pagina van het hotel.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

De eerste aanvraag vraagt een bekend detectiepunt voor captive portals op via gewone HTTP; een omleiding of onverwachte inhoud betekent dat je nog achter het portaal zit. De tweede test een normale HTTPS-site. Als de eerste onderschepping toont en de tweede mislukt, is de inlog onvolledig en heeft de VPN er niets mee te maken.

Op een persoonlijk apparaat moet de kill switch of altijd-aan-VPN mogelijk worden uitgeschakeld via de ondersteunde bediening van de client zodat het portaal kan laden. Sluit gevoelige toepassingen in dat venster en zet de bescherming daarna direct weer aan. Op een beheerd apparaat volg je de procedure die de beheerder heeft goedgekeurd in plaats van zelf een beleid te verwijderen.

Omzeil nooit een certificaatwaarschuwing en installeer nooit een onbekend certificaat of hulpprogramma om online te komen. Als het portaal iets onverwachts eist, bevestig dat met het personeel, en met de beheerder als het apparaat van een werkgever is.

Bewaar het oorspronkelijke profiel en zijn fout

Zodra gewone toegang werkt, verbind je het oorspronkelijke profiel en noteer je de exacte fout. Een authenticatieweigering is een accountprobleem, een time-out tijdens de onderhandeling is een padprobleem, en een tunnel die tot stand komt maar niets vervoert is een routerings- of beleidsprobleem.

Die drie vragen om verschillende vervolgstappen, en een schermafbeelding van de fout is meer waard dan een beschrijving. Noteer ook de tijd, want sessielimieten van het hotel kunnen binnen een uur verlopen en een storing veroorzaken die willekeurig lijkt. Als de client een log biedt, bewaar dan het deel rond de eerste storing en niet het hele bestand. Dat fragment is meestal genoeg voor de eigenaar van het profiel om de fase te herkennen.

Als gewone toegang werkt en de onderhandeling verloopt nog steeds, vraag het hotel dan of het dat verkeer ondersteunt, en vergelijk met een vertrouwde hotspot terwijl het apparaat en het profiel gelijk blijven. Werken op de hotspot richt de aandacht op het hotelpad zonder iets over het profiel te bewijzen.

Gebruik alleen de alternatieven die de operator levert

Een passend TCP-profiel kan slagen waar het aangeboden UDP-pad niet werkt, maar alleen als de server echt luistert op dat transport en die poort. TCP-poort 443 wordt niet automatisch als gewone HTTPS behandeld, en het is geen garantie voor doorgang door een beperkend netwerk.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Het geleverde profiel met meer detail draaien houdt de eerste bruikbare fout zichtbaar in plaats van hem in een algemene foutdialoog samen te persen. Gebruik het bestand dat de operator gaf in plaats van zelf poorten of protocollen te bewerken, want een lokale wijziging kan aan de andere kant geen passende luisteraar maken.

Als de tunnel herhaaldelijk reset, noteer dan of het portaal terugkomt of het lokale signaal wegvalt, en volg de stabiliteitscontroles in plaats van meerdere protocollen tegelijk te wisselen. Test daarna de toepassing die je echt nodig hebt en herstel de normale privacy-instellingen. Een verbinding die de ene site wel vervoert en de andere niet is een routerings- of beleidsvraag, geen portaalvraag.

Controleer ten slotte het herstel nadat de laptop heeft geslapen. De autorisatie van het portaal kan onafhankelijk van de tunnel verlopen, dus een apparaat dat automatisch opnieuw verbindt kan terugkomen op een netwerk dat het al vergeten is. De portaalpagina opnieuw openen is een normale stap, geen teken dat de VPN stuk is.