[HowTo] Fritz!Box/DynDNS/IPv6 und mehrere Domains

[bernd.stromberg]

Tag zusammen,

habe ewig nach Lösungen gesucht o. g. Problem elegant zu lösen. Nun habe ich in der Kombination mit einem Debian Server (mit fünf öffentlichen Domains) und ddclient eine Möglichkeit gefunden eine für mich akzeptable Umgebung zu gestalten.

Den Weg möchte ich nicht vorenthalten.

Da ich hier nicht die Formatierungsmöglichkeiten für das How-To finde, wie ich möchte, erlaube ich auf einen externen Link zu verweisen...

...nämlich DIESEN hier !

Zusammengefasst tragen wir eine Benutzerdefinierte URL zum DynDNS-Update in der Box ein, den Rest erledigt auf dem Linux der ddclient. Die Fritz!Box veröffentlicht ebenso eine aktuelle IPv6-Adresse, die uns zugewiesen wird (z. B. nach jeder Zwangstrennung). Die restlichen vier Domains werden von Linux aus an DynDNS geschickt.

Der Ansatz beinhaltet eine Benachrichtigung per eMail, falls etwas schief geht und eine Lösung für die Fehlermeldung

[COLOR=#000000][FONT=monospace]Dynamic DNS-Fehler: Die Dynamic DNS-Aktualisierung wird bis zur Änderung der Dynamic DNS-Anmeldedaten deaktiviert.
[/FONT][/COLOR][COLOR=#000000][FONT=monospace]Dynamic DNS-Fehler: Der DynDNS-Anbieter meldet Fehler 500 - badauth[/FONT][/COLOR]

Ich hoffe es nützt Anderen,

Gruss aus Düsseldorf...

 

[thtomate12]

Wegen der Formatierung, die total bescheiden ist, musst du es auf deiner Webseite hosten?
Kannst du keinen richtigen Server betreiben oder warum musst du die Webseite hinter eine DynDNS-Domain hosten?

 

[bernd.stromberg]

Wegen der Formatierung, die total bescheiden ist, musst du es auf deiner Webseite hosten?

Rischtischhhhhh.

Kannst du keinen richtigen Server betreiben oder warum musst du die Webseite hinter eine DynDNS-Domain hosten?

Der "unrichtige" Server steht in meiner Abstellkammer und macht noch ein bisschen mehr als ein paar Seiten bereitstellen, verstehst Du ?! Wenn man soetwas betreibt, dann greift man zu einem DynDNS-Dienst, verstehst Du ?!

Einen gesegneten ersten Advent...

...Rainer [LPI 302].

 

[PeterPawn]

Die Lösung mit dem Editieren der ar7.cfg dürfte nach wie vor der sinnvollere Ansatz sein, der auch die bessere Fehlerbehandlung bietet - eine solche ist ja hier gar nicht zu finden bzw. nicht zu erkennen.

Solange man sich in der eigenen ar7.cfg mehrere Services definiert, versucht das FRITZ!OS die auch alle gesondert zu aktualisieren. Schlägt dann bei einem von ihnen aus irgendeinem Grund die Aktualisierung im ersten Anlauf fehl, wiederholt der DynDNS-Client der Box (ddnsd) gezielt diese eine Aktualisierung - bis sie halt erfolgreich war. Das hat in bestimmten Szenarien auch Nachteile (bei kaskadierten Routern, wo die öffentliche IP-Adresse nicht mit der übereinstimmt, welche die Box an den DynDNS-Service meldet), trotzdem funktioniert das garantiert wesentlich besser - zumindest dann, wenn das unter dem Link gezeigte Beispiel die gesamte Lösung sein sollte.

Ich weiß ja nicht, was bei

habe ewig nach Lösungen gesucht o. g. Problem elegant zu lösen.

alles an "uneleganten" Lösungen in Erwägung gezogen wurde, aber solange das öffentliche IP-Adressen sind, geht es fast nicht mehr eleganter als direkt in der FRITZ!Box - zumindest würde ich angesichts des Gezeigten die Lösung von AVM (auch wenn über das GUI nur ein Account zu verwalten ist, in der ar7.cfg sind weitere kein Problem) tatsächlich für eleganter und weniger fehleranfällig halten.

Zusätzlich funktioniert die dann auch noch mit verschiedenen Anbietern - zwar kann das "ddclient" ebenfalls, aber für ein "HowTo" fehlt da eben noch jede Menge an Erklärungen und irgendwie wird man den Verdacht nicht los, daß der TE unter "DynDNS" nur den (kostenpflichtigen) Dienst (des inzwischen von Oracle gekauften) dyn.com versteht. Irgendwie erwartet man halt bei einer Ankündigung eines "HowTo" schon etwas anderes ... vielleicht geht das aber auch nur mir so. Solche Lösungen mit einem "Proxy" hatten wir aber auch schon oft genug - sogar unter Nutzung von Webspace, wo Perl oder PHP benutzbar waren. Da geht zwar vielleicht nicht immer "ddclient", aber das ist am Ende auch nur Perl und läßt sich auch so anpassen, daß es nicht unbedingt als Daemon laufen muß.

Eine weitere Beschränkung hier ist ja auch die Notwendigkeit, daß der "Update-Server" in jedem Falle auch unter der jeweils zu aktualisierenden Adresse laufen muß (die eigene aktuelle Adresse wird ja über einen HTTP-Request ermittelt) - eine "fremde Aktualisierung" ist hier gar nicht vorgesehen (braucht eine andere Kontrolle der IP im ddclient).

Die (als "worst case") 10 Minuten bis zur Aktualisierung weiterer Adressen sind da nur noch die Kirsche auf dem Sahnehäubchen ... irgendwie wirkt das Ganze so, als wäre es eine Lösung für einen ganz speziellen "use case" (ein einzelner Anbieter - dyn.com - mit mehreren zu aktualisierenden FQDN) und weniger wie eine "allgemeine Lösung".

Wer also nicht wirklich exakt dieselben Voraussetzungen hat (eigener Server für Aktualisierung hinter dem betroffenen Anschluß, 10 Minuten (Ausfall-)Zeit im schlechtesten Fall beim Update akzeptabel, ein einzelner Provider für mehrere DynDNS-Adressen), der baut sich das doch besser in die ar7.cfg ein. Das kostet zwar ein wenig Schreibarbeit, bildet damit aber die bei vielen ja eher erwartete/gewünschte Redundanz der DynDNS-Adressierung über mehr als einen Provider (zur Eliminierung des SPOF) wesentlich besser ab und aktualisiert andere Accounts auch noch dann, wenn ein Update bei einem Provider mal fehlschlagen sollte.

Wobei ich den ganzen Aufwand bei der gezeigten Konfiguration ohnehin nicht verstehe, wenn es um einen einzelnen Provider geht. Da wären ja passende CNAME-Einträge für die zusätzlichen Namen, die auf den ersten verweisen, vollkommen ausreichend ... wenn der DynDNS-Anbieter hier der SPOF ist und der ausfällt, bringt es ja auch nichts, die anderen Namen aktualisieren zu wollen - und mit einem CNAME-Eintrag ist dann auch wieder die "update gap" nicht mehr vorhanden.

Wer also vor ähnlichen Aufgaben steht, sollte das vielleicht noch einmal genauer durchdenken, was er eigentlich erreichen will ... die hier gezeigte Lösung hat (meine Meinung) schon erhebliche Schwachstellen.

Ach so ... falls sich jemand von der verlinkten Seite irritieren lassen sollte: Die 7370 ist mit hoher Wahrscheinlichkeit auch nur ein weiterer Fehler - es wäre m.W. die erste Box mit dieser Modellnummer, die hier gesichtet wurde und wo es sich nicht um einen Schreibfehler handelt.

 

[sparkie]

Kannst du keinen richtigen Server betreiben oder warum musst du die Webseite hinter eine DynDNS-Domain hosten?

verstehe ich auch nicht.

Wenn er einen *richtigen* Server betreiben wuerde, dann haette dieser eine statische IP und einen vernueftigen DNS Eintrag.

Dann koennte er ueber Reverse-Tunnel beliebige Rechner daran registrieren und wuerde so jede Kiste (z.B. sogar hinter Proxies aus Mobilfunknetzen) aus dem Internet zugreifbar machen.

Und den dyndns & Co Mist koennte er sich damit auch gleich noch sparen