ddclient veröffentlicht den VPN-Ausgang: die Erkennungsquelle reparieren

Ihr DNS-Name löst jetzt auf eine Adresse eines VPN-Anbieters auf, und das Aktualisierungsprotokoll sieht vollkommen gesund aus. Diese Kombination ist normal. Eine webbasierte Erkennungs-Sonde fragt einen externen Dienst, welche Quelle er sieht, und wenn die Anfrage über ein Volltunnel-VPN hinausgeht, ist die Antwort der VPN-Ausgang und nicht Ihre Heim-WAN-Adresse. Der Aktualisierer hat seine Arbeit getan; die Arbeit war auf die falsche Beobachtung gerichtet.

Bestätigen Sie, was der Name erreichen soll

Ein öffentlicher Name für einen eingehenden Heimdienst braucht eine Adresse, über die zugelassene eingehende Verbindungen diesen Dienst erreichen können. Einen gemeinsamen Anbieter-Ausgang zu veröffentlichen, richtet dort keine eingehende Weiterleitung ein, und keine DNS-Konfiguration erzeugt diese Weiterleitung. Entscheiden Sie das, bevor Sie den Aktualisierer anfassen, denn es bestimmt, welche Adresse die richtige ist.

Ein privater Name für die Tunneladresse eines VPN-Clients ist ein anderes Problem mit einer anderen Antwort: Er gehört in privates DNS und braucht überhaupt keinen öffentlichen Erkennungsdienst. Beide Anforderungen zu vermischen ist der Weg, auf dem eine funktionierende Konfiguration beginnt, eine Adresse zu veröffentlichen, die niemand angefordert hat.

Auch Schnittstellenadressen brauchen Deutung. Die Adresse eines Laptops hinter einem Heimrouter ist nicht die öffentliche WAN-Adresse, und selbst die WAN-Adresse des Routers kann hinter Carrier-Grade-NAT liegen, wo ihre Veröffentlichung keine eingehende Erreichbarkeit erzeugen kann.

Reproduzieren Sie den Wert, bevor Sie etwas ändern

Beobachten Sie beide Wege getrennt. Ist der Tunnel oben, meldet eine Sonde den Ausgang; ist der Tunnel unten oder ist die Sonde an die physische Schnittstelle gebunden, meldet sie die Heimatadresse: curl --interface eth0 https://ifconfig.me. Unterscheiden sich diese beiden Antworten, haben Sie den Fehler reproduziert, ohne den Aktualisierer anzufassen.

Starten Sie dann den Client in einem Modus, der die Konfiguration prüft, ohne eine Aktualisierung auszuführen, etwa ddclient -verbose -noexec, und lesen Sie, welche Erkennungsmethode er gewählt hat. Die ausführliche Ausgabe nennt die Methode und den erhaltenen Wert, und das ist die Tatsache, die Sie vor jeder Bearbeitung brauchen.

Richten Sie die Erkennung auf den gewählten Weg

Muss der Name die Heim-WAN-Adresse veröffentlichen, muss die Erkennung genau diese Adresse beobachten. Drei Optionen funktionieren, grob nach Vorliebe geordnet: Lassen Sie den Router über seinen eigenen unterstützten Aktualisierer veröffentlichen; nutzen Sie ddclients Routerstatus-Erkennung gegen eine Seite, die der Router tatsächlich ausliefert; oder behalten Sie eine Web-Sonde, binden Sie sie aber an die physische Schnittstelle, damit sie außerhalb des Tunnels hinausgeht.

Für den Routerstatus-Weg verwenden neuere ddclient-Versionen die Optionsfamilie usev4 und fwv4, mit einem optionalen Überspringmuster für den umgebenden Seitentext. Prüfen Sie die README für Ihre installierte Version, denn ältere Versionen schreiben dieselbe Idee mit use und fw, und ein aus der falschen Version kopierter Optionsname scheitert beim Start.

Behalten Sie die Web-Erkennung, bedenken Sie, dass das Routing der Sonde und das Routing des Aktualisierungs-API-Aufrufs getrennte Entscheidungen sind. Der Aktualisierungsaufruf liefert den Eintrag; die Sonde bestimmt den Wert, der geliefert wird.

Halten Sie Geheimnisse und Versionen sauber

Router-Anmeldedaten und Anbieter-Token gehören in eine geschützte Konfigurationsdatei, nicht auf eine Kommandozeile, die in der Shell-Historie landet. Ausführliche Traces können beides enthalten, daher schwärzen Sie sie, bevor Sie sie in ein Ticket einfügen. Eine Erkennungsmethode, die eine authentifizierte Routerseite abgreifen muss, verlangt außerdem, dass diese Anmeldedaten über Firmware-Aktualisierungen hinweg funktionieren. Bewahren Sie sie mit derselben Sorgfalt auf wie das Anbieter-Token.

Die ddclient README dokumentiert die Erkennungsansätze und ihre Optionsnamen. Mischen Sie keine IPv4- und IPv6-Ergebnisse in einem Eintrag, und nehmen Sie nicht an, dass eine Option aus einer Version in einer anderen existiert.

Prüfen Sie den Wert, dann die Erreichbarkeit

Vergleichen Sie die vorgeschlagene Adresse mit dem beabsichtigten Endpunkt, bevor Sie eine Live-Aktualisierung zulassen, prüfen Sie dann nach einer autorisierten Aktualisierung das autoritative DNS und rechnen Sie mit Resolver-Caches. Eine niedrige TTL verkürzt die Wartezeit; sie macht einen falschen Wert nicht richtig.

Erst wenn der Eintrag korrekt ist, sollten Sie den eingehenden Dienst aus einem unabhängigen Netz testen, mit bereits genehmigter Firewall und Weiterleitung. Ein korrekter A-Eintrag beweist keinen erreichbaren Dienst, und ein statisches VPN-Lease kann die private Benennung vereinfachen, ohne einen öffentlichen Hostnamen zu reparieren, der auf das falsche WAN zeigt.