DD-WRT - DDNS (Custom): Wie wird die IP übergeben?

Hallo Slainte,

...klingt vernünftig und würde drei Dinge erklären.
1. Warum ich vom Router keine IP per GET zu in meinem Testskript übermittelt bekomme.
2. Warum ich keinen Hinweis im Web finde, wie ich die IP als Variable ins Webinterface schreiben kann.
3. Warum ich im Router eine Erfolgemeldung erhalte auch wenn ich keine IP angebe.

Was es nicht erklärt ist, warum ich für Strato viele Beispiele gefunden habe, die in der URL "myip" nutzen.
Beispiel-URL enthalten dort &myip=<IP> oder &myip=%IP% oder auch &myip=__MYIP__.

...nicht vollständig.
Mit der Übergabe der IP als Wert, könnte man auch von B aus eine Umleitung von A nach C vornehmen.
Zugegebenermaßen wäre das aber nur selten sinnvoll.

Vielleicht ist die Antwort auch, dass der Dienst bei Strato die von ihm erkannte Remote-IP verwendet, es sei denn es wird mit myip= eine IP explizit übergeben.

Ich hatte es in der Testphase auch geschafft bei Strato auf eine IP umzubiegen, die ich angegeben hatte.
Das wollte ich jetzt nochmal verifizieren, aber egal was ich im Moment per Browser treibe, erhalte ich von Strato nur diese Antwort:
badauth 0.0.0.0
Keine Ahnung was da gerade los ist.

Per Router habe ich allerdings noch keinen "Beweis" erhalten, dass die Umleitung auch tatsächlich erfolgt.
Er meldet nur, dass es erfolgreich wäre.
Ich habe jetzt testweise einen zweiten DD-WRT-Router, an anderer Stelle (andere externe IP) auf DDNS konfiguriert und der meldet mir auch, dass das Update erfolgreich wäre.
sub.meinedomain.de wird dadurch aber nicht auf die neue IP umgebogen.

Wie es aussieht ist der DDNS-Kram im DD-WRT-Router nicht in Ordnung.
Erfolg melden und Erfolg haben scheinen da nicht Hand in Hand zu gehen.
Wenn's tatsächlich so ist, wäre ich nicht sonderlich überrascht.
Um DNS- und Browsercache auszugrenzen habe ich in den Webinterfaces der beiden Router ein Ping-Commando abgesetzt.
ping sub.meinedomain.de führt bei beiden jeweils zur selben, unveränderten IP.


Ein Blick tiefer bringt weitere Merkwürdigkeiten:
im ddns.log steht Folgendes

Was heißt hier updated successfully und badauth 0.0.0.0 im selben Log.

Vielleicht liegt die Ursache doch oder auch oder zumindest im Moment irgendwo bei Strato.
Ich forsche mal weiter, aber nicht mehr heute.

Gruß Frank

Hallo Stefan,

Danke, kenne ich und nutze es auch an anderer Stelle.
In Zusammenhang DD-WRT und Strato ist es nicht relevant.

Gruß Frank

Hallo,

vorab: es funktioniert jetzt und es war ein ganz banaler Fehler meinerseits: Falsche Logindaten.

Zu meiner Ehrenrettung möchte ich allerdings anführen, dass ein paar Umstände es gut verschleiert haben, dass meine Logindaten falsch waren.

Für ftp und ssh nutze ich als Benutzername www.meinedomain.de
Wie ich jetzt feststellte geht das auch mit dem Benutzernamen meinedomain.de
Für DynDNS allerdings muss der Benutzername zwingend ohne www. angegeben werden, also nur meinedomain.de

Hinzu kamen die weiter unten aufgeführen Fallen im DD-WRT.


Die Einrichung

Sie ist eigentlich sehr einfach und genau gemäß der entsprechenden Anleitungen:

1. Subdomain einrichten
https://www.strato.de/faq/article/339/Kann-ich-mit-den-STRATO-Paketen-ei ...

2. DynDNS für die Subdomain aktivieren
https://www.strato.de/faq/article/671/So-einfach-richten-Sie-DynDNS-fuer ...

3. DDNS im DD-WRT-Router einrichten
https://www.dd-wrt.com/wiki/index.php/DDNS_-_How_to_setup_Custom_DDNS_se ...
Die Hochkommata bei den Einträgen für Username, Password und Hostname natürlich weglassen.


Telnet-Sitzung in einer Eingabeausforderung

Einige Dinge kann man per Telnet machen. hier eine exemplarische Telnet-Sitzung...

telnet 192.168.1.1
Die IP muss die des Routers sein
root
Als "login" muss root verwendet werden auch wenn man für's Webinterface einen anderen Benutznamen eingerichtet hat.
Passwort
Das Password ist dasselbe, wie das für's Webinterface.
cd /tmp/ddns
Verzeichniswechsel
ls
Dateien auflisten
Ausgabe: ddns.log inadyn.conf inadyn_ip.cache inadyn_time.cache
rm ddns.log
Log-Datei löschen
inadyn -u benutzername -p kennwort --verbose 5 --input_file inadyn.conf
benutzername und kennwort für den DDNS-Anbieter anpassen
Der Befehl inadyn löst die DDNS-Aktualisierung aus.
Hier können auch zusatzliche Optinen wie z.B. --verbose 5 angegeben werden.
cat ddns.log
Inhalt der Log-Datei anzeigen lassen
exit
Telnet-Sitzung beenden

