UDP is niet altijd sneller: de OpenVPN-transport kiezen

Elke handleiding zegt dat UDP beter is dan TCP voor OpenVPN, en dat advies is een standaardinstelling, geen meting. Het transport verandert hoe pakketten worden afgeleverd en wat er gebeurt als het pad ze laat vallen, niet hoe de tunnel wordt versleuteld. Achter een captive portal of een proxy die alleen poort 443 toestaat, is de langzamere optie degene die überhaupt verbindt. Het volgende scheidt wat het protocol doet van wat je toegangsnetwerk toestaat.

Wat het transport werkelijk verandert

TCP levert een betrouwbare, geordende bytestroom en verzendt alles opnieuw wat verloren gaat, zoals RFC 9293 voorschrijft. UDP geeft datagrammen aan het netwerk, en OpenVPN draait zijn eigen betrouwbaarheidslaag over die socket. TCP in TCP inkapselen stapelt twee herstellussen, zodat één verloren segment de binnenste stroom kan ophouden tot de buitenste hertransmissie aankomt. Die wisselwerking is het echte argument voor UDP, en ze uit zich als latentie in plaats van als doorvoer.

Het effect groeit met verlies en rondetijd. Op een schoon lokaal pad voelen beide transporten identiek, waardoor een labtest de klacht zelden reproduceert. Op een overbelaste mobiele verbinding is het verschil in interactieve sessies zichtbaar lang voordat een grote overdracht iets merkt.

Niets hiervan raakt vertrouwelijkheid of integriteit. De TLS-handshake en het cijfer van het datakanaal zijn voor beide transporten hetzelfde, dus wisselen kan een zwakke cijfersuite niet redden.

Waar TCP zijn plek verdient

Toegangsnetwerken zijn de gebruikelijke reden om TCP te kiezen. Een hotel, een luchthaven of een gastnetwerk staat misschien uitgaand 443 toe en gooit al het andere weg, en een TCP-listener op die poort is het enige profiel dat werkt. Dat is bereikbaarheid, niet prestatie, en het is op zichzelf een goede reden.

TCP helpt ook wanneer het pad stabiel is maar de middleboxes vijandig zijn. Sommige netwerken resetten langdurige UDP-stromen terwijl ze TCP-sessies dulden die op gewoon webverkeer lijken. Of die gelijkenis lukt, is een eigenschap van het concrete netwerk, en geen enkele handleiding kan het voor alle beloven. Test binnen het netwerk dat faalt voordat je het protocol de schuld geeft.

Een geweigerde login is geen transportprobleem. Certificaatverificatie uitschakelen om een verbinding door te dwingen is een andere wijziging met een veel slechtere uitkomst.

Een TCP-profiel klaarhouden is het praktische compromis. De meeste clients bewaren beide en laten je wisselen wanneer een netwerk het UDP-pad weigert, wat niets kost tot je het nodig hebt. Wat je niet moet doen, is twee profielen leveren die naar verschillende eindpunten wijzen, want dan meet je vergelijking de servers.

Controleer welke listener je werkelijk hebt

Voordat je prestaties vergelijkt, bevestig je dat beide kanten het eens zijn over het transport en de poort. proto udp wijzigen in proto tcp in een clientbestand maakt geen server-listener. De server moet voor dat protocol zijn geconfigureerd, en het profiel moet daarbij passen.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep drukt af wat de server is opgedragen te gebruiken, terwijl de twee socketlijsten laten zien waaraan hij gebonden is. Een UDP-listener verschijnt alleen in de eerste lijst en een TCP-listener alleen in de tweede, dus een ontbrekende regel is de snelste manier om een profiel te vinden dat nooit is toegepast. Vergelijk ook de poort, want een TCP-profiel op 1194 gedraagt zich in de meeste toegangsnetwerken anders dan een op 443. Herstart de dienst na de wijziging en lees de logregel die de binding meldt.

Bevestiging aan de clientkant is goedkoop: start de verbinding met --verb 4 en lees de transportregel in de log. Als de client UDP zegt terwijl de server op TCP luistert, begint de handshake nooit en geen enkele afstelling helpt.

Vergelijk de werklast, niet het transportlabel

Een eerlijke vergelijking houdt alles constant behalve het transport. Hetzelfde apparaat, hetzelfde toegangsnetwerk, dezelfde bestemmingshost, dezelfde toepassing en idealiter dezelfde server. Als de twee profielen naar verschillende hosts wijzen, meet je die hosts ook.

Noteer drie uitkomsten per run: of de tunnel tot stand komt, of hij blijft staan en of de taak voltooit. Kleine verzoeken die werken terwijl grote overdrachten vastlopen, wijzen op pakketgrootte en MTU, niet op het transport. Herhaalde herverbindingen wijzen op het pad of op een time-out van een middlebox.

Houd het profiel dat werkt onder de omstandigheden die je werkelijk tegenkomt, en bewaar het andere. De keuze is aan het netwerk, niet aan de persoon, en daarom is elk enkel standaardantwoord ergens verkeerd.