DDNS Updater DDNS Updater 2

[QTip]

Nach nahezu 8 Monaten Programmierens kann ich euch nun die erste Public Beta des DDNS Updaters 2 freigeben. Ich habe mich in dieser Zeit oft gefragt, ob es zu Zeiten von DSM 5++ und dem eingebautem DDNS Client noch Sinn macht, einen weiteren 3rdparty DDNS Client zu entwickeln. Der DDNS Updater 1.xx war zu einer Zeit gefragt, als es noch keinen eingebauten DDNS gab und auch nur wenige Router benutzerdefinierte Aktualisierungsurls zuliessen. Die Konfigurierbarkeit für neue Protokolle und vor Allem die Benutzung von mehr als einem Host pro Anbieter liessen mich trotzdem weiter machen. Ob es dann den entsprechenden Anklang bei den Benutzern findet wird die Zeit zeigen. Ich habe auch schon darüber nachgedacht, meine WebGui ebenfalls für den eingebauten DDNS als eine Art Konfigurator anzupassen, zu einem Ergebnis bin ich allerdings noch nicht gekommen.

DDNS Updaters 2 ist eine komplette Neuentwicklung, der Daemon ddclient wird nicht mehr verwendet. Die weitere Benutzung von ddclient als Daemon wurde durch die fehlende IPv6 Unterstützung und der für meine Zwecke unverträglichen Konfigurationsmöglichkeit ausgeschlossen. Ausserdem benötigt man nun kein Init_3rdparty und iPKG Perl für die SSL-Unterstützung, das Synology Perl ist ausreichend. Besonderes Augenmerk habe ich auf eine hohe Konfigurierbarkeit gelegt, damit die Benutzer bei einem neuen Protokoll nicht jedes Mal im Forum nachfragen müssen Es wird natürlich immer wieder Protokolle geben, welche sich nicht mit den vorhandenen Bordmitteln einrichten lassen. Für diese Fälle kann durch Hinzufügen eines in Perl geschriebenen Moduls die gewünschte Funktionalität erreicht werden, dazu später mehr.

Unterstützte Anbieter: 3322.org, afraid.org, all-inkl.com, changeip.com, cloudflare.com, direkt-domains.de, dnsexit.com, dnsmadeeasy.com, dnsomatic.com, dnspark.com, do.de, domopoli.de, domains.google.com, dslreports.com, dtdns.com, duckdns.org, dyn.com, dynu.com, dynv6.com, dyndns.za.net, easydns.com, einsweb.de, enomcentral.com, freedyn.de, gratisdns.de, gratisdns.dk, goip.de, joker.com, kontent.com, loopia.se, myonlineportal.net, namecheap.com, no-ip.com, nsupdate.info, opendns.com, ovh.com, regfish.de, selfhost.de, sitelutions.com, spdns.de, strato.com, twodns.de, udmedia.de, variomedia.de, xlhost.de, zoneedit.com

DDNS Updater 2: Anleitung - Instructions

Kurze Zusammenfassung, ich nenne sie "Highlights", der Funktionen:

• konfigurierbarer Benutzerdialog für das Hinzufügen und Bearbeiten von DDNS Hostnamen (gewünschte Felder und Bezeichnungen pro Anbieter)
• Gruppierung von Hosts per selbst zu erstellender Gruppen
• Aktiv und Inaktiv Setzen von Hosts
• Online/Offline-Modus per Gruppe aktivierbar, Offline-Methode konfigurierbar (pro Anbieter)
• minimales Aktualisierungsintervall, minimales Intervall bei Fehlern und maximales Intervall (Force Update) einstellbar (pro Anbieter), maximales Intervall (Force Update) auch pro Host
• Offline-Modus wenn die DS herunterfährt (pro Host konfigurierbar)
• Offline-Script (global und nur wenn die DS herunterfährt)
• Offline-IP (global und nur für Offline-Modus "mit eigener IP")
• Script nach Update (pro Host konfigurierbar)
• Gruppierung von Hosts mit gleichen Merkmalen (z.B. Login, IP) vor dem Update, minimiert Traffic und erhöht Geschwindigkeit (pro Anbieter konfigurierbar)
• konfigurierbare Anbieter
• konfigurierbare Protokolle
• konfigurierbare Url-Parameter (pro Protokoll)
• konfigurierbare Rückmeldecodes (für alle Protokolle)
• konfigurierbare IP-Überprüfungsaddressen und Ausschlussmuster (für alle Anbieter)
• IPv6 Unterstützung (DS Lite und Dual Stack)
• Auswahl der IP-Überprüfungsmethode (DSM intern oder extern über IP-Überprüfungsaddressen)
• Import/Export von Anbieten, Protokollen, IP-Überprüfungsaddressen und Rückmeldecodes oder Alles als Backup (ungepackt bei einzelnen Exports, gepackt als *.tgz bei Backup)
• Import der DDNS Updater 1.xx Konfiguration (ungepackt)
• Paketerstellung bestehend aus Anbietern, Protokollen, Rückgabecodes und IP-Überprüfungsurls zur Sicherung oder Weitergabe
• Sicherung und Wiederherstellung der Konfiguration über DSM Datensicherung & Replikation
• Einrichtungsassistent für Analyse einer Aktualisierungsurl, sowie das Hinzufügen von neuen Anbietern und Protokollen mit anschliessendem Test des möglichen Moduls

