DynDNS auf meine Domain führt intern zur Fritzbox / Zertifikatfehler

  • Guten Morgen,

    ich habe, nach diesem Tutorial, DynDNS direkt bei netcup eingerichtet:


    Weiterhin 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?

  • Rufe ich das nun im Heimnetz auf, lande ich auf der Anmeldeseite der Fritzbox und nicht auf der Nextcloud.

    Das nennt sich NAT Loopback, wenn du aus deinem Heimnetz deine eigene öffentliche IP aufrufst. Jeder Router verhält sich da anders, einige blocken es ganz, andere lassen nur den Zugriff auf lokale Router-Dienste zu. Prinzipiell kann das eine Sicherheitslücke sein, deshalb wird der Zugriff eingeschränkt. Du könntest versuchen, den internen HTTPS Server der Box auf einen anderen Port zu verlegen. Aber ich glaube, das geht nur für den externen Zugriff, nicht intern. Einen Versuch ist es wert.


    Die einzige sichere Möglichkeit ist ein eigener, interner DNS Server, der die Abfrage auffängt und auf die interne IP umleitet. Oder alles auf IPv6 umstellen, das würde auch helfen.

  • Ich vermute hier wird intern eine Verbindung über IPv6 aufgebaut und extern über IPv4.


    Hast du mal mit curl und -6 und -4 geguckt, was zurückkommt?

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


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

    Gefällt mir 1
  • 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?

  • Den IPv6 DNS Eintrag korrigieren. Bedenke: bei IPv6 funktionieren Portweiterleitungen nicht, wie bei IPv4. Während du bei IPv4 auf den Router zugreifst, und der leitet das Paket an den Server weiter, musst du bei IPv6 direkt auf die Server IP zugreifen. Heißt: Der AAAA Eintrag von sub.domain.com muss auf die Server-IPv6-Adresse zeigen, nicht auf den Router. Zeigt sie auf den Router, bekommst du natürlich auch die Webseite des Routers angezeigt.


    Also muss entweder der Server selber die dyndns Aktualisierung vornehmen, oder du aktualisierst vom Router aus nur das Prefix und lässt die Interface-ID statisch (und nimmst die des Servers, nicht die des Routers).


    Übrigens: Dass es von außen funktioniert, ist Glückssache. Du hast offenbar eine IPv4 Verbindung von außen benutzt, da klappt die Portweiterleitung. Greifst du per IPv6 von außen zu, geht es auch da schief.

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

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

    Das oder den Nameserver selber machen fürs LAN.


    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.

    Aus deiner Beschreibung hätte ich geschlossen, dass es gerade nicht der Bridge Modus ist. Über eine Bridge haben alle Container Zugang zum Heimnetz. Über die IP des Hosts erfolgt der Zugriff, wenn NAT im Spiel ist (auch wenn lokal für die Container auch eine Bridge zum Einsatz kommen kann, aber ohne Integration des Host-Netzwerkes).


    Muss ich daran was ändern?

    Nein. Ggf. musst du es auch für IPv6 machen.


    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?

    Genau so.


    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?

    Könnte sein. Keine Ahnung, ob ein Proxy von IPv4 nach IPv6 übersetzen kann. Kann aber sein.

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

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

  • Commerzpunk

    Hat den Titel des Themas von „DynDNS auf meine Domain führ intern zur Fritzbox / Zertifikatfehler“ zu „DynDNS auf meine Domain führt intern zur Fritzbox / Zertifikatfehler“ geändert.