Eigener DynDNS Dienst

  • wieso dafür einen weiteren externen Dienst nutzen und nicht einfach im Netcup DNS ein cname auf die Fritz-Domain setzen?

    Vorteil der Weiterleitung ist wahrscheinlich, dass man ein gültiges Zertifikat bekommt, da die Fritzbox für ihre myfritz.net Subdomain ein Let's Encrypt Zertifikat zieht.
    Bei der CNAME-Variante muss man dann selber dafür sorgen, dass auf der Fritzbox ein gültiges Zertifikat installiert ist.
    Dazu habe ich mir übrigens mal ein PHP-Script geschrieben, was sich beim automatischen Erneuern des Zertifikats (Wildcard) auf meinem VPS zu allen Fritzboxen connected, die ich so verwalte, und dort das neue Zertifikat hochlädt.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Ja gut, auf der Adresse lauscht in meinem Fall zuhause ein nginx Proxy mit eigenem LE Zertifikat. Die Fritzbox-Adminoberfläche ist nur via lokalem Netz (und VPN) erreichbar. Je nach Anwendungsfall und Daten muss man eben selbst entscheiden welche Dienste man nutzt. :)

  • Danke für die Kommentare. Ich wollte allerdings eine Lösung ohne das ich Port 80 bei mir zuhause weiterleiten oder freigeben müsste zu dem Gerät auf dem ich die Zertifikate brauche (Node-RED-Instanz).

    Ich habe es jetzt anders, über die manuelle DNS-01 Challenge von LE gelöst:

    1. certbot installiert

    2. sudo certbot -d zuhause.domain.tld --manual --preferred-challenges dns certonly

    3. herauskommt das dns-challenge token und warten bis Schritt 6 komplett (certbot wartet selbständig auf "weiter")

    4. https://github.com/froonix/acme-dns-nc besorgt und für die netcup DNS api konfiguriert

    5. ./acme-dns-nc zuhause.domain.tld "<dns-challenge-token>"

    6. warten, wegen DNS-Aktualisierung (das ist natürlich nervig ...)

    7. certbot "Freigabe" erteilen (Fortsetzung Schritt 3)

    8. Zertifikate dort einbinden wo sie hinsollen

    9. Nicht vergessen mit " ./acme-dns-nc --del zuhause.domain.tld " den TXT-Eintrag wieder zu löschen (für das nächste mal)


    Mal gucken wie ich das besser automatisiert bekomme, aber zumindest bin ich erstmal glücklich ;)

  • Mal gucken wie ich das besser automatisiert bekomme, aber zumindest bin ich erstmal glücklich ;)

    Geht ohne Probleme automatisiert, mache ich auch so. Du kannst zumindest bei acme.sh mit --renew-hook "/opt/script/<dein_update_script>" arbeiten. So kannst nach jedem renew die Zertifikate automatisch irgendwo hochladen.


    Schaut bei mir so aus:


    Und halt dazu noch das Gegenpart auf dem jeweiligen Server, was eben passieren soll. Bei mir werden auf dem einen Server die Zertifikate noch in nen Docker Container kopiert, oder irgendwelche Container/nginx/etc neugestartet :)



    Edit: Da ich dort knapp 50 Domains für alle VPS/RS verwalte sind meine Scripte meist relativ allgemein ausgelegt. Du kannst natürlich auch die Angaben wie "server" oder "domain" direkt mit in das bashscript nehmen. Bei mir werden die halt auch noch mal weiter gereicht weil ich push notifications etc. bekomme.

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Eine Verständnisfrage:


    Ich richte derzeit auch meine FritzBox mit einem VPN-Zugang ein, der per DynDNS über meine Netcup-Adresse erreichbar sein soll. Ich hab das von dir verlinkte Script genutzt, haut auch soweit hin, unter subdomain.domain.tld/ip.html zeigt mir auch die public IP meiner FritzBox an. TTL habe ich auch mal auf 600 heruntergestellt und den A-Record ('subdomain' als host) so gesetzt wie von dir beschrieben (also mit 1.1.1.1 als Platzhalter bei Destination).


    Woher will der A-Record nun wissen, dass er die vom Script festgehaltene IP-Adresse nun nutzen soll? Ich verstehe an der Stelle nicht wo die "Schnittstelle" zwischen dem Github-Script und dem A-Record sein soll.


    Ich kann derzeit (zu Testzwecken halt) die VPN-Verbindung über die public IP meiner FritzBox nutzen. Läuft soweit. Über die hinterlegte Adresse meines A-Records halt noch nicht - zugegeben, ich habe das erst vor einer Stunde alles eingerichtet und warte erstmal brav meine 48 Stunden. Ping auf subdomain.domain.tld ('subdomain' ist entsprechend als A-Record hinterlegt) gibt zwar eine IP zurück, aber natürlich (noch?) nicht die meiner FritzBox. Die Frage ist aber dennoch offen.

  • Ok, Veriwrrung pur. Nach dem Einrichten stand ja unter meiner FritzBox bei VPN unter "Adresse im Internet" eine public IP. Diese deckte sich auch mit der Adresse, welche bei subdomain.domain.tld/ip.html angezeigt wurde, daher ging ich ja davon aus, dass die Übertragung immerhin funktioniert nicht hat.


    Dann war ich gestern etwas zu ungeduldig und wollte sehen, ob er auch eine neue public IP aktualisiert, also habe ich eine Zwangstrennung (mal die Fritze vom Strom genommen) vorgenommen. Seitdem waren all Dateien welche mit dem Script und unter subdomain.domain.tld/... liegen nicht mehr erreichbar (aka, hat u.a. subdomain.domain.tld/ip.html , aber auch .../data.json, etc. ein "Fehler: Netzwerk-Zeitüberschreitung" angezeigt).

    Hatte mir nicht fiel dabei gedacht und die Nacht jetzt abgewartet - immernoch nicht erreichbar. Wenn ich über das Netucp Dashboard reinschaue, sind aber Daten in data.json und ip.html, etc geschrieben (halt die von gestern, keine aktualisierten also).


    Also habe ich eebn bei der FritzBox geschaut und dort wo gestern unter "Adresse im Internet" eine public IP stand mit der ich auf die FritzBox kam, steht heute garnichts.

    Aktiv Name Adresse im Internet
    Virtuelle IP-Adresse
    meinName 192.168.178.XXX


    Bei meiner Recherche kam heraus

    Adresse im Internet: Bei aufgebauter VPN-Verbindung wird hier die öffentliche IPv4-Adresse der Gegenstelle angezeigt.


    Die public IP der GEGENstelle bei aufgebauter VPN-Verbindung? Bei mir war es die public IP meiner FritzBox, die immer angezeigt wurde (muss ja, sonst weiß ich ja nicht wohin ich mich verbinden möchte).

    Also muss irgendwas gestern beim Zwangstrennen schief gegangen sein. Ist aber alles so wie vorher.

  • Sorry für die drei Posts unereinander, aber ich habe es hinbekommen. Hier lag ein Denkfehler bei mir vor:


    Ich hatte bereits den A-Record mit Platzhaltern in meinem Netcup Dashboard gesetzt. Die update.php File wurde mit subdomain.domain.tld bei der FritzBox unter Update-URL aufgerufen. Als Domainname war ebenfalls subdomain.domain.tld. Da war es logisch, da meine FritzBox sich nicht anmelden konnte, wenn der A-Record auf 1.1.1.1 verweist. Hab jetzt die Scriptsammlung in domain.tld verschoben und entsprechend Update-URL in der FritzBox angepasst. Domainname habe ich gelassen. Nun ging es auch ruckzuck und der A-Record entspricht nun der aktuellen public IP meiner FritzBox.


    Schwere Geburt.

  • Hallo,


    ich habe das Script nach Anleitung eingerichtet und auch einen A-Record im Netcup CCP angelegt. Wenn ich das Script update.php in der Comandline auf meinem Server ausführe, erhalte ich folgende Fehlermeldung:


    Code
    Fatal error: Uncaught Error: Class 'SoapClient' not found in .../www/test/src/Soap.php:40
    Stack trace:
    #0 .../www/test/src/Soap.php(130): netcup\DNS\API\Soap\DomainWebserviceSoapClient::_Call('login', Array)
    #1 .../www/test/src/Handler.php(107): netcup\DNS\API\Soap\DomainWebserviceSoapClient->login('Kd-Nr', 'API-KEY...', 'API-PASSWORD...', '...')
    #2 .../www/test/update.php(20): netcup\DNS\API\Handler->doRun()
    #3 {main}
    thrown in .../www/test/src/Soap.php on line 40

    Kann mir jemand helfen? Woran liegt es?

  • nburgmann Dir fehlt das SOAP-Paket für PHP. Einfach nachinstallieren, dann sollte es laufen. Bei Debian/Ubuntu heißt das passenderweise php-soap.


    Oder PHP mit den richtigen Optionen neu kompilieren, falls es manuell installiert wurde. Siehe: https://www.php.net/manual/de/soap.installation.php

    Ah... großartig. Jetzt geht es ohne Fehler weiter. Vielen Dank. Ich meinte aber das Bash-Script natürlich (update-dyndns.sh).

    Komischer Weise übermittelt aber das Script an die API nur die IP meines vServers, nicht die meiner Fritzbox.


    Code
    [DEBUG] api login successful 
    [DEBUG] IPv4 for subdomain.meinedomain.tld set to 111.222.333.444 (<- IP meines vServers) 
    [DEBUG] dns recordset updated 
    [DEBUG] api logout successful

    EDIT 1:


    Offensichtlich läuft das Script update.php noch nicht sauber durch. Es wirft eine Exception:

    Code
    Fatal error: Uncaught RuntimeException: payload invalid in .../www/test/src/Handler.php:35
    Stack trace:
    #0 .../www/test/update.php(20): netcup\DNS\API\Handler->__construct(Array, Array)
    #1 {main}  thrown in .../www/test/src/Handler.php on line 35
  • Ah... großartig. Jetzt geht es ohne Fehler weiter. Vielen Dank. Ich meinte aber das Bash-Script natürlich (update-dyndns.sh).

    Komischer Weise übermittelt aber das Script an die API nur die IP meines vServers, nicht die meiner Fritzbox.


    Code
    [DEBUG] api login successful 
    [DEBUG] IPv4 for subdomain.meinedomain.tld set to 111.222.333.444 (<- IP meines vServers) 
    [DEBUG] dns recordset updated 
    [DEBUG] api logout successful

    EDIT 1:


    Offensichtlich läuft das Script update.php noch nicht sauber durch. Es wirft eine Exception:

    Code
    Fatal error: Uncaught RuntimeException: payload invalid in .../www/test/src/Handler.php:35
    Stack trace:
    #0 .../www/test/update.php(20): netcup\DNS\API\Handler->__construct(Array, Array)
    #1 {main}  thrown in .../www/test/src/Handler.php on line 35

    EDIT 2:


    In der Fritz.box kommt immer wieder die Meldung:

    Code
    18.03.20 22:15:05 DynDNS-Fehler: Die DynDNS-Aktualisierung war erfolgreich, anschließend trat jedoch ein Fehler bei der DNS-Auflösung auf. [4 Meldungen seit 18.03.20 22:03:05]
    
    18.03.20 21:54:23 DynDNS-Fehler: Der angegebene Domainname kann trotz erfolgreicher Aktualisierung nicht aufgelöst werden.
    
    18.03.20 21:54:23 DynDNS-Fehler: Die DynDNS-Aktualisierung war erfolgreich, anschließend trat jedoch ein Fehler bei der DNS-Auflösung auf. [6 Meldungen seit 18.03.20 21:34:23]
  • Danke noch einmal für die tolle Lösung.


    Ich habe leider ein Problem mit IPv6.
    An meiner Fitzbox ist ein NAS angeschlossen, über IPv4 funktioniert alles super mit einer Portweiterleitung.
    IPv6 routet leider natürlich immer nur zur FritzBox.

    Habt ihr eine Idee, ob man mit Anpassungen irgendwie die IPv6 des NAS statt der FitzBox übermitteln kann?

  • Bei mir kümmert sich der NAS selber darum, die entsprechende URL aufzurufen und so seine IPv6 mitzuteilen.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • bin kein ipv6-könner..

    aber nimm halt nich die IP vom router, sondern die eine vom DHCP, die du weiterleiten willst.. oder (wenn ich hier nicht falsch liege) nimm halt die router IP und ersetz das suffix?

  • Habt ihr eine Idee, ob man mit Anpassungen irgendwie die IPv6 des NAS statt der FitzBox übermitteln kann?

    Ah - kenne das Problem, hatte ich auch schon.


    Man muss seinen DynDNS "Daemon" bzw. das Updater Script immer von dem Gerät aus ausführen, dessen IPv6 Adresse auch im DynDNS stehen soll. Sprich, du musst das Script direkt auf deinem NAS laufen lassen.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Ah - kenne das Problem, hatte ich auch schon.


    Man muss seinen DynDNS "Daemon" bzw. das Updater Script immer von dem Gerät aus ausführen, dessen IPv6 Adresse auch im DynDNS stehen soll. Sprich, du musst das Script direkt auf deinem NAS laufen lassen.

    Das ist so nicht richtig.

    Man kann das ausführen wo immer man möchte. Dabei muss mann allerdings irgendwoher die IP bekommen, die man übermitteln will.


    So ein Script führt am ende auch nur ein curl-befehl aus, der dann ist nix anderes als ein "hallo dns server.. schreib mal die IP xyz an die domain foo.bar" macht.. und diese Aufgabe kann von überall erledigt werden. Die frage ist, wie die IP in diesen curl-aufruf reinkommt. und das kann so ein script auch anderweitig bekommen/auslesen. z.b. durch ping eines DHCP-Hosts im LAN.

    Sinnvoller wäre aber vermutlich mit der haupt-IP zu arbeiten und den suffix anzupassen, statt was im LAN anzupingen. Oder direkt den DHCP zu fragen.

  • Das ist so nicht richtig.

    Man kann das ausführen wo immer man möchte. Dabei muss mann allerdings irgendwoher die IP bekommen, die man übermitteln will.


    So ein Script führt am ende auch nur ein curl-befehl aus, der dann ist nix anderes als ein "hallo dns server.. schreib mal die IP xyz an die domain foo.bar" macht.. und diese Aufgabe kann von überall erledigt werden. Die frage ist, wie die IP in diesen curl-aufruf reinkommt. und das kann so ein script auch anderweitig bekommen/auslesen. z.b. durch ping eines DHCP-Hosts im LAN.

    Sinnvoller wäre aber vermutlich mit der haupt-IP zu arbeiten und den suffix anzupassen, statt was im LAN anzupingen. Oder direkt den DHCP zu fragen.

    Ja und Nein.


    Der Agent, welchen ich nutzte, macht folgendes:
    --> curl ipapi.tld

    <-- eigene öffentliche IP Adresse
    --> CCP API - hier ist meine öffentliche IP, setzt die für folgende Domain mit folgender Subdomain
    <-- Joa, mach ich


    In dem Fall muss man immer das von dem Gerät ausführen, dessen IPv6 man haben mag.



    Alternative: An sich sollte man bei IPv6 ja SLAAC nutzen und da kannste dir ja mit der MAC Adresse des entsprechenden Interfaces per EUI64 den Suffix zusammenschrauben. Das verbunden mit dem aktuellen Präfix könnte man dann auch nehmen, da ist das dann richtig.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Die Alternative klingt interessant, aber wie mache ich das? :D
    Ich habe aktuell nur die Fritzbox und ein Raspberry-NAS.