Problem, DDNS-Updater: DOMAIN oder DOMAIN_KEY falsch?

IPv64.net - Services API & Apps
61

N’Abend,

ich verstehe schon und mir ist auch bewusst, dass die FritzBox nicht das perfekte Gerät für spezielle Belange ist. Ich finde, sie ist aber ein guter Kompromiss für den Heimanwender und vergleicht man sie mit den Routern, die manch DSL-Anbieter ihren Kunden anbietet (um nicht zu sagen antut), ist sie schon eine Liga höher.

Deine Architektur mit pfsens, VLAN & Co. ist allerdings nochmal ein paar Ebenen weiter oben zu finden. Schon eine feine Sache. Das aber mit einer FritzBox zu vergleichen, ist ein wenig wie einen Panzer mit einer Pistole zu vergleichen.

Du könntest deine Verbesserungswünsche ja mal an AVM zurückspiegeln. Die sind da eigentlich immer recht offen für und je mehr Kunden es sich wünschen, umso wahrscheinlicher ist es, dass sie es auch umsetzen.

Bei dem Thema mit dem Zugriff auf die WebGUI muss ich dir leider widersprechen. Es ist in der Tat möglich über einen IPV64.net Domain auf die WebGUI der FritzBox zuzugreifen, auch wenn der Fernzugriff darin deaktiviert ist. Ich weiß nicht, ob das von AVM gewollt ist oder nicht aber als ich den kompletten Update-Link von IPV64.net in der FritzBox eingetragen hatte, hatte ich genau diesen Effekt. Ich konnte über mein-domain.ipv64.net auf meine FritzBox zugreifen. Die Fehlermeldung, dass ich über eine HTTPS-Verbindung auf eine HTTP-Ressource zugreifen möchte, war schnell weggeklickt. Für mich war/ist das noch ein Grund das DynDNS-Feature der FritzBox lieber nicht zu nutzen. Der Fernzugriff ist und bleibt bei mir auch aus.

Und ja, ich sehe und verstehe, dass du einen ganz anderen Ansatz in deinem Netzwerk verfolgst. Wahrscheinlich nutzt du dein Setup sogar dienstlich und hostest darauf sensible (Kunden?)-Daten o.ä. Alles super. Alles fein. Aktuell aber für mich eine Nummer zu groß.

Ursprünglich wollte ich in meinem Netzwerk eigentlich gar nichts öffentlich verfügbar machen aber dann kann ich keine Dateien über meine NetxCloud mit Freunden austauschen, was deren Sinn irgendwie mindert. Also habe ich auch lange an meinen Konfigurationen, Firewall, Freigaben und ein paar Überwachungs-Skripten rumgeschraubt, bis das „Loch“, was ich in mein System bohren musste, möglichst minimal geworden ist.

Mit dem „Gleichen Gedanken“ wollte ich nur sagen, dass wir die ganze Zeit um IPv6, DynDNS-Update-Links, Präfixe und Suffixe im Kreis diskutiert haben, um irgendwie doch wieder beim gleichen Nenner rauszukommen.

Also schönen Sonntag.

Grüße
Mic.

62

Das sollte man nie können. Also nicht direkt. also per https://mein-domain.ipv64.net oder noch schlimmer http://mein-domain.ipv64.net. Wenn das bei dir direkt möglich ist oder war, dann ist / war das eine krasse Fehlkonfiguration.

Eine sauber konfigurierte Fritte ermöglicht das nur entweder

  • wenn man unter Internet → Freigaben den Internetzugriff auf die FRITZ!Box über HTTPS aktiviert hat oder
  • einer Anleitungen für den Zugriff über das MyFRITZ!Net auf die FRITZ!Box gefolgt ist.

Die Fritten, auf die ich Zugriff habe, erlauben das NICHT. Ich kann die zwar dennoch per Fernwartung administrieren, aber nur über den Umweg einer Wiregurad-Verbindung ins LAN der Fritte. Diese Fritten nutzen auch ipv64 mit der
Update URL: https://ipv64.net/nic/update?key=1234567890abcdefgh&ip=<ipaddr>&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>
Dennoch kommt man NICHT per WAN-IP oder FQDN auf die Anmeldeseite der Fritten.

63

Bemerkung dazu: Mir ist das auch mal passiert, als ich noch einen Fehler in der Konfiguration hatte. Ich landete beim Zugriff über die WAN-IP/FQDN auf der Anmeldung der Fritzbox.
Eine Nachfrage bei AVM ergab, dass dies so gewollte sei, aber nur, wenn man es von innen probiert, also über Loopback reinkommt. Warum das so gewollt ist, konnte man mir nicht sagen.
Hab’s dann richtig von außen probiert, da war das natürlich nicht so.

64

@Benares guter Hinweis. Ich bin natürlich davon ausgegangen, das @Mic2025 seine Test nicht aus dem LAN sondern z.B. dem Mobilfunknetz durchführt. Schon allein wegen des bei Fritten per default aktiven DNS-Rebind-Schutzes.

Aber vielleicht setze ich da etwas voraus, was ich nicht hätte voraussetzen dürfen :smiling_face_with_tear:

65

Ja, so war es auch bei mir wahrscheinlich auch. Ich war noch in meinem Heimnetz unterwegs. Das kann also der Grund gewesen sein. Es war ja kein echter Test, ob es geht oder nicht… eher ein Zufallsbefund, den ich so schnell wie möglich wieder korrigiert haben wollte.

66

Passt zwar nicht zum Thema aber ich habe wieder ein neues cooles Feature des IPV64.net Update-Links herausgefunden.

Ich habe meine NextCloud gestern auch in V-LAN „verbannt“ und war auf das Problem gestoßen, dass mein Skript ja nur die aktuelle IPv6 des (Host-)PCs, auf dem es läuft, an IPV64.net senden kann. Da der V-LAN aber eine eigene IPv6 hat, nützt mir das nichts. Kurz nachgeschaut… man kann (z.B. per Skript) auch einen Update-Link basteln, der eine bestimmte vorgegebene IPv6 an IPV64.net sendet. Also liest mein Skript nun die IPv6 des V-LAN aus und sendet diese direkt an IPV64.net. Das funktioniert bisher prima.

So sieht der Update-Link beispielhaft nun aus:

https://ipv64.net/nic/update?key=mykeymykeymykeymykeymykeymykey&ip6=2001:abcd:0123:dcba:1234:abcd:2345:dcba

Feine Sache!

Von AVM habe ich bisher noch keine Rückmeldung erhalten, ob Sie was ändern möchten. Die diskutieren sicher erst einmal eine Weile…