Öffentliche VPN-Konfiguration funktioniert nicht mehr? Lies die Fehlerstufe

Das Profil lief am Dienstag, und am Freitag dreht der Client dreißig Sekunden lang und gibt auf. Auf deinem Rechner hat sich nichts geändert. Genau das ist der Punkt: Eine heruntergeladene Konfiguration beschreibt einen Host in einem Moment, und der Betreiber am anderen Ende ist nicht verpflichtet, diese Beschreibung wahr zu halten. Die Versuchung besteht darin, Sicherheitseinstellungen zu bearbeiten, bis der Tunnel wieder hochkommt. Genau dieser Impuls führt dazu, dass Leute am Ende ein Profil mit deaktivierter Zertifikatsprüfung betreiben, was schlimmer ist als gar kein Tunnel.

Die Datei beschreibt einen Moment, keinen Vertrag

Eine Konfigurationsdatei ist eine Menge von Zusicherungen: Dieser Hostname lauscht auf diesem Port mit diesem Protokoll, präsentiert ein Zertifikat, das zu diesem Namen passt, und akzeptiert diese Zugangsdaten. Sobald eine davon nicht mehr stimmt, ist die Datei veraltet, und die Reparatur gehört auf die Betreiberseite der Grenze, nicht in deine Einstellungen.

Öffentliche Knotenlisten machen das von ihrer Natur her deutlich. Knoten werden von Freiwilligen betrieben, sie erscheinen und verschwinden, Adressen werden wiederverwendet, und Ports werden von dem Netz blockiert, hinter dem sie liegen. Die Liste ist ein Schnappschuss, der neu erzeugt wird, und die Kopie auf deiner Platte ist ein Foto eines älteren Schnappschusses.

Kommerzielle Dienste ändern sich langsamer, aber nicht nie. Zertifizierungsstellen wechseln, ein Listener zieht von einer geteilten Adresse auf eine eigene um, ein altes Protokoll wird abgeschafft, und eine neue Cipher-Liste kommt an. Jedes davon ist unsichtbar, bis dein Client eine Verbindung versucht und eine andere Antwort bekommt als die, die die Datei erwartet.

Lies die Fehlerstufe, bevor du eine Einstellung anfasst

Die Fehlermeldung sagt, welche Zusicherung verletzt wurde, und jede Zusicherung hat eine völlig andere Reparatur. Cipher zu bearbeiten, wenn der Hostname nicht mehr auflöst, kostet einen Nachmittag und lehrt niemanden etwas.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Die mittlere Zeile trennt einen blockierten Pfad von einem kaputten Handshake, und die dritte zeigt den Aussteller und die Gültigkeitsdaten des tatsächlich präsentierten Zertifikats. Ist dieser Aussteller nicht der, den das Profil gepinnt hat, hat sich das Zertifikat geändert, und keine clientseitige Option macht den alten Pin wieder richtig.

Zertifikats- und Identitätsänderungen sind die leisen

Die meisten Fehler kündigen sich an. Identitätsänderungen nicht, denn ein Client, der einen Zertifikatsnamen pinnt, lehnt ein völlig gutes neues Zertifikat mit einer Meldung ab, die viele als Softwarefehler lesen. Der Tunnel ist in Ordnung. Der Pin ist veraltet.

Suche die Identitätsoptionen, bevor du irgendetwas schließt:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Trägt das Profil eine eingebettete CA und der Betreiber ist auf eine neue Autorität umgestiegen, kann die alte Datei den neuen Server nicht validieren. Den CA-Block durch den veröffentlichten des Betreibers zu ersetzen ist eine legitime Reparatur. Die Prüfungsdirektive zu löschen ist es nicht, und es sind dieselben Tastenanschläge mit einem ganz anderen Ergebnis.

Ein Client-Upgrade kann dasselbe Symptom ohne jede Änderung beim Betreiber erzeugen. Optionen, die stillschweigend geduldet wurden, werden abgelehnt, oder ein veraltetes Protokoll wird entfernt. Das ist eine Kompatibilitätsgrenze in deiner Software, und es lohnt sich, ein zweites Profil mit demselben Client zu testen, bevor du dem Server die Schuld gibst.

Nur der Betreiber kann einen gültigen Ersatz veröffentlichen

Wenn ein Knoten verschwindet, muss der Ersatz aus derselben Quelle kommen, die das Original veröffentlicht hat. Ein Profil, das per Direktnachricht ankommt, weil es „denselben Servernamen verwendet“, ist eine ungeprüfte Konfiguration von einer unbekannten Partei, und der Import gibt dieser Partei die Kontrolle über dein Routing.

Die Prüfung ist billig. Hole die aktuelle Datei vom veröffentlichten Ort, vergleiche Endpunkt und Protokoll mit der Liste und bestätige den Fingerabdruck des CA-Materials, statt dem Dateinamen zu vertrauen:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Unterscheiden sich die beiden Hashes nur in Leerraum, hast du eine Formatierungsänderung. Unterscheiden sie sich bei den Endpunkten, hat der Betreiber etwas verschoben, und die veröffentlichte Datei ist maßgeblich. Ist die veröffentlichte Datei älter als deine, siehst du wahrscheinlich einen Cache, und die veraltete Antwort schickt dich in die falsche Richtung.

Ziehe den alten Eintrag zurück und halte fest, was passiert ist

Sobald ein funktionierender Ersatz verifiziert ist, lösche das alte Profil, statt es als Rückfall zu behalten. Ein veralteter Eintrag, der halb verbindet, ist eine Falle: Er wird während einer Störung ausgewählt, er scheitert langsam, und die Person, die debuggt, verbringt die ersten zehn Minuten mit der falschen Datei.

Führe eine kurze Aufzeichnung außerhalb der Konfiguration: das Datum, den alten Endpunkt, die Fehlerstufe und was ihn ersetzt hat. Öffentliche Knoten wechseln, und sechs Wochen später kommt dieselbe Frage mit einer anderen Person daran. Eine Zeile in einer Notizdatei beantwortet sie in Sekunden.

Wenn aus einem Netz jeder Knoten auf dieselbe Weise scheitert und aus einem anderen keiner, dann hör auf, Profile zu bearbeiten, und sieh dir den lokalen Pfad an. Ein Captive Portal, ein gefilterter Portbereich oder ein abfangender Proxy erzeugen identische Fehler bei unabhängigen Anbietern, und genau dieses Muster ist das einzige Signal dafür, dass das Problem nie die Datei war.