Die meisten Funktionen sind selbsterklärend oder werden in den entsprechenden Dialogen näher erläutert. Mehr Informationen über die Bedienung wird es demnächst im Thread DDNS Updater 2.xx: Anleitung - Instructions und auch als Online-Hilfe geben. Trotzdem existieren einige Dinge die ich explizit hervorheben möchte.

Nach dem ersten Start gibt es 2 Szenarien:

• kein DDNS Updater 1.xx installiert, "Einstellungen - Allgemein" bezüglich IP-Überprüfungsmethode und IP-System muss unbedingt konfiguriert und gesichert werden
• DDNS Updater 1.xx installiert, wird automatisch erkannt, per Migrationsassistent lässt sich die alte Konfiguration übernehmen, anschliessend muss unter "Einstellungen - Allgemein" bezüglich IP-Überprüfungsmethode und IP-System ebenfalls unbedingt konfiguriert und gesichert werden

Wird "Einstellungen - Allgemein" nicht durchgeführt und gesichert lassen sich keine Hosts anlegen oder bearbeiten, bei jedem Start erscheint der Dialog "Einstellungen - Allgemein" erneut.

Bei den folgenden Anbietern haben sich die benutzten Felder gegenüber dem DDNS Updater 1.xx verändert, speziell die Felder Hostname/Domain:

cloudflare, duckdns, easydns, einsweb, gratisdns.dk, kontent, namecheap, regfish, zoneedit​

Die Hosts welche einen der oben genannten Anbieter verwenden sollten unbedingt nach Übernahme der alten Konfiguration überprüft werden, generell kann es aber nicht schaden, wenn alle übernommen Hosts einer Prüfung unterzogen werden. Auch müssen die übernommen Hosts erst aktiviert werden, damit eine Aktualisierung durchgeführt werden kann. Dies kann für einen/alle Hosts per Drag & Drop auf die Gruppe "Aktiv", sowie auch für einzelne Hosts im Dialog "Bearbeiten" durchgeführt werden.

Noch kurz etwas zu den oben erwähnten Modulen:
Am Anfang hatte ich vor, neu geschriebene Module zusammen mit den Anbieter- und Protokolleinstellungen in eine Datei zu exportieren. Damit hätte man per Community leicht neue Anbieter/Protokolle anbieten können, auch wenn die eingebauten Module das Protokoll nicht verstehen. Da dies für mich eine grosse Sicherheitslücke darstellt (jemand mit böswilliger Absicht könnte ein Schadprogramm als Modul tarnen und anbieten), welche ich mit einfachen Mitteln nicht schliessen kann, habe ich mich dagegen entschlossen. Es wird in Zukunft bestimmt das eine oder andere Update in Form von neuen Modulen und Anbietern/Protokollen von mir geben. Wer ein Modul selbst schreiben möchte, findet im Verzeichnis "/var/packages/ddnsupdater2/target/lib/DDNSUpdater/Module" eine Datei #example.pm, welche einige Informationen bezüglich der Erstellung, Einrichtung und Test eines Moduls beinhalten.
Nach Test und Fertigstellung kann man mich per Forum oder per PM kontaktieren, ich werde das Modul dann nach positiver Prüfung für die nächste Version einbauen. Mehr Informationen folgen dann im Thread DDNS-Updater-2-Neue-Anbieter-und-Protokolle-new-provider-and-protocols.

Debug-Mode aktivieren:
Hier kurz die Schritte, damit ihr mir im Falle eines Problems das debug.log erzeugen könnt.

