DynDNS.org Update Scripte ohne DNS-Check von LoUiS

Dungeonwatcher · Beitrag von **Dungeonwatcher** » 19 Jun 2007, 15:07

Hi!

Die Testfirmware trudelte gerade hier ein, wurde aufgespielt und so sieht es jetzt aus:

19.06.2007 14:53:24	exec:getenv IPnameselfhostde	88.134.2.80
19.06.2007 14:53:09	repeat:300	timer started
19.06.2007 14:53:09	lastresult:	DNS lookup failure
19.06.2007 14:53:09	lastresult:	DNS lookup failure
19.06.2007 14:53:09	lastresult:	DNS lookup failure
19.06.2007 14:53:09	lastresult:	DNS lookup failure
19.06.2007 14:53:09	http://carol.selfhost.de/update?username=12345&password=678910&myip=192.168.100.11	DNS lookup failure
19.06.2007 14:53:09	lastresult:	88.134.2.80
19.06.2007 14:53:09	exec:getenv IPnameselfhostde	88.134.2.80

Das schaut doch jetzt richtig gut aus, oder?

Da es bei KDG immer schwierig ist eine neue IP zu bekommen, habe ich so getestet:

- LC nach automatischem Warmstart nicht wieder angefasst
- Kabelmodem ausgeschaltet
- Laptop an das Kabelmodem angeschlossen
- Kabelmodem wieder eingeschaltet
- Laptop bekommt eine neue IP
- Kabelmodem wieder ausgeschaltet
- LC an's Kabelmodem angeschlossen
- Kabelmodem eingeschaltet
- LC bekommt wieder die 192er IP
- LC will bei SelfHost.de updaten und wird geblockt
- LC beendet die Verbindung zu Kabelmodem und baut sie neu auf
- LC hat nun die öffentliche IP

Die IP des LC hat sich zwar trotzdem nicht geändert, aber nachdem der LC die 192er IP bekam, baute er die Verbindung ab und anschließend neu auf. Diesmal mit der korrekten öffentlichen IP. Ich denke das das Script mit einer veränderte öffentl. IP jetzt auch korrekt bei SelfHost.de updaten würde. Oder was sagen die hiesigen Experten dazu?

Bye/2

DirkK · Beitrag von **DirkK** » 19 Jun 2007, 15:20

Hallo,

habe das Thema nun nicht bis ins allerletzte Detail verfolgt, da ich aber im Moment Probleme mit der Update-SW von Dyndns habe habe ich mir Jirkas Lösung mal angesehen und fand sie von der Idee her super. Habe sie dann eingespielt und festgestellt, dass es bei mir scheinbar nicht funktioniert. Ich vermute stark, dass es an meiner Installation liegt, würde micht aber freuen, wenn man des doch zum Laufen bekäme.

Ich habe einen LC-1811 mit zwei DSL-Anschlüssen und Loadbalancing. Dem 1811 vorgeschaltet sind zwei Fritzboxen, die als Router fungieren (notwendig, damit die Fritzboxen an die ISDN-Anlage angeschlossen werden können und darüber VoIP anbieten). D.h. im 1811 sind zwei Gegenstellen per Ethernet eingestellt. Diese Verbindungen sind dauerhaft aktiv, also auch wenn die Fritzboxen die Zwangstrennung durchlaufen (das dürfte ein Problem hier sein).

Ich habe nun fünf dyndns-Hosts. Zwei davon werden von den Fritzboxen aktualisiert. Die restlichen drei wurde bis jetzt durch den dyndns-updater aktualisiert, wobei hier das Problem war, dass durch das Loadbalancing sehr oft eine Aktualisierung erfolgte, da die Anfrage ja mal über die eine und beim nächsten mal zu 50% über die andere Fritzbox rausgeht.

Die optimale Lösung wäre natürlich, wenn man nun eben die Hosts über die entsprechend festgelegte Gegenstelle aktualisieren könnte, so dass die IP für 24h gleich bliebe.

Seht Ihr da eine Lösungsmöglichkeit?

Gruß
Dirk

Jirka · Beitrag von **Jirka** » 19 Jun 2007, 17:10

Hi Dungeonwatcher,

