Die öffentliche VPN-Liste sagt online; Ihr Client sagt nein

Sie öffnen das Verzeichnis, sortieren nach Geschwindigkeit, wählen einen als online markierten Knoten, und der Client gibt auf, bevor er das Verbinden abschließt. Die Liste log nicht, genau genommen. Sie meldete das Ergebnis der Prüfung einer anderen Person, aus einem anderen Netz, zu einem früheren Zeitpunkt, gegen einen Dienst, den ein Freiwilliger jederzeit abschalten kann. Diesen Unterschied zu verstehen macht aus einer frustrierenden Suche eine kurze Folge von Prüfungen, die Sie an jedem Kandidaten ausführen können.

Was die Liste tatsächlich gemessen hat

Ein öffentliches Verzeichnis führt Felder wie einen Zeitpunkt der letzten Prüfung, einen beobachteten Umlaufzeitwert, eine Sitzungszahl und manchmal eine Protokollliste. Jedes davon beschreibt die letzte erfolgreiche Beobachtung aus Sicht des Projekts selbst, nicht den Zustand des Knotens, wenn Ihr Paket ankommt.

Die Frische zählt mehr als die Zahl. Ein Knoten, der vor vier Minuten geprüft wurde, und ein Knoten, der vor vier Stunden geprüft wurde, können dieselbe grüne Markierung zeigen, und nur einer davon ähnelt noch dem aufgezeichneten Zustand. Suchen Sie den Zeitstempel, nicht die Farbe.

Freiwilliger Betrieb fügt eine zweite Änderungsquelle hinzu, die kein Monitor beheben kann. Der Betreiber startet vielleicht einen Laptop neu, geht ihm die Bandbreite aus, er wechselt den Anbieter oder klappt einfach den Deckel zu. Ein Listeneintrag ist ein Kandidat, und ihn als Service-Level-Vereinbarung zu behandeln ist ein Kategorienfehler.

Achten Sie auf die Phasen des Clients, nicht auf den Spinner

Jeder VPN-Client durchläuft dieselbe grobe Reihenfolge: den Namen auflösen, eine Transportverbindung öffnen, Sicherheit aushandeln, authentifizieren, dann den Tunnel konfigurieren und Daten übertragen. Ein Fehler in jeder Phase hinterlässt andere Spuren, und der Spinner zeigt keine davon.

Beginnen Sie mit der Namensauflösung. Wenn der Hostname nicht aufgelöst wird, wurde nichts über die Erreichbarkeit des Knotens geprüft, weil die Verbindung Ihre Maschine nie verlassen hat. Als Nächstes der Transport: ein abgelehnter oder abgelaufener TCP- oder UDP-Austausch sagt Ihnen, dass der Endpunkt an diesem Port nicht antwortet, was ein echter Befund über den Knoten ist. Dann Aushandlung und Authentifizierung, wo ein falsches Zertifikat, ein abgelaufenes Profil oder eine unpassende Chiffre scheitern, während der Knoten völlig gesund ist. Erst nachdem der Tunnel konfiguriert ist, kann ein Routing- oder DNS-Fehler den letzten Schritt erklären.

Lesen Sie das Client-Log mit der höchsten Ausführlichkeit, die noch auf den Bildschirm passt, und notieren Sie die letzte Zeile, die erfolgreich war. Diese Zeile ist der Punkt, an dem die Diagnose beginnt, und sie ist meist aufschlussreicher als alles, was das Verzeichnis anzeigt.

Eine Variable pro Versuch

Vergleichen Sie Kandidaten mit demselben Client, demselben Zugangsnetz und demselben Profilformat und ändern Sie nur den Endpunkt. Sonst könnte ein Fehler Ihrer sein, und Sie werden ihn dem Knoten zuschreiben.

Zwei Versuche reichen aus, um ein Muster zu erkennen, und ein dritter bestätigt es. Wenn Knoten A in der Transportphase scheitert und Knoten B bei der Authentifizierung, haben Sie zwei unabhängige Probleme statt einer veralteten Liste.

Wenn jeder Knoten auf dieselbe Weise scheitert

Ein allgemeiner Fehler in der ersten Phase deutet auf Ihre Seite: ein Resolver, der nicht antworten kann, eine lokale Firewall, die das Protokoll blockiert, oder ein Netz, das nur Webverkehr zulässt. Das Verzeichnis kann das nicht melden, weil seine Prüfungen nicht von Ihrem Platz aus laufen.

Prüfen Sie den Fall des geformten Netzes bewusst. Manche Zugangsnetze erlauben HTTPS ins Web und verwerfen andere Protokolle, wodurch jeder Kandidat tot aussieht, während die Liste korrekt ist. Der Vergleich eines Seitenaufrufs im Browser mit einem rohen Verbindungsversuch trennt diese beiden Situationen in weniger als einer Minute.

Lesen Sie den Fehler in der Phase, in der er auftrat

Reproduzieren Sie den Versuch in einem Terminal, damit die Phasen sichtbar werden. Die drei Befehle unten lösen den Namen auf, prüfen, ob der Port antwortet, und geben die Aushandlungszeilen aus einem OpenVPN-Profil aus:

dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"

Antwortet der Port und meldet die Aushandlungszeile ein Zertifikatsproblem, ist der Knoten in Betrieb und Ihr Profil veraltet. Antwortet der Port überhaupt nicht, ist der Eintrag ein Kandidat, der gescheitert ist, und zum nächsten zu wechseln ist die richtige Reaktion, statt Ihren Client zu debuggen. Notieren Sie die Phase in einer kurzen Zeile, und der nächste Versuch beginnt mit Wissen statt mit Hoffnung.