1. DDNS Updater stoppen
2. In "Einstellungen - Allgemein" das "Debug-Log" aktivieren (mit dem aktivieren wird ein vorhandenes debug.log gelöscht!)
3. DDNS Updater starten
4. Aktionen durchführen welche zum Fehler führen (wenn nicht das Update selbst)
5. DDNS Updater stoppen
6. In "Einstellungen - Allgemein" den Button "Download" anwählen und das debug.log sichern, anschließend das "Debug-Log" deaktivieren.

Was noch nicht bzw. nur unzufrieden funktioniert oder noch nicht existiert:

• Automatische Aktualisierung der Anzeige nach Update funktioniert manchmal nicht zeitnah (teilweise verbessert in 2.0-127)
• Anonymisierung der debug.log wird noch nicht 100% durchgeführt, bitte beim Post eines debug.log's daran denken, die Datei zu untersuchen und ggf. noch Passagen manuell anymisieren.
• Modultest Assistent bricht bei Fehlern ab, das ist so gewollt, aber die Erstellung des Protokolls kann nicht fortgesetzt werden. Hier fehlt die Möglichkeit dies dennoch zu übernehmen (wenn man weiss was man tut) (mit 2.0-137)
• IPv6 (DS Lite und Dual Stack) konnte ich nicht testen, da müssen mir die Benutzer mit IPv6 bitte weiterhelfen/testen
• Offline-Script noch nicht möglich (mit 2.0-133)
• Script nach Update noch nicht möglich (mit 2.0-133)
• Online-Hilfe

Nun viel Spass beim Testen und wie immer...Alles auf eigenes Risiko!

 

[tomtom00]

Vielen Dank für Deine Arbeit!!

Ich werde, sobald ich Zeit dafür habe und bei meinem Bruder bin, das ganze mal mit DS Lite zu testen.

Weißt du zufällig wie das mit dem Anbieter inwx.de aussieht? Ich habe dort meine Domains liegen und soweit ich weiß haben die auch eine API für DDNS.

 

[QTip]

Weißt du zufällig wie das mit dem Anbieter inwx.de aussieht? Ich habe dort meine Domains liegen und soweit ich weiß haben die auch eine API für DDNS.

Den habe ich zwar auf meiner ToDo-Liste, aber allerdings noch nicht eingebaut. Wenn es mit den eingebauten Modulen funktioniert, dann kannst du es selbst einbauen

 

[MMD*]

Hallo QTip,

Welche files muss man bearbeiten um völlig zu übersetzen nach Niederländisch?
Dan werde ich mich das die nächste tagen mal anschauen.

 

[QTip]

Hallo QTip,

Welche files muss man bearbeiten um völlig zu übersetzen nach Niederländisch?
Dan werde ich mich das die nächste tagen mal anschauen.

Schau in /var/packages/ddnsupdater2/target/app/texts dort existieren für jede Sprache ein Ordner mit 2 Dateien drin. Am einfachsten wäre es, wenn du einen von den vorhandenen Ordnern kopierst und dann als nld umbenennst. Der DDNS Updater erkennt beim Start ob die eingestellte Sprache existiert und schaltet bei fehlender Sprache auf englisch um.

Sobald ich deine Dateien erhalten habe, werde ich sie bei mir einspielen und einen kurzen Test durchführen (sicher ist sicher ). Ist Alles ok, dann wird es schnellstmöglichst ein neue Version geben.
Ist eine Menge Text zu übersetzen, ca. 600 Zeilen.


Vielen Dank für deine Unterstützung!

 

[Tensai]

Ich habe mich in dieser Zeit oft gefragt, ob es zu Zeiten von DSM 5++ und dem eingebautem DDNS Client noch Sinn macht, einen weiteren 3rdparty DDNS Client zu entwickeln.

Oh ja, macht es sehr wohl! Denn der interne DDNS Client der DS kann immer noch nicht mit Wildcard-Domänen umgehen bzw. akzeptiert kein "*"-Zeichen. Und ausserdem ist auch die Auswahl an Diensten beschränkt.
Daher bin ich Dir für Deine Arbeit äusserst dankbar. Der DDNS Updater 2 funktioniert bei mir mit ZoneEdit.com und einer Wildcard-Domäne ausgezeichnet! Version 1 wurde umgehend deinstalliert

Keep on going!

Tensai

 

[QTip]

Oh, endlich mal eine Rückmeldung, dachte schon das noch eine Version niemand gebrauchen kann. Das mit den Wildcard-Domänen beim internen DDNS wird aber nur eine Frage der Zeit sein, denke ich mal. Danke für dein Feedback.

 

[Tensai]