> Das schaut doch jetzt richtig gut aus, oder?

Ja. Aber es war kein DynDNS-Update notwendig. Insofern sieht man halt nicht wirklich viel.

> - LC nach automatischem Warmstart nicht wieder angefasst

D. h. das Gerät weiß noch die letzte IP, die erfolgreich geupdatet wurde. (Die vergißt es erst nach einem Kaltstart und dann versucht das Script die IP per DNS-Check zu ermitteln.)

> - LC beendet die Verbindung zu Kabelmodem und baut sie neu auf

Sehr schön.

> - LC hat nun die öffentliche IP

In dem Fall tatsächlich die gleiche wie vorher, wie Du ja auch schon erkannt hast.

> Ich denke das das Script mit einer veränderte öffentl. IP jetzt auch korrekt bei SelfHost.de updaten würde. Oder was sagen die hiesigen Experten dazu?

Na klar

Viele Grüße,
Jirka

Jirka · Beitrag von **Jirka** » 19 Jun 2007, 17:47

Hallo Dirk,

Ich habe einen LC-1811 mit zwei DSL-Anschlüssen und Loadbalancing. Dem 1811 vorgeschaltet sind zwei Fritzboxen, die als Router fungieren (notwendig, damit die Fritzboxen an die ISDN-Anlage angeschlossen werden können und darüber VoIP anbieten). D.h. im 1811 sind zwei Gegenstellen per Ethernet eingestellt. Diese Verbindungen sind dauerhaft aktiv, also auch wenn die Fritzboxen die Zwangstrennung durchlaufen (das dürfte ein Problem hier sein).

Die Scripte sind so geschrieben, dass sie nur funktionieren, wenn der LANCOM-Router selber die WAN-Verbindung herstellt. Da gibt es zwei Punkte, der eine, den hast Du selber schon erkannt, ist die Trennung und der Neuaufbau der Verbindung. Das sind in dem Script auslösende Faktoren, treten diese nicht ein, ahnt das Script nicht, dass eine Aktualisierung erforderlich wäre. Der zweite ist, dass das Script versucht die WAN-IP (des LANCOM) an den DynDNS-Anbieter zu übermitteln und auch anhand der zugewiesenen WAN-IP und der IP mit der die letzte erfolgreiche Aktualisierung stattfand überprüft, ob eine Aktualisierung erforderlich ist.

Ich habe nun fünf dyndns-Hosts. Zwei davon werden von den Fritzboxen aktualisiert.

Und funktioniert das nicht mit den Fritz!Boxen? Oder warum reicht Dir das nicht?!

Die restlichen drei wurde bis jetzt durch den dyndns-updater aktualisiert, wobei hier das Problem war, dass durch das Loadbalancing sehr oft eine Aktualisierung erfolgte, da die Anfrage ja mal über die eine und beim nächsten mal zu 50% über die andere Fritzbox rausgeht.

Ja, das sollte man nicht machen ...

Seht Ihr da eine Lösungsmöglichkeit?

