proto udp oder tcp-client: Welche Variante hört Ihr Server?

Ein Profil, das letzten Monat noch funktionierte, läuft jetzt in eine Zeitüberschreitung, und jemand schlägt vor, proto udp durch proto tcp-client zu ersetzen. Manchmal ist das der richtige Schritt, manchmal entsteht dabei ein Client, der sich mit einem Port verbindet, an dem nichts lauscht, weil der Server nie für den anderen Transport konfiguriert wurde. Die Direktive beschreibt, wie Ihre Seite spricht; sie kann auf der Gegenseite keinen Listener erzeugen. Lesen Sie Profil und Server gemeinsam, bevor Sie eines von beiden ändern.

Lesen Sie den Transport, den die ausgewählte Verbindung nutzt

Ein Profil kann mehrere remote-Einträge enthalten, und jeder kann seinen eigenen Transport nennen. Der Client arbeitet sie der Reihe nach ab, daher ist die Zeile, die Sie zuerst sehen, nicht unbedingt die, die gilt.

Suchen Sie den Eintrag, der tatsächlich versucht wird, und lesen Sie dann seinen Transport. Die Reihenfolge ist wichtig, denn der Client springt nicht stillschweigend weiter. Manche Builds versuchen den nächsten Eintrag erst nach einer Zeitüberschreitung, sodass eine funktionierende Alternative am Ende der Datei Sekunden später erreicht wird als erwartet. Beobachten Sie im Protokoll, welcher Endpunkt versucht wird, statt anzunehmen, die erste Zeile habe gewonnen.

Enthält die Datei eine proto-Zeile nahe dem Anfang und darunter mehrere Remote-Einträge, ist diese Zeile der Standard für jeden Remote, der ihn nicht überschreibt. Eine lokale Änderung am Standard bewirkt nichts für einen Remote-Eintrag, der seinen eigenen Transport nennt.

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

UDP und TCP sind keine Geschwindigkeitseinstellung

UDP versendet Datagramme, ohne einen geordneten Strom aufzubauen, daher wird der eigene Verkehr des Tunnels nicht in einen zweiten zuverlässigen Transport verpackt. TCP gibt Ihnen einen Weg durch Netze, die UDP verwerfen oder blockieren, zum Preis verschachtelter Neuübertragung, die eine verlustbehaftete Strecke schlechter wirken lassen kann.

Das ist ein Tausch bei der Erreichbarkeit, keine allgemeine Rangliste. Die richtige Wahl ist die, die das Netz vor dem Client zulässt. Ein Weg, der UDP am VPN-Port verwirft, wird sich niemals aushandeln, so gut das Profil auch geschrieben ist. Testen Sie den Weg und wählen Sie dann den Transport.

Die Wahl allein anhand eines Benchmarks zu treffen ist ein Fehler, denn die Antwort hängt davon ab, was das Netz vor Ihnen zulässt. Ein Hotel oder ein Unternehmensproxy erlaubt womöglich ausgehendes TCP auf 443 und sonst nichts, weshalb Anbieter diese Variante anbieten. Es bleibt eine OpenVPN-Verbindung auf diesem Port, keine HTTPS-Sitzung, auch wenn die Portnummer die vertraute ist.

Was tcp-client tatsächlich bedeutet

Die clientseitige Direktive benennt das initiierende Ende einer TCP-Verbindung. Die Serverseite verwendet ihre eigene lauschende Form, und das Kopieren des Client-Worts in eine Serverkonfiguration erzeugt einen Listener, der erwartet, angerufen zu werden, statt einen, der annimmt.

Übereinstimmung heißt, dass beide Enden sich auf den Transport einigen, nicht dass sie dieselbe Zeichenkette teilen.

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

Fragen Sie den Server, worauf er lauscht, bevor Sie annehmen, das Profil sei falsch. Ein UDP-Listener erscheint nicht in einer TCP-Socket-Auflistung, und umgekehrt gilt dasselbe, prüfen Sie daher die protokollspezifische Ansicht statt einer allgemeinen.

Wenn das Profil importiert wird, aber nie verbindet

Ein importiertes Profil, das sofort in eine Zeitüberschreitung läuft, scheitert meist vor jeder Authentifizierung. Das Paket geht an einen Port ohne Listener, oder das Netz verwirft es stillschweigend.

Testen Sie den Weg auf die einfachste mögliche Weise: Verbinden Sie sich vom selben Netz wie der fehlschlagende Client mit demselben Host und Port und dem Transport, den das Profil behauptet.

Wenn eine UDP-Prüfung nichts erhält und eine TCP-Prüfung verbindet, bietet der Server den anderen Transport an, und das Profil ist schlicht veraltet. Wenn keines von beiden antwortet, liegt das Problem oberhalb der Transportwahl, und keine Änderung am Profil wird es beheben. Diese beiden Fälle zu unterscheiden dauert eine Minute und spart eine Stunde Zertifikatsfehlersuche, die nie relevant war.

Halten Sie den funktionierenden Transport fest

Sobald eine Kombination funktioniert, notieren Sie sie mit Server, Port und Protokoll und vermerken Sie, von welchem Netz aus sie getestet wurde.

Sonst wird die nächste Person, die auf eine Zeitüberschreitung stößt, dasselbe Experiment in die andere Richtung versuchen und möglicherweise einen Server ändern, der in Ordnung war.

Wenn der Anbieter beide Varianten veröffentlicht, behalten Sie beide Dateien und kennzeichnen Sie sie nach dem Netz, für das sie passen. Zwei klar benannte Profile verhindern die versehentliche Vermischung eines Client-Transports mit einem Server-Listener, der nie dafür konfiguriert wurde.