Hallo QTip

Noch ein kleines Feedback zum ZoneEdit1 Protokoll.
Ich habe den Parameter "host" gelöscht, da es überflüssig ist, sowohl "zones" als auch "host" anzugeben. Die Parameter "zones" und "host" funktionieren absolut äquivalent und die Angabe von einem der beiden Parameter reicht völlig. Werden beide Parameter angegeben, wird "host" ignoriert.
Die korrekte URL für ZoneEdit lautet somit eigentlich (optionale Angaben in eckigen Klammern []):

http://usernameassword@dynamic.zoneedit.com/auth/dynamic.html?zones=domain1.com[,domain2.com][,*.domain1.com][,*.domain2.com]&dnsto=ip

oder

http://usernameassword@dynamic.zoneedit.com/auth/dynamic.html?host=domain1.com[,domain2.com][,*.domain1.com][,*.domain2.com]&dnsto=ip

Grüsse, Tensai

 

[saruman]

Ich habe mich in dieser Zeit oft gefragt, ob es zu Zeiten von DSM 5++ und dem eingebautem DDNS Client noch Sinn macht, einen weiteren 3rdparty DDNS Client zu entwickeln.

In meinen Augen unbedingt. Ich werde den, sobald die DS neu aufgesetzt und mit frischen HDDs versehen wurde, definitiv einbauen. Ich habe mehrere Domains bei Regfish die ich updaten möchte. Mit der FritzBox geht das nur unzulänglich - und dann auch nur mit einer einzigen Domain und halb gekrückt. Freue mich also schon drauf das demnächst von der DS erledigen zu lassen!

Noch eine Frage:

• Gruppierung von Hosts per selbst zu erstellender Gruppen
• Script nach Update (pro Host konfigurierbar)
• Gruppierung von Hosts mit gleichen Merkmalen (z.B. Login, IP) vor dem Update, minimiert Traffic und erhöht Geschwindigkeit (pro Anbieter konfigurierbar)

Ist es möglich ein externes Script auch bei Update einer Gruppe und nicht nur bei einzelnen Hosts anzustossen?

 

[QTip]

Noch eine Frage:Ist es möglich ein externes Script auch bei Update einer Gruppe und nicht nur bei einzelnen Hosts anzustossen?

Die Gruppierung der Hosts nach identischen Merkmalen vor dem Update wird automatisch durchgeführt, das ist keine Gruppe die man selber erstellen und dann aktualisieren kann.
Sagen wir mal, du hast mehrere Hosts mit gleichen Merkmalen bei einem Anbieter, dann werden alle Hosts durch diese Gruppierung mit einem Mal aktualisiert. Du könntest dann bei einem Host ein Script nach Update ausführen lassen, da eh alle Hosts aktualisiert wurden. Der Anbieter muss die Gruppierung natürlich unterstützen und in der Anbieterverwaltung müssen die Merkmale zur Gruppierung konfiguriert sein.

Zur Zeit ist die Funktion "Script nach Update" noch nicht verfügbar.

 

[QTip]

Die korrekte URL für ZoneEdit lautet somit eigentlich (optionale Angaben in eckigen Klammern []):

http://usernameassword@dynamic.zoneedit.com/auth/dynamic.html?zones=domain1.com[,domain2.com][,*.domain1.com][,*.domain2.com]&dnsto=ip

oder

http://usernameassword@dynamic.zoneedit.com/auth/dynamic.html?host=domain1.com[,domain2.com][,*.domain1.com][,*.domain2.com]&dnsto=ip

Grüsse, Tensai

OK, danke, werde es bei mir ebenfalls machen, damit ein Update von mir dies nicht wieder überschreibt.

 

[saruman]

So, hab das jetzt installiert und muss sagen: Tut prima. Gefällt! Da sag ich mal: Dankeschön!

Allerdings ist mir aufgefallen dass man keinen IPv6 FQDN anlegen kann, wenn es den schon als IPv4 Host gibt. Innerhalb der beiden Methoden ist das sicher richtig, allerdings darf ein- und derselbe Hostname sowohl einen A als auch einen AAAA Record haben. Sprich: Sowohl eine IPv4 als auch eine v6 Adresse.

Wenn mal Zeit ist...

Ist das mitgeführte Log eigentlich ein eigenes, wird das irgendwann gelöscht oder rotiert?

 

[QTip]

So, hab das jetzt installiert und muss sagen: Tut prima. Gefällt! Da sag ich mal: Dankeschön!

