Waarom een OpenVPN-profiel thuis werkt maar in een hotel faalt

Kantoor-wifi en een hotelkamer kunnen dezelfde laptop twee heel verschillende netwerken geven, en het profiel daartussen weet daar niets van. Wat thuis werkt, veronderstelt een toegeeflijke uplink, werkende naamresolutie en een lokaal subnet dat niet botst met iets wat de tunnel vervoert. Elk van deze aannames kan afzonderlijk mislukken.

De nuttige manier om dit te debuggen is het netwerk als vier afzonderlijke feiten te behandelen en ze dan op volgorde te testen. Eerst aan het profiel raden levert meestal een wijziging op die niets oplost en het bewijs vertroebelt.

Vier netwerkfeiten veranderen per locatie

Het eerste feit is of het lokale netwerk je überhaupt naar buiten laat. Een captive portal laat een apparaat toe op een inlogpagina en blokkeert al het andere tot die pagina is voltooid, wat betekent dat de tunnel niet kan starten, hoe correct het profiel ook is.

Het tweede is naamresolutie. Een portal die DNS onderschept, antwoordt elke query met zijn eigen adres, zodat de VPN-hostnaam naar de portal resolvet en de client een tunnel naar een webpagina probeert te bouwen.

Het derde is transportfiltering. Netwerken die alleen browsen willen toestaan, laten TCP 443 naar willekeurige bestemmingen door en laten bijna al het andere vallen, inclusief UDP.

Het vierde is adressering. Het lokale subnet kan overlappen met een netwerk achter de tunnel, of de uplink biedt helemaal geen bruikbare IPv4-route.

Naamresolutie en de captive portal

Vervang de hostnaam in het profiel door het numerieke adres van de server en probeer opnieuw. Als de IP verbindt en de naam niet, is naamresolutie de schuld, en het profiel zelf is in orde.

Open een browser en probeer een gewone HTTP-pagina voordat je de VPN aanraakt. Een omleiding naar een inlogpagina betekent dat de portal nog openstaat; voltooi die en maak daarna opnieuw verbinding. Veel hotels laten de sessie ook na een paar uur verlopen, wat eruitziet als een onderbreking midden op de dag in plaats van een inlogprobleem.

Als het numerieke adres ook faalt, is naamresolutie niet de verklaring, dus ga naar het transport. Bewaar het adres dat je testte, want het vertelt de volgende controle of pakketten de machine überhaupt hebben verlaten.

Transportfiltering: eerst UDP, TCP 443 als terugvaloptie

Een OpenVPN-stroom over UDP 1194 ziet eruit als niets dat een hotelfirewall herkent, dus wordt hij zonder fout weggegooid. De client probeert opnieuw tot de time-out verloopt, en de gebruiker ziet een verbinding die nooit tot stand komt in plaats van een weigering. Firewalls die zich zo gedragen, loggen het weggooien zelden ergens waar je het kunt zien. Het ontbreken van een weigering is zelf de aanwijzing.

TCP 443 is de betrouwbare terugvaloptie omdat het netwerk het niet kan onderscheiden van gewone HTTPS. Gebruik het TCP-profiel van de operator als dat bestaat, omdat de server ook op dat transport en die poort moet luisteren; alleen de client wijzigen levert een ander soort fout op. Als er geen TCP-profiel is, vraag het de operator in plaats van er zelf een te verzinnen door de poort te bewerken. De serverkant moet instemmen, en een mismatch ziet er weer uit als een firewallprobleem.

Verwacht een prestatieprijs. TCP in TCP versterkt hertransmissies op een verbinding met verlies, dus een werkende TCP-tunnel kan op een druk hotelnetwerk toch traag aanvoelen. Dat is een ruil voor bereikbaarheid, geen fout om achteraan te jagen.

Adresconflicten en uplinks zonder IPv4

Een tunnel kan tot stand komen en toch niets vervoeren. Wanneer het lokale LAN en een extern netwerk een prefix delen zoals 192.168.1.0/24, beschouwt de client de externe host als direct verbonden en stuurt het pakket naar de lokale verbinding in plaats van de tunnel. Het symptoom is een geslaagde verbinding met één onbereikbaar subnet, wat gemakkelijk verkeerd wordt gelezen als een routeprobleem aan de serverkant.

De blijvende oplossing is het externe LAN naar een ongebruikelijk privébereik te verplaatsen. Een bereik kiezen dat niemand thuis gebruikt, zoals 10.42.0.0/24, voorkomt het probleem voor elke toekomstige locatie in plaats van één. De lokale omweg is dat hotel, die hotspot of die router vermijden, wat helemaal geen oplossing is.

Mobiele uplinks voegen twee varianten toe. Carrier-grade NAT betekent dat inkomende verbindingen niet aankomen, wat uitmaakt als je een server host maar niet voor een uitgaande client. Een APN die alleen met IPv6 en NAT64-vertaling is geconfigureerd, kan een client laten falen die op een echte IPv4-route staat, en het gebruikelijke middel is het APN-protocol naar IPv4 of dubbele stack te wijzigen.

Symptomen nadat de tunnel staat

Een tunnel die verbindt en dan stilvalt, is meestal een keepalive- of MTU-probleem, geen geblokkeerde poort. Een verbinding die na een vast aantal minuten wegvalt, wijst op een keepalive- of heronderhandelingstimer. Stel de client in om zijn peer te peilen en opnieuw te starten wanneer antwoorden stoppen, en test een kleinere tunnel-MTU als pings werken terwijl grote overdrachten vastlopen.

Voordat je om hulp vraagt, schrijf drie dingen op: het adres dat je probeerde en of het antwoordde, het transport en de poort die je gebruikte, en het lokale subnet van het netwerk dat faalde. Samen scheiden ze naamresolutie van transportfiltering en van een adresconflict, en dat zijn de oorzaken die contact met bewijs overleven.