UDP ist nicht immer schneller: den OpenVPN-Transport wählen

Jede Anleitung sagt, UDP sei für OpenVPN besser als TCP, und dieser Rat ist eine Voreinstellung, keine Messung. Der Transport ändert, wie Pakete zugestellt werden und was passiert, wenn der Pfad sie verwirft, nicht wie der Tunnel verschlüsselt wird. Hinter einem Captive Portal oder einem Proxy, der nur Port 443 zulässt, ist die langsamere Option diejenige, die überhaupt eine Verbindung herstellt. Das Folgende trennt, was das Protokoll tut, von dem, was Ihr Zugangsnetz zulässt.

Was der Transport tatsächlich ändert

TCP liefert einen zuverlässigen, geordneten Bytestrom und überträgt alles Verlorene erneut, wie RFC 9293 festlegt. UDP übergibt Datagramme an das Netz, und OpenVPN betreibt darüber seine eigene Zuverlässigkeitsschicht auf diesem Socket. Die Kapselung von TCP in TCP stapelt zwei Wiederherstellungsschleifen, sodass ein einziges verlorenes Segment den inneren Strom aufhalten kann, bis die äußere Neuübertragung eintrifft. Diese Wechselwirkung ist das eigentliche Argument für UDP, und sie zeigt sich als Latenz statt als Durchsatz.

Der Effekt wächst mit Verlust und Roundtrip-Zeit. Auf einem sauberen lokalen Pfad fühlen sich beide Transporte gleich an, weshalb ein Labortest die Beschwerde selten reproduziert. Auf einer überlasteten Mobilfunkstrecke zeigt sich der Unterschied in interaktiven Sitzungen lange, bevor ein großer Transfer etwas bemerkt.

Nichts davon berührt Vertraulichkeit oder Integrität. Der TLS-Handshake und die Datenkanal-Chiffre sind für beide Transporte gleich, ein Wechsel kann also eine schwache Chiffriersuite nicht retten.

Wo TCP seinen Platz verdient

Zugangsnetze sind der übliche Grund, TCP zu wählen. Ein Hotel, ein Flughafen oder ein Gästenetz erlaubt vielleicht ausgehend 443 und verwirft alles andere, und ein TCP-Listener auf diesem Port ist das einzige Profil, das funktioniert. Das ist Erreichbarkeit, nicht Leistung, und das ist für sich genommen ein guter Grund.

TCP hilft auch, wenn der Pfad stabil ist, aber die Middleboxes feindlich sind. Manche Netze setzen langlebige UDP-Flüsse zurück, während sie TCP-Sitzungen dulden, die gewöhnlichem Webverkehr ähneln. Ob diese Ähnlichkeit gelingt, ist eine Eigenschaft des jeweiligen Netzes, und keine Anleitung kann sie für alle versprechen. Testen Sie innerhalb des Netzes, das versagt, bevor Sie das Protokoll beschuldigen.

Eine abgelehnte Anmeldung ist kein Transportproblem. Die Zertifikatsprüfung abzuschalten, um eine Verbindung zu erzwingen, ist eine andere Änderung mit einem viel schlechteren Ergebnis.

Ein TCP-Profil bereitzuhalten ist der praktische Kompromiss. Die meisten Clients speichern beide und lassen Sie wechseln, wenn ein Netz den UDP-Pfad verweigert, was nichts kostet, bis Sie es brauchen. Was Sie nicht tun sollten, ist zwei Profile mit unterschiedlichen Endpunkten auszuliefern, denn dann misst Ihr Vergleich die Server.

Prüfen Sie, welchen Listener Sie tatsächlich haben

Bevor Sie die Leistung vergleichen, bestätigen Sie, dass beide Seiten sich über Transport und Port einig sind. proto udp in einer Client-Datei zu proto tcp zu ändern, erzeugt keinen Server-Listener. Der Server muss für dieses Protokoll konfiguriert sein, und das Profil muss dazu passen.

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

grep gibt aus, was dem Server gesagt wurde zu verwenden, während die beiden Socket-Listen zeigen, woran er gebunden ist. Ein UDP-Listener erscheint nur in der ersten Liste und ein TCP-Listener nur in der zweiten, eine fehlende Zeile ist also der schnellste Weg, ein Profil zu finden, das nie angewendet wurde. Vergleichen Sie auch den Port, denn ein TCP-Profil auf 1194 verhält sich in den meisten Zugangsnetzen anders als eines auf 443. Starten Sie den Dienst nach der Änderung neu und lesen Sie die Logzeile, die die Bindung meldet.

Die Bestätigung auf Clientseite ist billig: Starten Sie die Verbindung mit --verb 4 und lesen Sie die Transportzeile im Log. Wenn der Client UDP meldet, während der Server auf TCP lauscht, beginnt der Handshake nie, und keine Abstimmung hilft.

Vergleichen Sie die Arbeitslast, nicht das Transport-Label

Ein fairer Vergleich hält alles außer dem Transport konstant. Dasselbe Gerät, dasselbe Zugangsnetz, derselbe Zielhost, dieselbe Anwendung und idealerweise derselbe Server. Wenn die beiden Profile auf verschiedene Hosts zeigen, messen Sie auch diese Hosts.

Notieren Sie drei Ergebnisse pro Lauf: ob der Tunnel aufgebaut wird, ob er bestehen bleibt und ob die Aufgabe abgeschlossen wird. Kleine Anfragen, die funktionieren, während große Transfers stocken, deuten auf Paketgröße und MTU hin, nicht auf den Transport. Wiederholte Neuverbindungen deuten auf den Pfad oder auf einen Middlebox-Timeout hin.

Behalten Sie das Profil, das unter den Bedingungen funktioniert, die Sie tatsächlich antreffen, und speichern Sie das andere. Die Wahl gehört dem Netz, nicht der Person, weshalb jede einzelne Standardantwort irgendwo falsch ist.