VPN-Verbindungs-Timeout: DNS, Transport, Aushandlung oder Anmeldung

„Connection timed out“ ist die ungenaueste Fehlermeldung, die ein VPN-Client ausgeben kann. Sie bedeutet, dass eine Operation ihre Frist verpasst hat, und jeder Schritt von der Namensauflösung bis zur Login-Antwort hat eine Frist. Clients, die nur die letzte Meldung zeigen, lassen die Schritte identisch aussehen, also erhöhen Leute das Timeout, ändern den Port und installieren das Profil neu, in dieser Reihenfolge, ohne etwas zu lernen. Die Schritte zu vergleichen ist schneller: jeder scheitert an einer anderen Stelle, und jedes Scheitern hinterlässt eine andere Art von Beweis.

Vier Schritte, vier verschiedene Fehler

Die Reihenfolge ist fest, auch wenn der Client sie verbirgt: Der Name muss aufgelöst werden, zur resultierenden Adresse muss ein Transport aufgebaut werden, das Protokoll muss seine Parameter und Schlüssel aushandeln, und das Konto muss authentifiziert werden. OpenVPNs Leitfaden zur Fehlerbehebung bei Verbindungen folgt für seinen eigenen Client derselben Reihenfolge, und die anderen folgen ihr dicht. Ein Timeout in Schritt zwei und ein Timeout in Schritt vier haben nichts gemeinsam außer dem Wort auf dem Bildschirm.

Lesen Sie im Protokoll die letzte Zeile, die Fortschritt anzeigt, nicht die letzte Zeile vor dem Fehler. Die meisten Clients geben so etwas wie eine aufgelöste Adresse, einen aufgebauten Socket, einen begonnenen Handshake oder eine Authentifizierungsanfrage aus, und der Schritt nach dieser Zeile ist der, der das Timeout hatte.

Die Namensauflösung scheitert, bevor irgendetwas kontaktiert wird

Löst sich der Endpunkt nie auf, hat der Client nichts, womit er sich verbinden könnte, und es ist keine Transportarbeit passiert. Dieser Fehler ist meist sofort da statt ein volles Timeout, was der billigste Weg ist, ihn vom Rest zu unterscheiden. Testen Sie den Namen mit dem System-Resolver und einem zweiten Resolver, und vergleichen Sie die beiden Antworten, bevor Sie schließen, dass der Server ausgefallen ist.

Eine alte Adresse aus einem Forenbeitrag ist eine häufige Ursache für ein Timeout, das wie ein Serverproblem aussieht, weil die Adresse jetzt zu etwas anderem oder zu nichts gehört. Verwenden Sie das aktuelle Profil des Betreibers, statt eine Adresse zu ersetzen, die früher funktioniert hat. Eine fehlende Ping-Antwort ist kein Beweis in irgendeine Richtung: Viele Endpunkte verwerfen ICMP und dienen trotzdem einwandfrei.

Der Transportaufbau wartet auf ein Paket, das nicht kommt

Wenn DNS in Ordnung ist und der Client trotzdem das ganze Timeout verbraucht, ist die Transportschicht verdächtig. Bei TCP können Sie den Port direkt testen; Test-NetConnection unter Windows oder nc -vz unter Linux sagt Ihnen, ob etwas die Verbindung annimmt, und das ist nützlicher als ein Ping. Bei UDP geht das nicht auf dieselbe Weise, weil auf dieser Schicht kein Handshake abzuschließen ist, und diese Asymmetrie führt zu vielen falschen Schlüssen.

Was ein TCP-Test belegt, ist begrenzt: Ein Dienst, der Port 443 annimmt, ist nicht unbedingt der VPN-Listener, und ein reiner UDP-Endpunkt hat keinen TCP-Port, der etwas annehmen könnte. Ein Profil von UDP auf TCP umzuschreiben erzeugt keinen Listener auf der anderen Seite; es ändert nur, worauf Ihr Client wartet. Filtert das Netzwerk das Protokoll, erzeugt die Änderung ein anderes Timeout im selben Schritt.

Captive Portals verdienen in diesem Schritt eine eigene Prüfung. Bis das Portal das Gerät autorisiert, geht ausgehender Verkehr zum Portal, und der Tunnelversuch hängt einfach. Schließen Sie das Portal zuerst im Browser ab, versuchen Sie es dann erneut, und ändern Sie das Profil nicht, solange das Portal noch aussteht.

Aushandlung und Login bedeuten, dass der Server geantwortet hat

Sobald der Tunnel den Server erreicht, beginnt der Client einen Handshake, und der Fehler ändert seinen Charakter. Ein Stocken hier betrifft die Kompatibilität, nicht die Erreichbarkeit: unpassende Protokollversionen, eine Cipher- oder Datenkanal-Einstellung, die die Gegenseite nicht akzeptiert, oder ein Profil, das eine Funktion erwartet, die der Server nicht anbietet. OpenVPN hat seine Aushandlungs-Standardwerte zwischen Hauptversionen oft genug verschoben, dass ein für eine Generation geschriebenes Profil den Server erreichen und trotzdem nicht hochkommen kann.

Die Authentifizierung ist der letzte Schritt und der am leichtesten falsch zu lesende. Eine ausdrückliche Ablehnung ist eine Antwort, was bedeutet, dass der Weg funktioniert und das Problem die Identität, das Zertifikat oder der Kontozustand ist. Ein browserbasierter Single-Sign-on-Ablauf ist ein dritter Fall: Der Client wartet auf eine Handlung, die Sie nicht vorgenommen haben, oder auf einen Browser, den er nicht starten kann, und es kommt nichts an, bis Sie diesen Schritt abschließen.

Vergleichen Sie die Beweise, bevor Sie den Wiederholungsversuch ändern

Halten Sie Gerät und Profil fest und ändern Sie jeweils eine Sache, beginnend mit dem Netzwerk. Wenn dasselbe Profil über einen Handy-Hotspot verbindet und im Hotel-Wi-Fi ein Timeout bekommt, ist der Weg die Variable, nicht der Server. Scheitert es überall, ist das Profil oder der Endpunkt die Variable. Scheitert es nur zu einer bestimmten Tageszeit, erfassen Sie den Zeitstempel und vergleichen Sie ihn mit Ereignissen auf Serverseite, bevor Sie etwas über Last annehmen.

Bei einem Dienst, den Sie betreiben, ist der entscheidende Vergleich, ob der Versuch überhaupt ankommt. Eine Verbindung, die den Listener erreicht und dann stockt, gehört zum Aushandlungsschritt; eine, die nie in dessen Sicht auftaucht, ist ein Transport- oder Auflösungsproblem, und keine Abstimmung der Wiederholungen bewegt sie. Serverprotokolle trennen außerdem einen abgelehnten Login von einem stillen Verwerfen, was der Unterschied zwischen einer Identitätskorrektur und einer Firewall-Korrektur ist.

Notieren Sie die Client-Version, den Profilnamen, die Versuchszeit mit ihrer Zeitzone und den ersten brauchbaren Fehler statt der letzten getrennten Zeile. Entfernen Sie Schlüssel und credentialhaltiges Material, bevor Sie den Auszug teilen. Nehmen Sie dann eine sinnvolle Korrektur vor und versuchen Sie es erneut, denn eine längere Frist hilft nur der dokumentierten langsamen Operation und bewirkt nichts bei falscher Adresse oder blockiertem Port.