Okay, das war schon anonymisiert.
Habe es aber nochmal deutlicher mit x-en gemacht.
Beiträge von Commerzpunk
-
-
Hallo,
wie hier beschrieben, habe ich ja das DynDNS mit dem Skript auf die API von Netcup auf meiner Fritzbox eingerichtet.
DynDNS auf meine Domain führt intern zur Fritzbox / Zertifikatfehler - netcup KundenforumGuten Morgen, ich habe, nach diesem Tutorial, DynDNS direkt bei netcup eingerichtet: https://community.netcup.com/e…ials/ddns-with-webhosting Weiterhin habe…forum.netcup.deDas lief dann jetzt all die Zeit problemlos.
Gestern haben hatten wir einen kurzen Internetausfall, deswegen habe ich ein paar Änderungen gemacht, in Absprache mit dem 1&1 Support:
WLAN an / aus, Fritzbox Neustart, Kabel an der Fritzbox ab/an/umgesteckt und letztlich alles wieder zurück wie es war.
Dann habe ich auf eigene Faust noch nach dieser Anleitung: https://stadt-bremerhaven.de/fritzbox-durch…t-iperf-messen/ iperf aktiviert.
Das ist aber nun auch wieder ausgeschaltet, nutze ich zur Zeit nicht.
Heute habe ich dann plötzlich festgestellt, dass meine DynDNS Dienste nicht mehr gehen.
Siehe da: Die IP im Netcup DNS ist noch die von gestern Abend, heute habe ich bereits eine Neue.
API Log zeigt auch den letzten Eintrag von gestern Abend.
Die Fritzbox meldet keinen Fehler, da steht immer DynDNS angemeldet und OK.
Ich habe nun alle Register gezogen, Fritzbox neu gestartet, stromlos gemacht und neu gestartet.
Den API Key und Passwort verändert und in der .env Datei hinterlegt.
User und Passwort doppelt und dreifach geprüft.
Das Skript zeigt in der PHP.log auch keinen Fehler.
Wenn ich allerdings die update url manuell im Browser aufrufe, bekomme ich diesen Fehler, der mir nicht normal erscheint:
CodeFatal error: Uncaught SoapFault exception: [SOAP-ERROR: Parsing Schema: can't import schema from 'http://schemas.xmlsoap.org/wsdl/soap/'] WSDL in /var/www/vhosts/hosting148033.a2eaf.netcup.net/ddns.nas-hunda.de/httpdocs/src/Soap.php:44 Stack trace: #0 /var/www/vhosts/hosting148033.a2eaf.netcup.net/ddns.nas-hunda.de/httpdocs/src/Soap.php(130): netcup\DNS\API\Soap\DomainWebserviceSoapClient::_Call('login', Array) #1 /var/www/vhosts/hosting148033.a2eaf.netcup.net/ddns.nas-hunda.de/httpdocs/src/Handler.php(104): netcup\DNS\API\Soap\DomainWebserviceSoapClient->login('xxxx', 'xxxx...', 'xxxx...', 'xxxx...') #2 /var/www/vhosts/hosting148033.a2eaf.netcup.net/ddns.nas-hunda.de/httpdocs/update.php(31): netcup\DNS\API\Handler->doRun() #3 {main} thrown in /var/www/vhosts/hosting148033.a2eaf.netcup.net/ddns.nas-hunda.de/httpdocs/src/Soap.php on line 44Das ist mir nun schon paar Mal passiert und ich finde keine Erklärung.
Es lässt sich erst wieder in Gang setzen, wenn ich die IP in der DNS Verwaltung manuell aktualisiere, dann läuft es erst mal wieder, auch die Update URL geht dann wieder problemlos.
Kann mir jemand helfen?
-
Ich weiß, aber die Lösung dauert zu lange und ist zu anstrengend, gerade jetzt über Ostern. Meine Familie steigt mir aufs Dach.
Leider ist es ja nicht ein gradliniges umkonfigurieren und gut ist, sondern - für mich als Amateur - ein wochenlanges Rumgedoktore.
Daher erst mal verschoben, mit Glasfaser habe ich nächstes Jahr ja die Chance
auf nur noch IPv6.Spätestens dann werde ich die Sache nochmal neu und mit Vorplanung angehen.
Das ist dann entspannter, als mit einer kaputten Umgebung und unter Druck.
-
Okay, ich habe es nun doch etwas anders gelöst:
- IPv6 Teil aus dem DynDNS Update String entfernt
- AAA @ Record (wurde von DynDNS gesetzt) in den DNS Einstellungen entfernt
Jetzt ist IPv6 erst mal aus dem Spiel, das ist mir zurzeit noch zu kompliziert und wacklig - ich werde es umsetzen, wenn es nicht mehr anders geht.
-
Ah, cool, dann kommen wir der Sache etwas näher

Verständnisfragen:
Zur Zeit habe ich auf meinem Unraid, auf dem die Dienste alle als Docker Container laufen, kein IPV6 aktiviert, das müsste ich wahrscheinlich als Erstes tun, damit der Servers selbst ne IPv6 bekommt?
Die Docker Container laufen alle im Bridge-Modus, das heißt sie haben alle keine eigene IP(4) Adresse in meinem Netz, sondern nur eine Übersetzung von innen nach außen, also in der Regel sowas wie Port 80 im Container nach außen auf 8081 auf die IP(4) des physischen Unraid-Servers. Muss ich daran was ändern?
Meine Verteilung der 3 Dienste geht ja per Reverse Proxy, der ebenfalls ein Container ist. Dort kommt bisher die externe Anfrage auf die 443 per Portweiterleitung von der Fitzbox an und dort wird dann, je nachdem über welche Subdomain die Anfrage kam, leitet der Reverse Proxy dann die Anfrage an die interne auf die Server Ip mit dem richtigen Port weiter. Wie wird das mit IPv6 eingerichtet? Also praktisch dann für ein Beispiel in etwa so: "listen 443 > cloud.* > 192.168.178.93:449"
Für mich scheint die Lösung zu sein, dafür zu sorgen, dass der Reverse Proxy Container eine eigene IPv6 Adresse in meinem Netz bekommt, ohne Bridge, und diese IPv6 könnte ich dann ja fest in das DynDNS Update eintragen, die wird sich ja nicht mehr ändern. Ab da wird die Unterverteilung ja normal weiterlaufen, könnte ich auch auf IPv4 lassen, oder?
-
Guten Morgen,
ihr habe wohl beide Recht, es ist am Ende dieses IPv6 Thema.
An der Fritzbox kann man da nach etwas Recherche nichts umstellen, die ist da recht einfach gestrickt, das ist für mich aber OK.
Ich habe einen Adguard Home Container unter Unraid laufen, aber noch nicht produktiv und damit noch nicht den DNS Server der Fritzbox ersetzt.
Allerdings ist bei Unraid kein IPv6 aktiv.
curl -4 https://sub.domain.com führt zu >> curl: (7) Failed to connect to sub.domain.com port 443 after 2070 ms: Couldn't connect to server
curl -6 https://sub.domain.com führt zu >> curl: (60) schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - Die Zertifikatkette wurde von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt.
Welche Schritte kann ich nun tun, um aus meinem Heimnetz auf die Dienste per ext. Domain zuzugreifen?
-
Guten Morgen,
ich habe, nach diesem Tutorial, DynDNS direkt bei netcup eingerichtet:
Setting up DDNS with netcup Webhostingcommunity.netcup.comWeiterhin habe ich 3 Subdomains für Dienste, die ich erreichen möchte, hinterlegt, hier mal eine:
[Blockierte Grafik: https://www.kodinerds.net/wcf/attachment/70507-image-png/]
Auf meiner Fritzbox 7490 ist ein einziger Port offen, 443, der zeigt auf eine interne IP, auf der ein Reverse-Proxy läuft.
Nach Recherche habe noch eine Rebind-Schutz für die externe Domain und Subdomain eingetragen.
Das Setup funktioniert von extern genau wie gewünscht.
Generell ist das Nextcloud Setup OK und läuft schon länger so, mit Reverseproxy, Lets Encrypt, fail2ban.Rufe ich das nun im Heimnetz auf, lande ich auf der Anmeldeseite der Fritzbox und nicht auf der Nextcloud.
Wenn ich versuche den Nextcloud-Client intern zu verbinden (über die externe Domain), dann zeigt es einen Zertifikatsfehler, und das präsentierte Zertifikat ist das interne der Fritzbox und nicht das Lets Encrypt, welches bei der Nextcloud liegt.
Was kann ich nun tun, damit es intern so geschmiert läuft wie extern?
-
Hallo,
ich bin den Anweisungen auf GitHub gefolgt.
Es scheint keine Aktualisierung vorgenommen zu werden.
debug = true, log = true.
Inhalt der json.log ist lediglich:
{
"nas-hunda.de": []
}
Was mache kann ich noch einstellen, was könnte die Ursache sein, dass es kein DNS Update gibt?
-
Das funktioniert leider nicht.
emby.beispiel.de führt immer noch zu einer 403 Fehlerseite bei Netcup.
-
Ok, soweit verstanden, das war wohl ein Missverständnis meinerseits dass der Container das auch macht. Schade.
Das mit dem CNAME verstehe ich nicht so ganz.
Ich möchte eine Handvoll Dienste über den Reverse Proxy von außen erreichbar machen, mit möglichst einfachen, kurzen Namen.
cloud.beispiel.de
media.beispiel.de
info.beispiel.de
Fritz-Box und myFritz habe ich tatsächlich auch.
Was muss ich dann jetzt noch wo eintragen?
-
Guten Morgen,
ich möchte gern meine Netcup Domain auf meinen Server zu Hause zeigen lassen.
Dazu verwende ich den Linuxserver SWAG Container da dieser einen Nginx, Reverseproxy, Lets Encrypt und DNS Update für Netcup mitbringt.
Den Container habe ich konfiguriert, API Key und Passwort eingetragen, die Propagate Time auf 900 Sekunden gestellt.Was ich sehe ist, dass das Zertifikat korrekt geholt wird, dass iM API Log erfolgreiche Änderungen protokolliert werden, dass im DNS Eintrag der Domain "_acme-challenge" Einträge entstehen.
Der Container loggt auch keine Probleme:
Requesting a certificate for *.nas-hunda.de and nas-hunda.de
Performing the following challenges:
dns-01 challenge for nas-hunda.de
dns-01 challenge for nas-hunda.de
Unsafe permissions on credentials configuration file: /config/dns-conf/netcup.ini
Waiting 900 seconds for DNS changes to propagate
Waiting 900 seconds for DNS changes to propagate
Waiting for verification...
Waiting for verification...
Cleaning up challenges
Cleaning up challenges
Danach verschwinden die TXT Einträge für die Challenge, aber es ändert sich halt nix an den DNS Einträgen, somit zeigt alles noch auf Netcup und nicht auf meinen Server.
Was mache ich denn hier noch falsch?