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.

  • 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.

  • 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
    1. Fatal error: Uncaught Error: Class 'SoapClient' not found in .../www/test/src/Soap.php:40
    2. Stack trace:
    3. #0 .../www/test/src/Soap.php(130): netcup\DNS\API\Soap\DomainWebserviceSoapClient::_Call('login', Array)
    4. #1 .../www/test/src/Handler.php(107): netcup\DNS\API\Soap\DomainWebserviceSoapClient->login('Kd-Nr', 'API-KEY...', 'API-PASSWORD...', '...')
    5. #2 .../www/test/update.php(20): netcup\DNS\API\Handler->doRun()
    6. #3 {main}
    7. 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
    1. [DEBUG] api login successful
    2. [DEBUG] IPv4 for subdomain.meinedomain.tld set to 111.222.333.444 (<- IP meines vServers)
    3. [DEBUG] dns recordset updated
    4. [DEBUG] api logout successful

    EDIT 1:


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

    Code
    1. Fatal error: Uncaught RuntimeException: payload invalid in .../www/test/src/Handler.php:35
    2. Stack trace:
    3. #0 .../www/test/update.php(20): netcup\DNS\API\Handler->__construct(Array, Array)
    4. #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
    1. [DEBUG] api login successful
    2. [DEBUG] IPv4 for subdomain.meinedomain.tld set to 111.222.333.444 (<- IP meines vServers)
    3. [DEBUG] dns recordset updated
    4. [DEBUG] api logout successful

    EDIT 1:


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

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

    EDIT 2:


    In der Fritz.box kommt immer wieder die Meldung:

    Code
    1. 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]
    2. 18.03.20 21:54:23 DynDNS-Fehler: Der angegebene Domainname kann trotz erfolgreicher Aktualisierung nicht aufgelöst werden.
    3. 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]