Da wäre nur eine Passiv-Variante möglich, da in Deinem Fall die LANCOM-Router ja keine öffentliche IP haben. D. h. das Script übermittelt keine IP an den DynDNS-Anbieter (dann wird die öffentliche Source-IP genommen, mit der das Update angefordert wurde, in dem Fall also die WAN-IP der entsprechenden Fritz!Box). Zur Überprüfung ob eine Aktualisierung erforderlich ist (die LANCOM-Router kriegen ja nicht mit, ob die Fritz!Boxen eine neue WAN-IP haben), wäre regelmäßig eine Kontrolle erforderlich (was dann auch bedeutet, dass es keine unverzügliche "Sofort-Aktualisierung" geben wird). Für diese Kontrolle müßte das Script eine Webseite von DynDNS aufrufen, die die WAN-IP liefert ( http://checkip.dyndns.org/ wobei es da noch schönere gibt, die nur die WAN-IP liefern).

Aber ich frage mich, ob das nötig ist, wenn doch die Fritz!Boxen aktualisieren.

Viele Grüße,
Jirka

DirkK · Beitrag von **DirkK** » 19 Jun 2007, 18:49

Hallo Jirka,

danke für Deine Ausführungen. Die anderen Punkte (WAN-IP LC und checkscript dyndns) hatte ich auch bereits gesehen, jedoch insgeheim gehofft, dass Euch/Dir da noch was dazu einfällt, wie man das evtl. Lösen kann.

Jirka hat geschrieben:Aber ich frage mich, ob das nötig ist, wenn doch die Fritz!Boxen aktualisieren.

Das Problem bei den Fritzboxen ist, das die natürlich nur jeweils einen Host aktualisieren und nicht mehrere gleichzeitig.

Danke nochmal, Gruß
Dirk

Jirka · Beitrag von **Jirka** » 19 Jun 2007, 19:45

Hallo Dirk,

Das Problem bei den Fritzboxen ist, das die natürlich nur jeweils einen Host aktualisieren und nicht mehrere gleichzeitig.

Hmm. Eigentlich brauch man ja auch nur einen ...

Ich kenne mich mit Fritz!Boxen nicht so gut aus, aber gib doch mal in der Fritz!Box an der Stelle wo Du den FQDN eingibst einfach 2 FQDNs ein, aber durch Komma getrennt. Also so:
vorher: name.dyndns.org
nachher: name.dyndns.org,name1.dyndns.org

dass Euch/Dir da noch was dazu einfällt, wie man das evtl. Lösen kann

Also eine Lösung gibt es da, wie bereits angedeutet. Aber ich halte da nicht viel von.
Na probier das erstmal mit der Fritz!Box und zwei FQDNs.

Viele Grüße,
Jirka

Jirka · Beitrag von **Jirka** » 19 Jun 2007, 22:40

Hallo Dirk,

für die Angabe der 2 FQDNs wäre natürlich Voraussetzung, dass die beide dem selben DynDNS-Account zugeordnet sind.

Falls das nicht gehen sollte gibt es hier (Link) noch eine Anleitung für die Nutzung von mehreren DynDNS-Accounts mit der Fritz!Box.

Die weiter oben erwähnte "Passiv-Variante", wäre nämlich so einfach doch nicht zu realisieren, weil die Prüfung ob ein Update erforderlich ist (also ob sich die IP der ipcheck-Webseite von der letzten erfolgreich geupdateten IP bei DynDNS unterscheidet) doch nicht so einfach zu implementieren ist.

Viele Grüße,
Jirka

DirkK · Beitrag von **DirkK** » 19 Jun 2007, 23:28

Hallo Jirka,

Jirka hat geschrieben:Hmm. Eigentlich brauch man ja auch nur einen ...

Nicht, wenn jedes Familienmitlgied seine eigene Adresse braucht und man auch noch für Freunde die Webseiten hostet.

Jirka hat geschrieben:aber gib doch mal in der Fritz!Box an der Stelle wo Du den FQDN eingibst einfach 2 FQDNs ein, aber durch Komma getrennt. Also so:
vorher: name.dyndns.org
nachher: name.dyndns.org,name1.dyndns.org

Habe ich probiert, funktioniert leider nicht.

Jirka hat geschrieben:für die Angabe der 2 FQDNs wäre natürlich Voraussetzung, dass die beide dem selben DynDNS-Account zugeordnet sind.

Das wäre zwar der Fall, aber geht leider nicht.

Jirka hat geschrieben:Falls das nicht gehen sollte gibt es hier (Link) noch eine Anleitung für die Nutzung von mehreren DynDNS-Accounts mit der Fritz!Box.

Danke für den Link! (Du machts Dir ja ne Menge Mühe zu helfen: Respekt!) Solche "Schweinereien" kenne ich zwar, habe da aber noch nicht wirklich weiter geforscht, da man beim Ändern der Fritzbox FW auf file-level Ebene sich selbst ganz schön in's Knie schiessen kann (habe eine Eumex mit der Original-FritzBox-FW umgepatcht). Aber stimmt, vielleicht ist das am Ende doch der sauberste und zuverläsigste Weg. Vor allem muss man sich dann da keine Gedanken mehr bzgl. Loadsharing machen.

Danke nochmal für die Bemühungen!
Dirk

RoiDanton · Beitrag von **RoiDanton** » 24 Jun 2007, 10:45

Hallo,

super Arbeit mit den DynDNS Scripten.

Ich wollte gerade mal eines anpassen für Regfish's DynDNS Service.
Leider bin ich damit total überfordert.

Könnte mir mal einer von Euch mit einem entsprechenden Script oder Ansatz auf die Sprünge helfen?

REGFISH Parameter:

http://www.regfish.de/domains/dyndns/dokumentation

Danke!

Jirka · Beitrag von **Jirka** » 24 Jun 2007, 19:13

Hallo RoiDanton,

> Leider bin ich damit total überfordert.

Die umfangreiche Dokumentation der Scripte sollte eigentlich genau das bzw. das Anpassen an die persönlichen Bedürfnisse ermöglichen ...

> REGFISH Parameter:

Na die Dokumentation ist ja nur so halb ... Da muss man immer alles ausprobieren, wie es denn nun wirklich ist. Die sollten die mal überarbeiten.

1) Mein erster Test lieferte gleich den Fehlercode 412, der gar nicht in der Fehlerauswertung verzeichnet ist. Wie soll man da ein ordentliches Script schreiben, wenn man nicht mal weiß, was es alles für mögliche Fehlercodes gibt, oder man nur die Hälfte zu sehen bekommt.

