VPN verbunden, aber kein Internet? Die vier Schichten abarbeiten

Der Client meldet verbunden, der Browser dreht, und jede Seite endet im Timeout. Diese Kombination ist häufig und kein Widerspruch: Verbunden heißt, der Tunnel hat ausgehandelt, mehr nicht. Namensauflösung, Routing und der eigene Ausgang des Servers scheitern jeweils auf ihre Weise, und jede hat einen anderen Verantwortlichen. Arbeiten Sie die Schichten der Reihe nach ab und halten Sie bei der ersten an, die scheitert.

Beginnen Sie mit dem Netz, aus dem Sie kamen

Trennen Sie den Tunnel mit der eigenen Trennfunktion des Clients, und versuchen Sie dann zwei unabhängige HTTPS-Seiten, wenn die Richtlinie es erlaubt. Lassen Sie sensible Arbeit für die Dauer dieses Tests geschlossen. Scheitert auch der normale Zugang, ist das VPN nicht der erste Verdächtige.

Sehen Sie sich die WLAN-Verbindung, den Router und jede Portalseite an, die eine Anmeldung verlangt, bevor Sie den Tunnel anfassen. Ein Kill Switch kann den Verkehr im getrennten Zustand planmäßig blockieren, folgen Sie also seinem dokumentierten Testverfahren, statt zu schließen, das Netz sei tot. Ein anderes vertrauenswürdiges Netz ist ein nützlicher Vergleich, und ein neuer VPN-Ausgang wird eine abgelaufene Hotel-Anmeldung nicht abschließen. Funktioniert das offene Netz und der Tunnel nicht, ist das Netz entlastet, und die nächste Schicht gehört Ihnen.

Entscheiden Sie, ob der Fehler die Namensauflösung ist

Notieren Sie den Fehlertext, denn Auflösungsfehler, Timeout und Zertifikatswarnung zeigen jeweils woanders hin. Das früh zu erkennende Muster ist ein Hostname, den Sie nie besucht haben, der scheitert, während eine Anwendung mit offener Sitzung weiterläuft. Dieses Muster betrifft neue Abfragen, nicht ob der Tunnel Pakete trägt. Eine einzelne Abfrage zeigt, was der Resolver zurückgibt, und dauert eine Sekunde. Probieren Sie auch einen zweiten Namen, damit eine zwischengespeicherte Antwort oder ein kaputter Eintrag die Diagnose nicht entscheidet.

nslookup example.com

Eine beliebige IP in der HTTPS-Adressleiste ist kein DNS-Test, weil Zertifikat und virtueller Host meist vom Namen abhängen. Interne Namen können den Resolver der Organisation statt eines öffentlichen Ersatzes brauchen, und ein Browser mit eigenem sicheren Resolver kann anders antworten als die Abfrage des Betriebssystems. Wo beide uneinig sind, ist der Resolver des Browsers der, den der Nutzer erlebt, und dieser Unterschied gehört ins Ticket.

Volltunnel oder nur Firmen-Subnetze

Manche Profile existieren nur, um eine Handvoll Firmen-Subnetze zu erreichen; andere sind gebaut, um alles zu tragen, und brauchen einen funktionierenden Ausgang dahinter. Lesen Sie den dokumentierten Zweck, bevor Sie annehmen, die Anzeige decke jede Anwendung und jede Adressfamilie ab. Ein Privatnetz-Profil kann genau wie entworfen funktionieren, während der Browser, der es nie nutzen sollte, weiter scheitert. Lesen Sie die Routentabelle, ohne sie zu ändern, und schließen Sie IPv6 ein, denn ein funktionierender IPv4-Pfad sagt nichts über die andere Familie.

Eine spezifischere Route kann gewinnen, während die Standardroute noch existiert, deshalb muss die Tabelle gelesen und nicht angenommen werden. Konkurrierende virtuelle Adapter können ebenfalls Verkehr besitzen, den Sie anderswo erwartet haben, besonders nachdem ein zweiter VPN-Client installiert und vergessen wurde. Löschen Sie die Standardroute nicht als Experiment; das macht aus einer Diagnose einen zweiten Ausfall.

Eine einzelne scheiternde Seite unter funktionierenden ist ein Problem dieser Seite, und sie beweist auch, dass der Tunnel Verkehr trägt. Stockungen, die nur bei großen Übertragungen auftreten, deuten auf Paketgröße statt auf Erreichbarkeit.

Wenn der Server nie etwas weiterleitet

Wenn jedes Ziel auf zwei Geräten und zwei Zugangsnetzen scheitert, steht der Tunnel, und der Ausgang leitet nicht weiter. Diese Paarung trennt einen serverseitigen Fehler von einem Gerät, das an einer Stelle falsch konfiguriert ist. Schicken Sie dem Betreiber die Fragen zu Weiterleitung, NAT und Rückweg, nicht einen Screenshot der Anzeige.

Diese drei decken die meisten serverseitigen Ursachen ab, und der Betreiber muss sie beantworten. Die OpenVPN-Seite zur Fehlersuche bei der Konnektivität geht dieselben Fragen von der Serverseite durch, geben Sie sie mit dem Ticket weiter. Ein Screenshot einer grünen Anzeige beantwortet keine davon.

Durchsuchen Sie das Client-Log nach der Anmeldung nach Fehlern beim Anwenden von Routen, DNS-Einstellungen oder des virtuellen Adapters. Fehler in dieser Phase deuten auf das Gerät statt auf den Server. Ein Fehler, der nie im Log erscheint, ist ebenso aussagekräftig, weil er den Verdacht auf die andere Seite verschiebt.

Prüfen Sie jeweils eine Schicht

Sobald Sie etwas ändern, verbinden Sie neu und wiederholen Sie genau die Anwendung, die scheiterte. Eine einzelne Seite, die lädt, beweist weniger als ein wiederholbarer Pfad zu den Ressourcen, für die das Profil gebaut wurde. Zwei Befehle trennen Auflösung von Erreichbarkeit, und der zweite ist hostspezifisch. Führen Sie die curl-Zeile überall aus, dann den Routenbefehl, der zum Host vor Ihnen passt.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Funktioniert die numerische Anfrage und der Name nicht, bleiben Sie bei DNS. Funktioniert keines von beiden, vergleichen Sie die Routentabelle mit dem erwarteten Standard des Tunnels und prüfen Sie die Familie, die Sie tatsächlich testen. Ist die Route richtig und stirbt die Anfrage trotzdem am Ausgang, gehört die restliche Frage dem Betreiber, und die Belege, die Sie behalten haben, sind das Ticket.