Der Inhalt des ddns.log wird allerdings auch im Webinterface im Feld "DDNS Status" angezeigt.
Zusätzlich Optionen für den Befehl inadyn lassen sich im Feld "Additional DDNS Options" eintragen.
Ein sofortiges Ausführen des Befehls kann man mit dem Schalter [Apply Settings] auslösen.
(Bei Änderungen der Konfiguration zuvor noch auf [Save] klicken.)

Die Telnetsitzung kann man sich daher sparen eigentlich sparen.


1. Böse Falle im DD-WRT

Löscht man die ddns.log kommt die erste Irreführung:
Im Feld "DDNS Status" steht dann nicht nichts und auch nicht "no log entries", sondern
Connecting to server
Das ist aber inhaltlich falsch, hier wird nicht connected, da kann man warten bis man schwarz wird. Hier passiert einfach Nichts.


2. Böse Falle im DD-WRT

Löst man die Aktualisierung aus und hat dabei einen falschen Benutzernamen eingetragen, so endet die letzte Zeile der Statusanzeige mit den Worten:
updated successfully
Was auch immer erfolgreich sein mag, die Aktualisierung beim DynDNS-Anbieter ist es nicht.
Die Antwort des DynDNS-Servers wird hier nicht ausgegeben und die lautet u.U.
bad auth 0.0.0.0 (schlechte Authentifizierung = falscher Login)

Man sollte - zumindest in der Testphase - unbedingt die Zusatzoption
--verbose 5
ins Feld "Additional DDNS Options"eintragen.
(Mindestens --verbose 3)
Dann wird auch die Antwort des DynDNS-Servers als letzte Zeile ausgegeben.
Die Antwort muss entweder
good 82.149.225.21
oder
nochg 82.149.225.21
lauten, sonst hat's nicht funktioniert.

good = Aktualisierung durchgeführt
nochg = no change = alles in Ordnung, aber die IP war schon die Aktuelle

Warum die Serverantwort nicht auch bei Verboselevel <=2 (Ausführlichkeitsebene) ausgegeben wird ist mir unklar.
Die Serverantwort ist eigentlich die wichtigste Information und die sollte immer ausgegeben werden, wenn man die Ausgaben nicht explizit komplett unterdrücken möchte.
Naja, ich weiß es jetzt und Ihr wisst es jetzt auch.


Angabe der IP

Wie SlainteMhath schrieb, ist die Angabe der IP, die verwendet werden soll nicht nötig.
Der DynDNS-Server nimmt die IP von der der Aufruf erfolgt.
Danke für den Hinweis.

Zumindest bei Strato kann man das optional anders regeln.
Die zusätzliche Get-Variable myip= lässt es zu eine andere IP zur Aktualisierung vorzugeben.

Man kann also (beispielsweise per Browser) folgende URL aufrufen:

Aktualisierung mit der aktuellen WAN-IP
Dasselbe mit den Logindaten schon in der URL eingefügt
Aktualisierung mit einer manuell vorgegebenen IP
Dasselbe mit den Logindaten schon in der URL eingefügt

Diese vier Beispiele funktionieren auch mit http statt https.
Die Logindaten werden dann aber unverschlüsselt übermittelt.
Falls man gezungen sein sollte http zu verwenden, so sollte man zumindest unbedingt ein explizites DynDNS-Passwort bei Strato anlegen und das verwenden und nicht das Master-Passwort unverschlüsselt schicken.

Hier sind noch weiteren, optionalen Variablen zu finden:
https://help.dyn.com/remote-access-api/perform-update/
Für die einfache Umbiegung einer Sub-Domäne sind sie nicht notwendig.


DynDNS-Clients

Wieso finde ich eigentlich keinen kostenlosen DynDNS-Client für Windows?
Nicht, dass es immer für Alles eine kostenlose Variante geben muss, Programmierarbeit hat seinen Wert, aber gerade hier erscheint mir die Aufgabe doch so simplel, dass es mich einfach wundert, dass das Angebot dünn ist.
Mit beispielsweise wget als geplante Aufgabe wäre es technisch schnell erledigt.

Ein URL-Aufruf per C# wäre auch schnell programmiert.
Man müsste nur noch für die unterschiedlichen Dienstanbieter die jeweilige Syntax zusammensuchen und einen Timer einfügen, der die aktuelle WAN-IP ermittelt.

Vielleicht ist das Angebot auch so dünn, weil es mit einfachen Mitteln erledigt werden kann und es ohnehin am sinnvollsten ist, wenn die Aufgabe der Rouer übernimmt und nicht ein Tool auf einem angeschlossenen Rechner.

DD-WRT prüft mit den Defaulteinstellungen übrigens im 10-Minuten-Takt, ob sich die WAN-IP des Routers geändert hat.
Ob im Falle einer tatsächlichen Änderung diese erst in dieser Taktung bemerkt und beim Dienstanbieter aktualisiert wird, weiß ich nicht.
Falls die Reaktionszeit tatsächlich bis zu zehn Minuten lang sein sollte, wäre das für mich völlig akzeptabel.
Wem das nicht ausreichen sollte, der findet sicher Zusatzoptionen für inadyn/DD-WRT, die die Taktung erhöhen.

Gruß Frank