2) Das erste unter 3.2 angegebene Update-Beispiel ist falsch, da fehlt nach dem Parameter fqdn das =-Zeichen.

3) thisipv4, oben als Pflichtparameter angegeben, scheint doch nicht Pflicht zu sein, denn bei den beiden unteren Beispielen fehlt die Angabe dieses Parameters.

4) Was wird für ein Fehlercode bei Überlastung geliefert? (zu häufige Updates, Fehler bei regfish, Systemauslastung bei regfish)

Du kannst diese Punkte ja mal bitte regfish mitteilen.

> Könnte mir mal einer von Euch mit einem entsprechenden Script oder Ansatz auf die Sprünge helfen?

Ich habe mal das selfHOST-Script als Grundlage genommen und das entsprechend angepasst. Da die Doku von regfish schlecht ist und ich bei regfish keinen DynDNS-Account habe, konnte ich das Script nur so aufschreiben. Ich habe nichts ausgetestet, nichts ausprobiert, nichts hinterfragt. Es ist vielleicht auch nicht optimal (könnte z. B. zwei Zeilen kürzer sein), denn dafür müßte man wirklich alle Rückgabecodes kennen. Von daher also wirklich Beta-Status, Du müßtest also regelmäßig schauen, was in der Status-Aktions-Tabelle so abläuft.
Zur (vollständigen) Änderung der Kommentare hatte ich keine Zeit, die stimmen also nur teilweise.

Viele Grüße,
Jirka

RoiDanton · Beitrag von **RoiDanton** » 24 Jun 2007, 20:41

Hui das war ja schnell,

Danke nun komm ich vieleicht auch etwas weiter.

Mit regfish werde ich mich mal in Verbindung setzen wegen der genauen Dokumentation.

Falls Interesse besteht zum Weitertesten, kann ich ja mal eine Subdomain erstellen und die Daten posten. Wäre das was?

Danke vielmals.

Jirka · Beitrag von **Jirka** » 24 Jun 2007, 23:04

Hallo RoiDanton,

> Danke nun komm ich vieleicht auch etwas weiter.