Allerdings ist mir aufgefallen dass man keinen IPv6 FQDN anlegen kann, wenn es den schon als IPv4 Host gibt. Innerhalb der beiden Methoden ist das sicher richtig, allerdings darf ein- und derselbe Hostname sowohl einen A als auch einen AAAA Record haben. Sprich: Sowohl eine IPv4 als auch eine v6 Adresse.

Da ich kein IPv6 besitze, war mir dies nicht bewußt, werde mir dazu mal was einfallen lassen. Es ist ja nicht bei allen Anbieter möglich IPv6 zu benutzen, von daher könnte man beim anlegen schauen, ob der Anbieter dies unterstützt und dann eine Ausnahme für diesen Host aktivieren, also 2x anlegbar.
Funktioniert denn IPV6 im DDNS Updater 2 bei dir zufriedenstellend bzw. klappt das Update? Welche Variante zur Erkennung der IP benutzt du , intern oder extern?

Ist das mitgeführte Log eigentlich ein eigenes, wird das irgendwann gelöscht oder rotiert?

Wird per DSM syslog-ng in eine eigene Datei /var/log/ddud.log geschrieben und rotiert (max. 5 Archive). D.h. nach 5MB sind die alten Meldungen nur noch per Konsole im angegebenen Pfad in einer Datei ddud.log.(x).xz einsehbar.

Danke für dein Feedback

 

[saruman]

Da ich kein IPv6 besitze, war mir dies nicht bewußt, werde mir dazu mal was einfallen lassen. Es ist ja nicht bei allen Anbieter möglich IPv6 zu benutzen, von daher könnte man beim anlegen schauen, ob der Anbieter dies unterstützt und dann eine Ausnahme für diesen Host aktivieren, also 2x anlegbar.

Ja, entweder so oder generell das Anlegen eines IPv4/6 Eintrags erlauben. Denn wenn der Anbieter kein IPv6 unterstützt gibt es auch keinen Updater dafür und es kann kein IPv6 Eintrag im DDNS Updater 2 erfolgen. Dann muss der Check nur noch innerhalb von IPv4, bzw. IPv6 ausgeführt werden.

Funktioniert denn IPV6 im DDNS Updater 2 bei dir zufriedenstellend bzw. klappt das Update? Welche Variante zur Erkennung der IP benutzt du , intern oder extern?

Ja, das Update funktioniert. Extern, wobei das bei IPv6 aber keinen Unterschied macht weil es ja keine NAT mehr gibt. Hier muss man also mittels externem Script seinen Router abfragen. Oder man setzt halt ganz bewusst die IPv6 Adresse der DS.

Danke für dein Feedback

Da nicht für, ich mach ja nix. Der Dank geht an Dich!

 

[QTip]

Ja, entweder so oder generell das Anlegen eines IPv4/6 Eintrags erlauben. Denn wenn der Anbieter kein IPv6 unterstützt gibt es auch keinen Updater dafür und es kann kein IPv6 Eintrag im DDNS Updater 2 erfolgen. Dann muss der Check nur noch innerhalb von IPv4, bzw. IPv6 ausgeführt werden.

Da ist aber ein Problem, denn nicht jeder Anbieter mit IPv6 hat auch eine eigenes Url-Tag zum Angeben der IPv6 IP. Wenn ich nun für jeden Host ein IPv4- und ein IPv6 Feld bereitstelle, dann kann ich das natürlich nicht zuordnen. Des weiteren beisst sich das System mit 2 gleichen Hosts ebenfalls mit der umgesetzten internen Struktur, besonders im Daemon und speziell das Gruppieren der Hosts vor der Aktualisierung. 2 gleiche Hostnamen so sind nicht möglich, ausserdem werden die Hosts zur eindeutigen Identifizierung benutzt; in der Konfiguration wie auch für den Status, denn dort muss ich das eindeutig dem entsprechenden Host zuweisen.
Am besten wäre es, die Begrenzung bezgl. der Hosts fallen zu lassen und dem User das mehrfache Anlegen entscheiden lassen. Dann muss ich mir nur noch für das interne Problem etwas überlegen. Wenn ich da etwas umstrukturiere, dann müssen alle Hosts nach der Update vom DDNS Updater neu aktualisiert werden, da der Status so nicht mehr existiert. Da werden die User aber nicht froh drüber sein, zumal nicht jeder User das Wieso und Warum kennt.

Ja, das Update funktioniert. Extern, wobei das bei IPv6 aber keinen Unterschied macht weil es ja keine NAT mehr gibt. Hier muss man also mittels externem Script seinen Router abfragen. Oder man setzt halt ganz bewusst die IPv6 Adresse der DS.

