proto udp of tcp-client: welke hoort jouw server?

Een profiel dat vorige maand werkte, loopt nu in een time-out, en iemand stelt voor om proto udp te vervangen door proto tcp-client. Soms is dat de juiste stap, en soms levert het een client op die verbinding maakt met een poort waar niets luistert, omdat de server nooit voor het andere transport is geconfigureerd. De richtlijn beschrijft hoe jouw kant praat; hij kan aan de andere kant geen luisteraar maken. Lees het profiel en de server samen voordat je een van beide wijzigt.

Lees het transport dat de gekozen verbinding gebruikt

Een profiel kan meerdere remote-regels bevatten, en elk daarvan kan zijn eigen transport noemen. De client werkt ze op volgorde af, dus de regel die je het eerst ziet is niet noodzakelijk degene die geldt.

Zoek de regel die daadwerkelijk wordt geprobeerd en lees dan het transport. De volgorde is belangrijk, want de client gaat niet stilzwijgend verder. Sommige builds proberen de volgende regel pas na een time-out, dus een werkend alternatief onderaan het bestand wordt seconden later bereikt dan je verwacht. Kijk in het log welke endpoint wordt geprobeerd in plaats van aan te nemen dat de eerste regel heeft gewonnen.

Als het bestand één proto-regel bovenaan heeft en daaronder meerdere remote-regels, dan is die regel de standaard voor elke remote die hem niet overschrijft. Een lokale aanpassing van de standaard doet niets voor een remote-regel die zijn eigen transport noemt.

grep -nE '^(remote|proto)\b' client.ovpn

UDP en TCP zijn geen snelheidsinstelling

UDP verstuurt datagrammen zonder een geordende stroom op te bouwen, dus het eigen verkeer van de tunnel wordt niet in een tweede betrouwbaar transport verpakt. TCP geeft je een pad door netwerken die UDP laten vallen of blokkeren, tegen de prijs van geneste herverzending die een verbinding met verlies erger kan laten voelen.

Dat is een ruil in bereikbaarheid, geen universele ranglijst. De juiste keuze is degene die het netwerk voor de client toestaat. Een pad dat UDP op de VPN-poort laat vallen, zal nooit onderhandelen, hoe goed het profiel ook is geschreven. Test het pad en kies dan het transport.

Alleen op basis van een meting tussen hen kiezen is een fout, want het antwoord hangt af van wat het netwerk voor je toestaat. Een hotel of een bedrijfsproxy staat misschien uitgaand TCP op 443 toe en niets anders, en daarom bieden providers die variant aan. Het blijft een OpenVPN-verbinding op die poort, geen HTTPS-sessie, ook al is het poortnummer het bekende.

Wat tcp-client werkelijk betekent

De richtlijn aan de clientkant benoemt het uiteinde dat een TCP-verbinding begint. De serverkant gebruikt zijn eigen luistervorm, en het kopiëren van het woord van de client naar een serverconfiguratie levert een luisteraar op die verwacht te worden gebeld, niet een die accepteert.

Overeenkomen betekent dat beide uiteinden het over het transport eens zijn, niet dat ze dezelfde tekenreeks delen.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Vraag de server waarop hij luistert voordat je aanneemt dat het profiel verkeerd is. Een UDP-luisteraar verschijnt niet in een TCP-socketlijst, en het omgekeerde geldt ook, dus bekijk de protocolspecifieke weergave in plaats van een algemene.

Wanneer het profiel importeert maar nooit verbindt

Een geïmporteerd profiel dat meteen in een time-out loopt, mislukt meestal vóór enige authenticatie. Het pakket gaat naar een poort zonder luisteraar, of het netwerk laat het stil vallen.

Test het pad op de eenvoudigste manier: verbind met dezelfde host en poort met het transport dat het profiel beweert, vanaf hetzelfde netwerk als de falende client.

Als een UDP-test niets krijgt en een TCP-test verbindt, biedt de server het andere transport aan en is het profiel simpelweg verouderd. Als geen van beide reageert, ligt het probleem boven de transportkeuze en geen enkele aanpassing van het profiel lost het op. Die twee gevallen onderscheiden kost een minuut en bespaart een uur certificaatdebugging die nooit relevant was.

Leg het werkende transport vast

Zodra een combinatie werkt, schrijf die op met de server, poort en protocol, en noteer vanaf welk netwerk hij is getest.

Anders zal de volgende persoon die een time-out tegenkomt hetzelfde experiment in de andere richting proberen, en mogelijk een server wijzigen die in orde was.

Als de provider beide varianten publiceert, houd dan beide bestanden en label ze naar het netwerk waarvoor ze geschikt zijn. Twee duidelijk benoemde profielen voorkomen het per ongeluk mengen van een clienttransport met een serverluisteraar die er nooit voor is geconfigureerd.