OpenVPN werkt thuis maar niet op één netwerk: UDP of TCP?

Hetzelfde profiel verbindt thuis en blijft hangen op een hotel-, campus- of vestigingsnetwerk. De inloggegevens zijn niet veranderd, dus de interessante variabele is het pad: wat er met de pakketten gebeurt voordat OpenVPN ze leest. Vier mogelijke oorzaken vergelijken in de volgorde waarin ze te testen zijn, is beter dan gissen naar certificaten. Elk laat een ander spoor achter, en dat spoor is wat ze onderscheidt.

Welke fase faalde, bepaalt welke vergelijking ertoe doet

Het clientlog legt al vast hoe ver je kwam. Een regel dat TLS-sleutelonderhandeling niet binnen de time-out plaatsvond, betekent dat een eerste pakket vertrok en er niets bruikbaars terugkwam, wat op het pad wijst. Een certificaatweigering ziet er totaal anders uit: er komt een antwoord, en dan noemt een specifieke verificatiefout de reden. Noteer de laatste regel vóór de herhaallus, want dat is de waarde die je tussen netwerken vergelijkt.

Leg vast tijdens het opnieuw proberen, niet daarna. Op de client laat tcpdump -ni any udp port 1194 zien of er überhaupt een antwoord terugkomt. Herhaal het op de WAN-interface van een server die je beheert, wat onthult of die pakketten het verre uiteinde überhaupt bereiken.

Eenrichtingsverkeer is hier het nuttigste resultaat, want het verandert een terugkerende klacht in een onderzoeksrichting. Bewaar de capturebestanden, want de volgende melding van hetzelfde probleem sluit je makkelijker met bewijs dan met een beschrijving.

UDP-filtering versus een gesloten poort

Veel toegangsnetwerken vinden aanhoudende UDP verdacht, en sommige ISP's zijn het daarmee eens. Een gesloten poort levert dezelfde stilte vanaf de clientzijde. Het verschil is selectiviteit: een filter is vaak kieskeurig over welke bestemmingen of poorten het laat vallen, terwijl een gesloten poort alles naar die ene poort weigert.

Een TCP-profiel op poort 443 is de gebruikelijke oplossing, omdat het op een gewone HTTPS-stroom lijkt en de meeste captive portals en uitgaande filters passeert. Er moeten twee voorwaarden gelden. De server moet luisteren met proto tcp-server en de client moet overeenkomen met proto tcp-client, en de operator moet dat alternatieve endpoint publiceren. Een werkend UDP-profiel herschrijven om TCP 443 te claimen, levert niets op als er aan de andere kant niets luistert.

Een gesloten poort is een configuratieprobleem, geen censuurprobleem. Een server achter een thuisrouter heeft port forwarding voor zijn UDP-poort nodig, en de routerfirewall moet dat toestaan. Als de poort nooit is toegestaan, faalt elke client bij de onderhandeling ongeacht de inloggegevens, en de fout volgt de server in plaats van het netwerk.

Oudere protocollen scoren slecht op deze as. PPTP vereist TCP 1723 plus GRE, en GRE is IP-protocol 47, geen poort, dus geen gewone port forward drukt dat uit.

Wanneer de switch de pakketten laat vallen

Een beheerde switch kan de tunnel met opzet laten vallen. Sommige HPE- en Aruba-modellen bieden een UDP-floodbeveiligingsregeling, soms aangeduid als Prevent UDP Blat Attack, in hun geavanceerde beveiligingssectie. Zodra die regeling actief is, antwoordt een server achter de switch nergens op en loopt elke client op dezelfde manier in een time-out. Hem uitzetten en de actieve configuratie opslaan is de hele reparatie, maar pas nadat je hebt vastgesteld dat de switch echt in het pad zit.

Tegenbewijs is wat een switch-drop van een providerblokkade onderscheidt. Lees de interfacetellers en het floodbeveiligingslog voordat je een ticket bij de ISP opent. Consumentenrouters met DoS- of floodbeveiliging falen op dezelfde manier, en elke middlebox met een korte UDP-idle-time-out ook. Een handshake die nooit voltooit wijst op een drop, terwijl een tunnel die na minuten stilte sterft op de time-out wijst.

Schrijf elk apparaat tussen client en server op voordat je een profiel wijzigt. Een oplossing op de verkeerde laag lijkt goed tot het volgende netwerk. Die lijst vertelt de volgende engineer ook waar hij moet kijken zonder het hele onderzoek te herhalen.

Een adresoverlap die op een DNS-fout lijkt

Een toegangsnetwerk dat binnen 10.0.0.0/8 is genummerd, kan overlappen met de tunnelpool, en de resolver woont meestal in die pool. Wanneer een laptop op Wi-Fi een adres zoals 10.184.178.50 met een /8-masker krijgt, is elke 10.x-bestemming per definitie lokaal. Pakketten voor 10.4.0.1 gaan dan naar de LAN, de tunnel blijft overeind en naamresolutie faalt.

ip addr toont de overlap in één oogopslag, en ip route get 10.4.0.1 laat zien waar het pakket werkelijk zou worden afgeleverd. Omdat het zichtbare symptoom een resolverfout is, overleeft deze vaak meerdere rondes DNS-wijzigingen.

Hernummer de pool of houd dat toegangsnetwerk buiten scope. Geen enkele clientinstelling herstelt van een overlap.

Kiezen tussen een TCP-fallback en een padoplossing

Kies de TCP-fallback als je het pad niet beheert en gebruikers vandaag moeten werken, en accepteer de kosten: TCP in TCP gedraagt zich slecht op links met verlies, en de fallback vereist een listener die jij beheert. Kies de padoplossing als de blokkade op infrastructuur van jou zit, want een firewallregel is goedkoper dan een tweede listener. Werk hoe dan ook de lagen in volgorde af: link, buitenste transport, onderhandeling, interne routering. De fase die op dat netwerk faalde, is het enige feit dat ertoe doet.

Leg het resultaat per netwerk vast, niet per gebruiker. De volgende melding van dezelfde fout begint dan bij een bekende fase in plaats van bij een certificaattheorie. Dat verslag is ook wat een permanente tweede listener rechtvaardigt, als die ooit nodig is.