Wieso muss man mit einem extra Script den Router abfragen, dafür gibt es doch schon die Methoden intern und extern. Beide sollten die korrekte IPv4 und wenn notwendig, IPV6 liefern, deswegen fragte ich.

 

[saruman]

Da werden die User aber nicht froh drüber sein, zumal nicht jeder User das Wieso und Warum kennt.

Jap, irgendwas ist ja immer.

Wieso muss man mit einem extra Script den Router abfragen, dafür gibt es doch schon die Methoden intern und extern. Beide sollten die korrekte IPv4 und wenn notwendig, IPV6 liefern, deswegen fragte ich.

Nicht ganz. Bei IPv4 machst Du normalerweise NAT - außer Du vergibst öffentliche IP-Adressen hinter Deinem Router und routest das interne Subnetz nach außen. Dann musst Du allerdings auch erstmal einen Provider finden der das mitmacht. Für Heimnutzer findest Du da keinen. Also nutzt Du - auch um der Adressknappheit bei IPv4 Adressen vorzubeugen und aus Sicherheitsgründen - intern private, vom IANA im RFC 1597 bzw. RFC 1918 definierte Subnetze. Die berühmten 192.168.0.0/16 sind so welche, oder auch das 10.0.0.0/8. Da ein DNS-Eintrag für diese Adressen im öffentlich erreichbaren DNS keinen Sinn machen würde (diese Netze können mehrfach vergeben sein und werden - vereinfacht gesprochen - nicht ins Internet geroutet) machst Du da eine NAT drauf und kommst nach außen mit Deiner (öffentlichen) Routeradresse die Dir vom Provider zugewiesen wurde. Die externe Methode des DDNS Updaters nutzt genau diesen Mechanismus, nämlich die NAT.

IPv6 spannt jetzt aber einen so unglaublich großen Adressraum auf, dass man jedes Gerät, welches IP spricht, mit tausenden von Adressen ausstatten könnte. Damit ist die Notwendigkeit einer NAT nicht mehr gegeben - technisch wäre das möglich, macht aber keiner weils an sich Quatsch ist und weil es zudem das Ende-zu-Ende Prinzip (nur Endknoten sprechen direkt miteinander, die Knoten dazwischen sind nur für die Weiterleitung der Pakete verantwortlich) verletzt. Also haben alle Deine Geräte hinter Deinem Router ebenfalls öffentliche IPv6 Adressen. Macht der DDNS Updater jetzt einen Webcheck um seine IP zu ermitteln, so nutzt er seine öffentliche Adresse, der Router lässt ihn einfach so ohne eine NAT durch und *schwupps* meldet der Webdienst nicht mehr die Routeradresse zurück sondern die öffentliche IPv6 Adresse Deiner DiskStation. Das ist ja im Allgemeinen nicht das was man will. Denn genau genommen reisst IPv6 ein Security-Loch auf: Es können sich nun keine Endgeräte mehr hinter einer öffentlichen Adresse verstecken, so wie das bei IPv4 der Fall ist. Statt dessen steht jedes Gerät öffentlich im IPv6-Netz und wäre ohne Firewall aus dem Internet erreichbar. Deswegen: Firewall (sprich Firewall im IPv6-fähigen Router). Aber das nur am Rande.

Ich muss also, wenn ich den DDNS Updater auf der DS laufen lasse und möchte, dass der AAAA-Record mit der IP-Adresse des Routers versehen wird, ein externes Script abfahren welches die IP-Adresse des Routers (beispielsweise per SNMP) ausliest. Und genau die IP-Adresse muss die DS dann beim DNS-Provider setzen.

Insofern gibts da eh eine Grundsatzentscheidung für Dich zu treffen: Macht ein IPv6 Updater überhaupt Sinn? Ist eine NAT durch Einführung von IPv6 nicht generell so selten (es wird sicher noch irgendwo auf der Welt Leute geben die sich auch mit IPv6 noch eine NAT bauen) dass man einen IPv6 Updater eh nicht benötigt (weil er ohne NAT wie gesagt nur die IP-Adresse der DS zurückliefert)? Denn: Jetzt auch noch SNMP-Scripte in den DDNS Updater einzubauen macht m.E. keinen Sinn. Da gibts einfach zu viele verschiedene...

