OpenVPN maakt geen verbinding op hotel-Wi-Fi? Probeer TCP 443

Open de client, druk op Verbinden en lees de statusregel in plaats van het venster dat daarna komt. Een profiel dat na een hotel-, campus- of mobiel netwerk blijft hangen op Verbinden of Wachten op server heeft meestal onderweg ergens zijn transport verloren, niet zijn inloggegevens. De nuttige volgende stap is uitzoeken wat dat netwerk vervoert voordat je de server aanraakt. Verander niets tot hetzelfde profiel elders heeft gewerkt.

Test eerst vanaf een hotspot van een telefoon. Als de tunnel daar opkomt, zijn de server, het certificaat en het account in orde, en is de enige variabele die overblijft het netwerk voor je.

Begin bij de client: lees de statusregel

De statusregel vertelt welke fase is mislukt. Een client die op Verbinden vastzit, lost nog de hostnaam op of opent de buitenste socket; een die Wachten op server bereikt, heeft een pad maar geen antwoord; een die authenticeert en daarna wegvalt, heeft een heel ander probleem. Het clientlog en de eigen remote- en proto-velden van het profiel laten zien wat de client probeert, en --verb 4 op een client vanaf de opdrachtregel print dezelfde details. Het vergelijken daarvan met het netwerk voor je is wat 'de VPN is geblokkeerd' in een concrete bewering verandert.

Probeer daarna het netwerk met gereedschap dat je al hebt. nc -vzu 203.0.113.10 1194 stuurt een UDP-datagram, curl -v telnet://203.0.113.10:443 meldt of een TCP-handshake voltooid wordt, en een browser die een HTTPS-pagina laadt bewijst alleen dat uitgaand 443 die ene host bereikt. Kleine probes beantwoorden wat de VPN-client niet kan: welke poort en welk protocol dit netwerk überhaupt verlaten.

Drie netwerkgedragingen lijken vanuit de client op elkaar en vragen verschillende antwoorden. Uitgaand 443 kan open zijn, alleen een proxy kan zijn toegestaan, of 443 kan transparant worden doorgestuurd naar een inspectiebox die niet kan lezen wat erin zit. Het eerste wordt verholpen door de profielwijziging hieronder, het tweede door proxyinstellingen, en het derde kan een handshake voltooien en daarna blijven hangen wanneer de inspecteur besluit dat hij de stroom niet mag. Weten welke van de drie je tegenover je hebt, is het verschil tussen een wijziging van tien minuten en een middag clients opnieuw installeren.

Verplaats de listener en het profiel samen

Zet aan de serverkant de listener op wat het netwerk toestaat: port 443 en proto tcp in de serverconfiguratie, herstart daarna de dienst en bevestig de socket met ss -lntp. Aan de clientkant moet het profiel meegaan, want transport en poort staan buiten de tunnel: proto tcp en port 443 in de .ovpn, of de overeenkomende velden in het instellingenscherm van de app. Een profiel dat nog op UDP 1194 is gericht, faalt precies zoals eerst, en de verleiding is om een firewall de schuld te geven die al is gerepareerd. Als dezelfde host ook HTTPS op 443 beantwoordt, kunnen de twee listeners dat adres en protocol niet delen; geef de VPN een tweede adres of zet er een demultiplexer voor.

Volg de eerste verbinding met tcpdump -ni any port 443 aan beide kanten. Pakketten die de client verlaten en nooit aankomen betekenen dat het netwerk toch filtert, of dat het adres in het profiel niet het adres is dat je aanneemt. Pakketten die aankomen zonder antwoord sturen je terug naar het serverlog, waar een protocolverschil meteen als een weggegooid pakket verschijnt.

Wanneer alleen een proxy het netwerk verlaat

Sommige gastnetwerken staan niets anders toe dan een HTTP-proxy, wat een andere beperking is dan een gesloten poort en meer uitsluit dan OpenVPN. Clients die alleen PPTP, L2TP/IPsec of kaal IPsec spreken, komen er niet doorheen, omdat die ontwerpen verwachten dat hun buitenste protocol de server rechtstreeks bereikt. OpenVPN kan het wel, met http-proxy proxy.example.net 8080 in het clientprofiel, mits de proxy de CONNECT-methode naar jouw poort toestaat. Een SOCKS-proxy is nog eenvoudiger, omdat die de stroom doorstuurt zonder zich te bekommeren om wat erin zit.

Waar de client geen proxyondersteuning heeft, blijft meestal een SSH-tunnel over 443 over. Die voegt een tweede laag toe, en de beheerder van het netwerk kan er een mening over hebben, dus behandel hem als een brug voor één reis en niet als een architectuur.

Bereken de prijs van de terugvaloptie voordat je hem houdt

TCP in TCP heeft een bekende prijs. Wanneer de buitenste verbinding TCP is en de payload ook TCP, veroorzaakt een verloren segment hertransmissie op beide lagen, en de binnenste verbinding deinst terug voor een verlies dat hij niet kan zien. Browsen doorstaat dat; interactieve sessies en gesprekken voelen het. Houd de TCP 443-listener als terugvaloptie voor netwerken die erom vragen, en laat UDP de standaard voor alles wat het nog doorlaat.

Leg de keuze vast in de profielnaam en in de supportnotities: welke poort, welk protocol en welk netwerk erom vroeg. Vraag daarna de beheerder van het netwerk of die poort na de volgende apparatuurvernieuwing open blijft, want een terugvaloptie die stilletjes verdwijnt is erger dan helemaal geen terugvaloptie.