Von außen sehen ein veralteter Hostname und ein defektes VPN identisch aus. Der Client löst einen Namen auf, der Name zeigt irgendwohin, und die Verbindung läuft in eine Zeitüberschreitung oder wird abgelehnt. Das eine ist ein DNS-Aktualisierungsproblem, das andere ein Authentifizierungs- oder Weiterleitungsproblem, und der Unterschied wird erst deutlich, wenn Sie die veröffentlichte Adresse mit der Adresse vergleichen, die Ihre Leitung tatsächlich hat.

Zwei Fehler, die gleich aussehen

Der erste Fehler ist, dass der Eintrag noch die WAN-Adresse von gestern nennt. Der zweite ist, dass der Eintrag korrekt ist und der Tunnel Sie aus eigenen Gründen abweist. Beide erzeugen dieselbe Meldung im Client, und die Versuchung ist, Zertifikate neu zu erzeugen.

Die Reihenfolge ist hier wichtig. DNS zu prüfen dauert eine Minute und ist umkehrbar. Eine CA neu zu erzeugen ist beides nicht.

Vergleichen Sie zuerst die Adressen

Fragen Sie den Netzwerkeigentümer, welche Adresse die Leitung derzeit hat, und fragen Sie dann DNS, was veröffentlicht wird. dig +short vpn.example.com liefert die Antwort, die Ihr Client erhält, und dig @1.1.1.1 vpn.example.com zeigt, ob ein anderer Resolver etwas anderes sieht. Wenn die beiden nicht übereinstimmen, sehen Sie Cache-Verhalten und keinen defekten Updater.

Eine rekursive Antwort kann hinter einer Aktualisierung um ihre TTL zurückbleiben, deshalb halten Sie den autoritativen Eintrag und das, was Ihr Laptop zwischengespeichert hat, in getrennten Kisten.

Was der Zugangsnachweis des Updaters wirklich ist

Ältere DDNS-Geräte authentifizieren sich oft mit dem Kontopasswort selbst, weshalb ein Wechsel dieses Passworts sie stillschweigend lahmlegt. Sie versuchen es weiter mit dem alten Wert und melden nichts Nützliches. Die Anleitung von No-IP zu Gerätepasswörtern dokumentiert genau dieses Kompatibilitätsproblem bei älterer Hardware, und die vernünftige Antwort ist ein begrenzter Aktualisierungsnachweis statt eines schwächeren Kontopassworts.

Neuere Mechanismen stellen ein separates Aktualisierungstoken oder einen Schlüssel mit eigenem Lebenszyklus aus. Das ist der Wert, den Sie in den Router rotieren, und der, den Sie in Ihrem Nachweisverzeichnis erfassen. Es ist auch nicht der Wert, den Sie während der Fehlersuche in einen Chat-Thread einfügen sollten.

Prüfen Sie den nicht geheimen Status des Updaters: Zeitpunkt des letzten Erfolgs, Antwortkategorie und den Hostnamen, den er zu besitzen glaubt. Eine Ablehnung des Nachweises und ein Verbindungsfehler erfordern unterschiedliche Korrekturen.

Was eine DNS-Korrektur nicht leisten kann

Den Eintrag zu korrigieren schafft keine eingehende Erreichbarkeit. Wenn die Leitung hinter Carrier-Grade-NAT sitzt, wird kein Hostname eine eingehende Verbindung zum Laufen bringen. Es öffnet auch keine Firewall-Regel und leitet keinen Port weiter. Und es ist niemals ein Grund, die Serverprüfung im Client abzuschalten, was der Schritt ist, den Leute machen, wenn sie entscheiden, das Zertifikat müsse das Problem sein.

Umgekehrt ist ein Wechsel des VPN-Passworts keine Korrektur für veraltetes DNS. Er fügt demselben Ticket nur einen zweiten Fehler hinzu.

Neu verbinden und es durchgängig beweisen

Wenn der autoritative Eintrag stimmt, kann der Client noch einen alten Lookup halten. Nutzen Sie seine unterstützte Wiederverbindung oder Endpunkt-Aktualisierung und geben Sie ihm einen Moment, statt auf Verbinden zu hämmern. Beweisen Sie dann den Pfad in vier Schritten: Namen auflösen, Adresse bestätigen, prüfen, ob der Listener erreichbar ist, und authentifizieren. Vier getrennte Ergebnisse, vier getrennte Antworten.

Halten Sie den Updater auf der Rotationscheckliste neben dem VPN-Konto. Ein beabsichtigter Eintragsinhaber, ein gültiger Nachweis und ein beobachtbarer Erfolg sind das, was die nächste Version dieses Tickets verhindert.

Ähnliche Artikel