Und generell funktioniert die Adressvergabe bei IPv6 auch anders als bei IPv4. Bei IPv4 bekommt man seine Adresse ja dynamisch zugewiesen - ähnlich wie beim DHCP oder auch genau so, abhängig vom Provider. IPv6 hingegen wird - solange wir jetzt nicht vom professionellen Bereich ausgehen - in den seltensten Fällen statisch konfiguriert sonder bezieht seine Adresse mittels Stateless Adress Auto Configuration. Dabei wird eine Interface ID, z.B. die MAC-Adresse der Netzwerkkarte, gewählt um damit und dem vom Provider gepushten IPv6 Prefix eine Adresse zu bilden. Die bleibt im allgemeinen gleich (weder das Prefix ändert sich permanent, allerdings kann es das, noch ändert sich so ohne weiteres die Interface ID, also die MAC Adresse). Per SAAC konfigurierte IPv6 Interfaces haben also eh so gut wie immer ein- und dieselbe IP-Adresse. Ergo könnte man die IPv6 Adresse des Routers auch fest in das Zonenfile des DNS-Providers schreiben.

*puh* Sehe grad, ist lang geworden. Hoffe ich hab nicht gelangweilt...

 

[QTip]

Ich muss also, wenn ich den DDNS Updater auf der DS laufen lasse und möchte, dass der AAAA-Record mit der IP-Adresse des Routers versehen wird, ein externes Script abfahren welches die IP-Adresse des Routers (beispielsweise per SNMP) ausliest. Und genau die IP-Adresse muss die DS dann beim DNS-Provider setzen.

Wieso, ich möchte doch grad die IPv6 der DS benutzen um meinen DDNS Host zu aktualisieren, um z.B. eine Webseite zu hosten. Dann nützt mir die IP vom Router recht wenig, da doch jedes Gerät seine eigene IPv6 IP hat.

Insofern gibts da eh eine Grundsatzentscheidung für Dich zu treffen: Macht ein IPv6 Updater überhaupt Sinn? Ist eine NAT durch Einführung von IPv6 nicht generell so selten (es wird sicher noch irgendwo auf der Welt Leute geben die sich auch mit IPv6 noch eine NAT bauen) dass man einen IPv6 Updater eh nicht benötigt (weil er ohne NAT wie gesagt nur die IP-Adresse der DS zurückliefert)? Denn: Jetzt auch noch SNMP-Scripte in den DDNS Updater einzubauen macht m.E. keinen Sinn. Da gibts einfach zu viele verschiedene...

Ich werde IPv6 drin lassen, denn es wurde in der Vergangenheit mehrfach danach gefragt. Die User müssen es ja nicht benutzen und nein, ich werde keine SNMP-Anfrage einbauen.

*puh* Sehe grad, ist lang geworden. Hoffe ich hab nicht gelangweilt...

Boah, na das war ja mal eine Lektüre vor dem Einschlafen, danke für deine Ausführungen. Wie ich schon schrieb, habe ich null praktische Erfahrungen mit IPv6, werde mir aber evtl. rein zu Test- und Versuchszwecken welche besorgen

btw: Ich bin grad dabei, von unique Hosts auf unique ID's umzustellen, dann ist die Anzahl der gleichen Hosts egal und der User muss selbst darauf achten, welche Hosts schon existieren.

 

[Frogman]

...Also haben alle Deine Geräte hinter Deinem Router ebenfalls öffentliche IPv6 Adressen. Macht der DDNS Updater jetzt einen Webcheck um seine IP zu ermitteln, so nutzt er seine öffentliche Adresse, der Router lässt ihn einfach so ohne eine NAT durch und *schwupps* meldet der Webdienst nicht mehr die Routeradresse zurück sondern die öffentliche IPv6 Adresse Deiner DiskStation. Das ist ja im Allgemeinen nicht das was man will. Denn genau genommen reisst IPv6 ein Security-Loch auf: Es können sich nun keine Endgeräte mehr hinter einer öffentlichen Adresse verstecken, so wie das bei IPv4 der Fall ist. Statt dessen steht jedes Gerät öffentlich im IPv6-Netz und wäre ohne Firewall aus dem Internet erreichbar. Deswegen: Firewall (sprich Firewall im IPv6-fähigen Router)...