Kannst ja berichten, wie es mit dem Script läuft, wie gesagt anfangs regelmäßig die Status-Aktions-Tabelle (http://<NameoderIP>/config/1/4/20/1/) begutachten.

> Falls Interesse besteht zum Weitertesten, kann ich ja mal eine Subdomain erstellen und die Daten posten. Wäre das was?

Da würde ich ganz gerne in 3 bis 4 Wochen drauf zurückkommen, bis dahin aus Zeitgründen erst mal nicht. Es sei denn das Script macht bei Dir arge Schwierigkeiten.

Viele Grüße,
Jirka

RoiDanton · Beitrag von **RoiDanton** » 26 Jun 2007, 08:56

Hmm,

also aus meiner Sicht kannst Du den Betastatus beenden.
Das Skrip funzt einwandfrei.

Zum Testen für interessierte Entwickler hier mal eine Subdomain:

Domain: "dyndns.gravity-world.com "
Token: (aus Sicherheitsgründen entfernt, siehe nachfolgendes Posting)

Gruß, Roi

Jirka · Beitrag von **Jirka** » 26 Jun 2007, 10:35

Hallo Roi,

> also aus meiner Sicht kannst Du den Betastatus beenden.
> Das Skrip funzt einwandfrei.

Na ja, das kann man erst nach ein paar Wochen sagen, wenn denn auch mal ein Update nicht auf Anhieb klappt, weil es irgendeinen Fehler gab. Ich stelle ziemlich hohe Ansprüche an so ein Update-Script ...

Angenommen es gibt den Fehlercode 410 würde das Script zum Beispiel ein Problem kriegen, aber laut Doku gibt es den nicht und ich konnte ihn auch nicht erzeugen.

> Zum Testen für interessierte Entwickler hier mal eine Subdomain:

Hab mal kurz durchgetestet:

Angabe der IP 123.94.94.1234 führt zu einem unerwarteten Fehler, Code 414; sollte eigentlich "Die übergebene IPv4 Adresse ist ungültig.", Code 408 ergeben. Bei IP 123.943.94.13 selbes Ergebnis. (Kann man nur froh sein, dass ein Fehler dieser Art mit einem LANCOM nicht auftaucht.)

Angabe einer unzulässigen TTL führt nicht zum Fehler "TTL-Range ist ungültig", Code 407.

Falscher Token und falscher FQDN führen zu den erwarteten Fehlern.

Da ich mit dem Token auch die Domain "www.gravity-world.com" updaten konnte, habe ich den Token mal aus Sicherheitsgründen gelöscht. Wär ja lustig, wenn so ein Token für alle DynDNS-Domains bei regfish gilt (kennst Du noch eine Domain bei regfish, die nicht zu Dir gehört und per DynDNS geupdatet wird?).

Viele Grüße,
Jirka

Irgendwie hatte ich eben bei einem Test versehentlich noch mal die "www.gravity-world.com" geupdatet, hatte dann gleich wieder auf die alte IP zurückgeupdatet, aber scheinbar hilft das nicht ... wahrscheinlich hat sich inzwischen die IP geändert, oder Du hattest das schon mitbekommen und einen Verbindungsneuaufbau initiiert. Vielmals sorry für die Ausfälle ...
Geht scheinbar doch, muss man mit der URL aufrufen, die IP alleine liefert nur eine Info-Seite ...

RoiDanton · Beitrag von **RoiDanton** » 26 Jun 2007, 18:18

Oh oh..

Fehler erkannt.

Die Haupt IP stimmt noch.
Hab DynDNS auf gravity-world.com deaktiviert.

Eine alte Domain hab ich da noch, die nicht mehr genutzt wird aber noch bis 2008 läuft:

Domain: "schwarzekiste.de"
Token: "ead25a7a14cb924a3dab19d3ac0d1cf8"

Bei mit funzt das script auf 2 Routern.

Da ich mit dem Token auch die Domain "www.gravity-world.com" updaten konnte, habe ich den Token mal aus Sicherheitsgründen gelöscht. Wär ja lustig, wenn so ein Token für alle DynDNS-Domains bei regfish gilt

Doch - für die TLD und alle subdomains. (für jede TLD gibts aber nen eigenen Token.)

Irgendwie hatte ich eben bei einem Test versehentlich noch mal die "www.gravity-world.com" geupdatet, hatte dann gleich wieder auf die alte IP zurückgeupdatet, aber scheinbar hilft das nicht ... wahrscheinlich hat sich inzwischen die IP geändert, oder Du hattest das schon mitbekommen und einen Verbindungsneuaufbau initiiert. Vielmals sorry für die Ausfälle ...
Geht scheinbar doch, muss man mit der URL aufrufen, die IP alleine liefert nur eine Info-Seite ...

Jupp - ist ein Rootserver mit nur einer IP, darauf verweisen alle meine Domains (ausser die dyndns) für unsere DSL Lines.

So long, Roi!