Hilft TCP 443 wirklich? Nur wenn der Server dort lauscht

TCP 443 ist ein Rückfallweg mit einer Vorbedingung, keine Tarnung, die einen Tunnel an jedem Filter vorbeischleust. Er hilft, wenn der Anbieter bereits einen TCP-Listener auf diesem Port veröffentlicht und der Pfad eine Verbindung trägt, die stundenlang offen bleibt. Er scheitert, meist als Zeitüberschreitung, wenn eines von beidem fehlt, und die Zeitüberschreitung sagt selten, welches. Die Entscheidung für einen Wechsel verlangt drei Fragen, und nur eine davon betrifft die Portnummer.

Eine Portnummer ist kein Transportversprechen

Ein Port benennt einen Endpunkt; TCP macht daraus einen geordneten Bytestrom; OpenVPN entscheidet, was in diesem Strom reist. Ein Webserver auf derselben Nummer verwendet eine völlig andere Anwendungsanordnung, sodass der gemeinsame Port 443 die beiden für einen Filter ähnlich aussehen lässt und nicht mehr. Die Nummer ist ein Hinweis, den ein Filter liest, keine Eigenschaft, die ändert, was die Pakete enthalten. Die beiden für dasselbe zu halten, weil sie einen Port teilen, ist der Fehler hinter dem meisten Durcheinander hier.

Zwischengeräte treffen selten eine einfache Erlauben-oder-Verbieten-Entscheidung über einen Port. Viele prüfen die ersten Bytes, manche nageln ein Ziel fest, und manche setzen Verbindungen zurück, die zu lange offen bleiben. Deshalb kann dasselbe Profil aus einem Netz funktionieren und aus einem anderen in eine Zeitüberschreitung laufen, und deshalb lohnt es, einen Rückfallweg als unterstützte Option zu testen, statt ihm als Versprechen zu vertrauen. Wenn ein Filter den Verkehr untersucht, ist die Portnummer nur das Erste, worauf er schaut.

Bestätigen Sie den Listener, bevor Sie das Profil anfassen

Der Server muss für TCP auf dem Port konfiguriert sein, und das Client-Profil muss denselben Transport anfordern. Ein UDP-Profil umzuschreiben, damit es TCP anfordert, erzeugt keinen Listener, und die daraus folgende Zeitüberschreitung ist nicht von einer Firewall zu unterscheiden, die den Port verwirft. Laden Sie das eigene TCP-Profil des Anbieters herunter, wenn es eines gibt, weil manche Dienste einen separaten Endpunkt und separate Identitätseinstellungen für jeden Transport veröffentlichen. Handarbeit ist gut für einen kontrollierten Test und ein schlechter Weg, die beabsichtigte Konfiguration eines Anbieters zu erraten.

Die beiden Seiten dieser Übereinstimmung erscheinen in der Konfiguration, und die Link-Optionen des OpenVPN-Projekts dokumentieren beide Formen. Das minimale Paar sieht so aus:

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

Drei Bedingungen entscheiden, ob sich der Rückfallweg lohnt

Die erste Bedingung ist, dass der Anbieter den Transport überhaupt anbietet; ohne ihn spielt alles andere keine Rolle. Die zweite ist, dass der Pfad eine langlebige Sitzung am Leben hält, da manche Netze Verbindungen zurücksetzen, die offen bleiben, statt den Port rundweg zu blockieren. Die dritte ist, ob der Rückfallweg eine bewusste Ausnahme ist oder ein Notbehelf, der einen Fehler verdeckt, den Sie nicht behoben haben.

Jede Bedingung hat eine billige Prüfung. Ein Fehlschlag bei einer von ihnen sieht vom Client aus gleich aus:

Schließen Sie jede Anmeldung an einem Captive Portal ab, bevor Sie Transporte vergleichen. Ein Netz, das Ihr Gerät nicht zugelassen hat, blockiert beide Transporte, und der Vergleich misst dann das Portal statt den Tunnel. Melden Sie sich an, bestätigen Sie, dass gewöhnliches Surfen funktioniert, und starten Sie erst dann den Test.

Der Preis, den Sie akzeptieren: TCP in TCP

TCP überträgt verlorene Segmente erneut und bewahrt ihre Reihenfolge. Wenn eine Anwendung, die ebenfalls TCP nutzt, in einem TCP-Tunnel läuft, reagieren zwei Wiederherstellungsschichten auf denselben Verlust, und genau dieses Zusammenspiel lässt den Tunnel auf einem verlustbehafteten Pfad langsam wirken. Das Symptom ist Verzögerung und Jitter statt eines sauberen Fehlers, was es leicht macht, das ferne Ende zu beschuldigen. Messen Sie vom Client unter beiden Transporten, bevor Sie ein Fazit ziehen.

UDP vermeidet diese Verschachtelung, und das ist der Hauptgrund, warum Anbieter es bevorzugen und TCP nur als Alternative anbieten. Eine stabile TCP-Verbindung ist immer noch nützlicher als eine unerreichbare UDP-Verbindung, also geht der Vergleich zwischen zwei echten Kosten und nicht zwischen einer guten und einer schlechten Option. Halten Sie Gerät und Zugangsnetz stabil, während Sie vergleichen, sonst beschreibt das Ergebnis die falsche Variable.

Manche Client-Funktionen sind nur für einen Transport dokumentiert, sodass ein Rückfallprofil stillschweigend Verhalten verlieren kann, auf das Sie angewiesen waren. Lesen Sie die Transportanforderung der Option, bevor Sie das TCP-Profil als einfachen Tausch behandeln.

Fehler, die ein anderer Transport nicht berührt

Ein abgelaufenes Zertifikat braucht weiterhin eine Uhrprüfung oder eine Erneuerung, und ein abgelehntes Konto braucht weiterhin die richtigen Zugangsdaten. Behalten Sie die Serveridentitätsprüfungen bei, die der Anbieter geliefert hat, denn eine vertraute Portnummer authentifiziert niemanden. Ein Port, der antwortet, sagt nur, dass etwas lauscht.

Kommt der Tunnel hoch und scheitern Ziele weiterhin, liegt das verbleibende Problem im Routing oder in der Namensauflösung nach der Verbindung, nicht im Transport. Folgen Sie diesem Weg, statt Ports durchzuprobieren, denn so verschwindet ein Nachmittag. Das Profil sagt Ihnen, welchen Transport Sie versuchen sollen; es sagt Ihnen nie, warum der UDP-Pfad gescheitert ist.