Hier wäre aber noch etwas weiter zu differenzieren. Ein Gerät hat ja nicht per se die eine öffentliche IPv6, wenn IPv6 aktiviert ist. Zunächst gibt es nur lokale Adressen, mindestens die per SLAAC generierte Adresse mit dem Prefix fe80:: und dem aus der MAC abgeleiteten Interface Identifier. Falls konfiguriert, kann ein DHCPv6 auch noch weitere lokale IPv6 verteilen - die unique local adresses (auch wenn diese in der Auflistung mit ifconfig als global bezeichnet sind, werden sie nur im lokalen Subnet geroutet). Per SLAAC gibt es dann unter Umständen noch eine weitere IPv6, die auch global gilt - dieses allerdings nur dann, wenn der DHCPv6 per Router Advertisement (IA_PD) das vom Provider zugeteilte Subnet im LAN bekannt gibt. Diese besteht dann aus dem Subnet-Prefix und dem aus der MAC abgeleiteten Interface Identifier.
Daneben kann es auch noch weitere öffentliche IPv6 geben, bspw. per DHCPv6 (IA_NA) zugeteilte Adressen aus dem zugeteilten Subnet oder auch eine mit einem selbst fest definierten Interface Identifier. Sind die privacy extensions aktiviert, werden auch noch weitere globale und ULA-IPv6 generiert, die aber nur temporär verwendet werden (bestehend aus dem Subnet-Prefix (für globale Adressen) bzw. dem ULA-Prefix (für lokale Adressen) plus einem zufäligen Interface Identifiern) und eine konfigurierbare Lebensdauer haben. Diese werden dann übrigens auch bei externen Zugriffen wie zB. Webchecks verwendet - und die stellen per se erst einmal keine Gefahr dar, weil ungefragte externe Zugriffe darauf i.d.R. durch die Firewall abgefangen werden (man muss gewöhnlich jede IPv6 explizit für einen Port freischalten).
Ob und welche Adresse man nun auf eine DDNS abbilden möchte, hängt von den Vorstellungen ab - eine feste IPv6 wäre aber eine Möglichkeit, alleine schon wegen der Öffnung einer Router-Firewall.

...
Ich muss also, wenn ich den DDNS Updater auf der DS laufen lasse und möchte, dass der AAAA-Record mit der IP-Adresse des Routers versehen wird, ein externes Script abfahren welches die IP-Adresse des Routers (beispielsweise per SNMP) ausliest. Und genau die IP-Adresse muss die DS dann beim DNS-Provider setzen.

Warum das? Ich will doch in der Regel meinen Server erreichen und nicht meinen Router.

 

[QTip]

@saruman: Irgendwie reden wir aneinander vorbei. Was möchtest du laufend mit der Router-IP, wenn ich doch den DDNS für meine DS benötige, welche ja eine eigene IP, von meinen vielen IPv6, besitzt?

 

[saruman]

Wieso, ich möchte doch grad die IPv6 der DS benutzen um meinen DDNS Host zu aktualisieren, um z.B. eine Webseite zu hosten. Dann nützt mir die IP vom Router recht wenig, da doch jedes Gerät seine eigene IPv6 IP hat.

Hehe, unterschiedliches Szenario. Ich zum Beispiel möchte lediglich meine Routeradresse als AAAA-Record hinterlegen. Ich hoste auf meiner DS keine öffentlich erreichbaren Dienste, dafür liegen mir da zu viele private Daten drauf. Und wenn doch, löse ich das über ein Portforwarding. Ist ähnlich dämlich wie eine NAT, aber meine DS als exposed host ins Netz zu stellen... Nee... (Paranioa, quasi).

Ich werde IPv6 drin lassen, denn es wurde in der Vergangenheit mehrfach danach gefragt. Die User müssen es ja nicht benutzen und nein, ich werde keine SNMP-Anfrage einbauen.

Joa, wie gesagt: Unterschiedliche Anwendungsszenarien halt. Ich bin heute Nacht auch nicht mehr auf die Idee gekommen dass jemand seine DS wirklich ins Netz hängen möchte. Da machts natürlich Sinn.

[...] werde mir aber evtl. rein zu Test- und Versuchszwecken welche besorgen

Ich empfehle SixXS.

btw: Ich bin grad dabei, von unique Hosts auf unique ID's umzustellen, dann ist die Anzahl der gleichen Hosts egal und der User muss selbst darauf achten, welche Hosts schon existieren.

Jo, so gehts natürlich auch.

@saruman: Irgendwie reden wir aneinander vorbei. Was möchtest du laufend mit der Router-IP, wenn ich doch den DDNS für meine DS benötige, welche ja eine eigene IP, von meinen vielen IPv6, besitzt?

Wie gesagt: Unterschiedliche Szenarien. Dazu war ich beim Schreiben des Romans wohl doch müder als gedacht und habs einfach nicht gepeilt (siehe oben). Alles gut so.