Warum ein OpenVPN-Profil zu Hause funktioniert, im Hotel aber scheitert

Büro-WLAN und ein Hotelzimmer können demselben Laptop zwei sehr unterschiedliche Netze geben, und das Profil dazwischen ahnt nichts davon. Was zu Hause funktioniert, setzt einen duldsamen Uplink, funktionierende Namensauflösung und ein lokales Subnetz voraus, das nicht mit etwas kollidiert, das der Tunnel transportiert. Jede dieser Annahmen kann unabhängig scheitern.

Der nützliche Weg zur Fehlersuche ist, das Netz als vier getrennte Fakten zu behandeln und sie dann der Reihe nach zu prüfen. Erst am Profil zu raten erzeugt meist eine Änderung, die nichts behebt und die Beweise verschleiert.

Vier Netzfakten ändern sich zwischen Standorten

Der erste Fakt ist, ob das lokale Netz überhaupt hinauslässt. Ein Captive Portal lässt ein Gerät auf eine Anmeldeseite und blockiert alles andere, bis diese Seite abgeschlossen ist, was bedeutet, dass der Tunnel nicht starten kann, so korrekt das Profil auch sein mag.

Der zweite ist die Namensauflösung. Ein Portal, das DNS abfängt, antwortet auf jede Anfrage mit seiner eigenen Adresse, sodass der VPN-Hostname zum Portal auflöst und der Client versucht, einen Tunnel zu einer Webseite aufzubauen.

Der dritte ist die Transportfilterung. Netze, die nur Surfen erlauben wollen, lassen TCP 443 zu beliebigen Zielen durch und verwerfen fast alles andere, einschließlich UDP.

Der vierte ist die Adressierung. Das lokale Subnetz kann sich mit einem Netz hinter dem Tunnel überschneiden, oder der Uplink bietet überhaupt keinen nutzbaren IPv4-Pfad.

Namensauflösung und das Captive Portal

Ersetzen Sie den Hostnamen im Profil durch die numerische Adresse des Servers und versuchen Sie es erneut. Wenn die IP verbindet und der Name nicht, ist die Namensauflösung schuld, und das Profil selbst ist in Ordnung.

Öffnen Sie einen Browser und versuchen Sie eine gewöhnliche HTTP-Seite, bevor Sie das VPN anfassen. Eine Weiterleitung auf eine Anmeldeseite bedeutet, dass das Portal noch aussteht; schließen Sie es ab und verbinden Sie sich dann erneut. Viele Hotels lassen die Sitzung außerdem nach einigen Stunden ablaufen, was wie eine Trennung am Mittag aussieht und nicht wie ein Anmeldeproblem.

Wenn auch die numerische Adresse scheitert, ist die Namensauflösung nicht die Erklärung, also gehen Sie zum Transport über. Behalten Sie die getestete Adresse, denn sie sagt der nächsten Prüfung, ob Pakete den Rechner überhaupt verlassen haben.

Transportfilterung: zuerst UDP, TCP 443 als Rückfall

Ein OpenVPN-Fluss über UDP 1194 sieht aus wie nichts, was eine Hotelfirewall erkennt, also wird er ohne Fehler verworfen. Der Client versucht es erneut, bis sein Timeout abläuft, und der Nutzer sieht eine Verbindung, die nie zustande kommt, statt einer Ablehnung. Firewalls, die sich so verhalten, protokollieren das Verwerfen selten an einer sichtbaren Stelle. Das Fehlen einer Ablehnung ist selbst der Hinweis.

TCP 443 ist der verlässliche Rückfall, weil das Netz ihn nicht von gewöhnlichem HTTPS unterscheiden kann. Verwenden Sie das TCP-Profil des Betreibers, wenn es eines gibt, denn auch der Server muss auf diesem Transport und Port lauschen; nur den Client zu ändern erzeugt eine andere Art von Fehler. Gibt es kein TCP-Profil, fragen Sie den Betreiber, statt eines durch Bearbeiten des Ports zu erfinden. Die Serverseite muss zustimmen, und eine Abweichung sieht wieder wie ein Firewallproblem aus.

Rechnen Sie mit Leistungskosten. TCP in TCP verstärkt Neuübertragungen auf einer verlustbehafteten Strecke, sodass ein funktionierender TCP-Tunnel in einem überlasteten Hotelnetz trotzdem langsam wirken kann. Das ist ein Tausch gegen Erreichbarkeit, kein Fehler, dem man nachjagt.

Adresskollisionen und Uplinks ohne IPv4

Ein Tunnel kann zustande kommen und trotzdem nichts übertragen. Wenn das lokale LAN und ein entferntes Netz ein Präfix wie 192.168.1.0/24 teilen, hält der Client den entfernten Host für direkt verbunden und schickt das Paket an die lokale Strecke statt in den Tunnel. Das Symptom ist eine erfolgreiche Verbindung mit einem unerreichbaren Subnetz, was leicht als Routenproblem auf Serverseite missdeutet wird.

Die dauerhafte Lösung ist, das entfernte LAN in einen ungewöhnlichen privaten Bereich zu verschieben. Einen Bereich zu wählen, den zu Hause niemand nutzt, etwa 10.42.0.0/24, verhindert das Problem für jeden künftigen Standort statt nur für einen. Die lokale Notlösung ist, jenes Hotel, Hotspot oder jenen Router zu meiden, was überhaupt keine Lösung ist.

Mobile Uplinks bringen zwei Varianten. Carrier-Grade-NAT bedeutet, dass eingehende Verbindungen nicht ankommen, was zählt, wenn Sie einen Server hosten, aber nicht für einen ausgehenden Client. Ein APN, der nur mit IPv6 und NAT64-Übersetzung konfiguriert ist, kann einen Client scheitern lassen, der auf einem echten IPv4-Pfad besteht, und das übliche Mittel ist, das APN-Protokoll auf IPv4 oder Dual Stack zu ändern.

Symptome, nachdem der Tunnel steht

Ein Tunnel, der sich verbindet und dann verstummt, ist meist ein Keepalive- oder MTU-Problem, kein blockierter Port. Eine Verbindung, die nach einer festen Zahl von Minuten abreißt, deutet auf einen Keepalive- oder Renegotiation-Timer. Stellen Sie den Client so ein, dass er seinen Peer sondiert und neu startet, wenn Antworten ausbleiben, und testen Sie eine kleinere Tunnel-MTU, wenn Pings durchgehen, große Übertragungen aber stocken.

Bevor Sie um Hilfe bitten, notieren Sie drei Dinge: die Adresse, die Sie versucht haben, und ob sie geantwortet hat, den Transport und Port, den Sie genutzt haben, und das lokale Subnetz des Netzes, das versagt hat. Zusammen trennen sie Namensauflösung, Transportfilterung und Adresskollision, und das sind die Ursachen, die den Kontakt mit Belegen überstehen.