OpenVPN verbindet im Hotel-WLAN nicht? TCP 443 testen

Öffnen Sie den Client, drücken Sie Connect und lesen Sie die Statuszeile statt des Dialogs, der danach erscheint. Ein Profil, das nach einem Hotel-, Campus- oder Mobilfunknetz bei Connecting oder Waiting for server hängen bleibt, hat meist irgendwo auf dem Weg seinen Transport verloren, nicht seine Zugangsdaten. Der sinnvolle nächste Schritt ist herauszufinden, was dieses Netz überhaupt trägt, bevor Sie den Server anfassen. Ändern Sie nichts, bis dasselbe Profil anderswo funktioniert hat.

Testen Sie zuerst über einen Handy-Hotspot. Kommt der Tunnel dort zustande, sind Server, Zertifikat und Konto in Ordnung, und die einzige verbleibende Variable ist das Netz vor Ihnen.

Am Client anfangen: die Statuszeile lesen

Die Statuszeile sagt, an welcher Stufe es gescheitert ist. Ein Client, der bei Connecting hängt, löst noch den Hostnamen auf oder öffnet den äußeren Socket; einer, der Waiting for server erreicht, hat einen Pfad, aber keine Antwort; einer, der sich authentifiziert und dann abbricht, hat ein ganz anderes Problem. Das Client-Log und die eigenen Felder remote und proto des Profils zeigen, was der Client zu tun versucht, und --verb 4 gibt bei einem Kommandozeilen-Client dieselben Details aus. Der Vergleich mit dem Netz vor Ihnen macht aus »VPN ist blockiert« eine konkrete Aussage.

Prüfen Sie dann das Netz mit Werkzeugen, die Sie schon haben. nc -vzu 203.0.113.10 1194 sendet ein UDP-Datagramm, curl -v telnet://203.0.113.10:443 meldet, ob ein TCP-Handshake zustande kommt, und ein Browser, der eine HTTPS-Seite lädt, beweist nur, dass ausgehendes 443 diesen einen Host erreicht. Kleine Tests beantworten, was der VPN-Client nicht kann: welcher Port und welches Protokoll dieses Netz überhaupt verlassen.

Drei Netzverhalten sehen vom Client aus gleich aus und verlangen unterschiedliche Antworten. Ausgehendes 443 kann offen sein, es kann nur ein Proxy erlaubt sein, oder 443 wird transparent an eine Inspektionsbox weitergereicht, die nicht lesen kann, was es trägt. Das erste behebt die Profiländerung unten, das zweite die Proxy-Einstellungen, und das dritte kann einen Handshake abschließen und dann hängen bleiben, wenn der Inspector entscheidet, dass ihm der Strom nicht gefällt. Zu wissen, welches davon vorliegt, ist der Unterschied zwischen einer Änderung von zehn Minuten und einem Nachmittag voller Neuinstallationen.

Listener und Profil gemeinsam umstellen

Serverseitig stellen Sie den Listener auf das, was das Netz zulässt: port 443 und proto tcp in der Serverkonfiguration, starten Sie dann den Dienst neu und prüfen Sie den Socket mit ss -lntp. Clientseitig muss das Profil zustimmen, denn Transport und Port liegen außerhalb des Tunnels: proto tcp und port 443 in der .ovpn oder die passenden Felder im Einstellungsbildschirm der App. Ein Profil, das weiterhin auf UDP 1194 zielt, scheitert genau wie zuvor, und die Versuchung ist, eine Firewall zu beschuldigen, die längst repariert ist. Antwortet derselbe Host auch per HTTPS auf 443, können sich die beiden Listener diese Adresse und dieses Protokoll nicht teilen; geben Sie dem VPN eine zweite Adresse oder setzen Sie einen Demultiplexer davor.

Verfolgen Sie die erste Verbindung mit tcpdump -ni any port 443 an beiden Enden. Pakete, die den Client verlassen und nie ankommen, bedeuten, dass das Netz doch filtert, oder dass die Adresse im Profil nicht die angenommene ist. Pakete, die ohne Antwort ankommen, schicken Sie zurück ins Server-Log, wo sich eine Protokollabweichung sofort als verworfenes Paket zeigt.

Wenn nur ein Proxy aus dem Netz herausführt

Manche Gästenetze erlauben nichts außer einem HTTP-Proxy, was eine andere Einschränkung als ein geschlossener Port ist und mehr als OpenVPN ausschließt. Clients, die nur PPTP, L2TP/IPsec oder reines IPsec sprechen, kommen dort nicht durch, weil diese Entwürfe erwarten, dass ihr äußeres Protokoll den Server direkt erreicht. OpenVPN kann es, mit http-proxy proxy.example.net 8080 im Client-Profil, sofern der Proxy die CONNECT-Methode zu Ihrem Port erlaubt. Ein SOCKS-Proxy ist noch einfacher, weil er den Strom weiterreicht, ohne sich um dessen Inhalt zu kümmern.

Wo der Client keine Proxy-Unterstützung hat, bleibt meist ein SSH-Tunnel über 443. Er fügt eine zweite Schicht hinzu, und der Betreiber des Netzes hat dazu möglicherweise eine Meinung, also behandeln Sie ihn als Brücke für eine Reise und nicht als Architektur.

Den Preis des Rückfalls kennen, bevor Sie ihn behalten

TCP in TCP hat einen bekannten Preis. Wenn die äußere Verbindung TCP ist und die Nutzlast ebenfalls, löst ein verlorenes Segment auf beiden Schichten eine Neuübertragung aus, und die innere Verbindung weicht einem Verlust aus, den sie nicht sieht. Surfen übersteht das; interaktive Sitzungen und Anrufe spüren es. Behalten Sie den TCP-443-Listener als Rückfall für Netze, die ihn verlangen, und lassen Sie UDP die Voreinstellung für alles, was es noch durchlässt.

Halten Sie die Wahl im Profilnamen und in den Support-Notizen fest: welcher Port, welches Protokoll und welches Netz sie erzwungen hat. Fragen Sie dann den Administrator des Netzes, ob dieser Port nach der nächsten Geräteerneuerung offen bleibt, denn ein Rückfall, der still verschwindet, ist schlimmer als gar keiner.