ext. Domain - Nextcloud - interner Zugriff

[burnout2000]

Hallo zusammen.

Ich habe eine Domain cloud.xyz.com die auf meine Nextcloud verlinkt ist. Nextcloud (docker container) läuft im Heimnetz auf 192.168.1.10. Über Letsencrypt (docker container) wird ein Zertifikat für https ausgestellt.
Es funktioniert wunderbar. Zugriff über https://cloud.xyz.com auf Nextcloud, von unterwegs und von zu Hause.

Allerdings möchte ich von zu Hause nicht, dass der traffic zuerst ins Internet geroutet wird, sondern nur im Heimnetz bleibt.

In der FritzBox habe ich die cloud.xyz.com im DNS rebind eingetragen, das hat nicht funktioniert.
Wird immernoch über die externe IP geroutet. (tracert löst über ext. IP auf)

Im Netzwerk läuft ein pihole, dort unter lokaler DNS die cloud.xyz.com zu der 192.168.1.10 eingetragen. (tracert löst auf lokale IP auf)
...und dann habe ich keinen Zugriff mehr auf Nextcloud. Werder über cloud.xyz.com noch über 192.168.1.10

Was könnte hier schief laufen?

Vielen Dank im Voraus

 

[Mr. Robot]

Die Fritzbox muss den Namen auf die externe IP auflösen. Sie routet die Pakete (wenn nichts schief läuft) trotzdem intern. Das sieht man anhand der kürzeren Ping-Zeiten.

Warum muss sie das? Nun ja, in einem Netzwerk gibt es ja mehrere potentielle Ziele. Ich hab bei mir mehrere Server unter dem gleichen DNS-Namen laufen. Die Fritzbox schickt z.B. Pakete mit dem Zielport 80 dabei an einen anderen Rechner, als Pakete mit dem Zielport 443. Würde man den DNS Namen auf eine interne IP auflösen, könnte die Fritzbox nicht mehr routen, und man würde nur noch eine einzige interne IP erreichen.
(Ok, in den meisten Fällen würde das reichen. Aber es wäre halt eine massive Einschränkung.)

Ist der Pi nur dein DNS Server, oder auch als Standardgateway eingetragen? Falls letzteres, blockiert der PI vielleicht Ziele im internen Netzwerk. (Nur so als erste Vermutung, ich hab keine Ahnung von Pihole.)

 

[Raijin]

Allerdings möchte ich von zu Hause nicht, dass der traffic zuerst ins Internet geroutet wird, sondern nur im Heimnetz bleibt.

Wird er auch nicht. Das Stichwort heißt: NAT-Loopback. Wenn ein Router das unterstützt - wie die Fritzbox - dann dreht sie den Traffic noch im WAN-Port um 180° um und schickt die Verbindung in die NAT-Pipeline. Das heißt, dass der Provider nie auch nur ein einziges Bit davon sieht. Das ist ungefähr damit vergleichbar, dass du vom Wohnzimmer nicht direkt ins Badezimmer gehst, sondern erst zur Haustür, einen Schritt rausmachst, aber gleich wieder reingehst.

Die Problematik bei NAT-Loopback ist also nicht, dass irgendetwas ins Internet geleakt wird, sondern dass die Verbindung dennoch einen riesigen Umweg geht. Statt zB vom PC, der womöglich am selben Switch hängt wie das NAS, direkt zum NAS zu gehen, laufen die Daten erstmal quer durch das Netzwerk zum Router, dort über die WAN-LAN-NAT-Pipeline und dann den ganzen weg wieder zurück zum NAS. Schlimmstenfalls hat das massive Performanceeinbußen zur Folge, wenn der Router keine 1 Gbit/s am WAN inkl. NAT schafft.

Am NAS sähe die Verbindungsanfrage dann auch so aus als wenn sie von der WAN-IP käme und nicht von der PC-IP. Das heißt, dass der Rückweg denselben Umweg über den Router nimmt. Warum? Ganz einfach, kurz vom Umdrehen des Traffics im WAN-Port hat der Router bereits die Absender-IP auf seine WAN-IP geändert. Er spricht also sozusagen mit sich selbst.

In der FritzBox habe ich die cloud.xyz.com im DNS rebind eingetragen, das hat nicht funktioniert.
Wird immernoch über die externe IP geroutet. (tracert löst über ext. IP auf)

Das ist aber genau der Weg. Normalerweise verhindert der DNS Rebindschutz der Fritzbox, dass externe Domains auf eine lokale IP auflösen. Mit einer Ausnahme für cloud.xyz.com kann man das umgehen. Aber: Natürlich muss man dafür dann auch die Fritzbox als DNS verwenden. Hat man am PC zB 8.8.8.8 oder eben einen pihole als DNS, dann wird der Fritzbox-DNS überhaupt nicht gefragt....

Darüber hinaus löst tracert überhaupt nichts auf, das ist ein Tracetool. Wenn du die Auflösung einer Domain testen willst, dann verwende bitte nslookup. So kannst du beispielsweise verschiedene DNS testen, wenn du nslookup cloud.xyz.com 192.168.178.1 für den Fritzbox-DNS und nslookup cloud.xyz.com 8.8.8.8 für den google-dns nimmst. Eigentlich sollte bei ersterem dann auch die DNS-Rebind-Ausnahme greifen und die lokale IP aufgelöst werden.

und dann habe ich keinen Zugriff mehr auf Nextcloud. Werder über cloud.xyz.com noch über 192.168.1.10

Wenn das der Fall ist, dann wird bei nextcloud direkt eine Domain-Weiterleitung durchgeführt. Wenn die Domain dann nicht korrekt aufgelöst werden kann, klappt das natürlich nicht. Das Problem hatte ich beispielsweise als ich meinen DNS aufgesetzt habe und auf meinem Speedport einloggen wollte - mittels IP. Der Speedport hat sofort auf speedport.ip umgeleitet und zack - keine Verbindung. Ich musste zwingend im DNS einen Eintrag für speedport.ip vornehmen, weil sich der Speedport partout nicht direkt via IP ansurfen lassen wollte.

 

[brainDotExe]

Die einfachste Lösung wäre zusätzlich IPv6 zu verwenden.
Dann läuft der Datenverkehr im lokalen Netzwerk immer direkt zum Ziel.

 

[burnout2000]

Danke für Euren Support!

Ist der Pi nur dein DNS Server, oder auch als Standardgateway eingetragen? Falls letzteres, blockiert der PI vielleicht Ziele im internen Netzwerk. (Nur so als erste Vermutung, ich hab keine Ahnung von Pihole.)

Der Pihole ist nur als DNS Server eingetragen. Standardgateway ist die FritzBox.

Schlimmstenfalls hat das massive Performanceeinbußen zur Folge, wenn der Router keine 1 Gbit/s am WAN inkl. NAT schafft.

So ist mir das Ganze aufgefallen. Wenn ich Datei Up- oder Downloade zur Nextcloud aus dem heimischen Netz, sollte mein Download-Speed doch bedeutend größer sein, als mein maximaler Internet Upload Speed von ~1,2MB/s
Deswegen die Vermutung, dass da irgendwie die Internetleitung mitspielt.

Aber: Natürlich muss man dafür dann auch die Fritzbox als DNS verwenden. Hat man am PC zB 8.8.8.8 oder eben einen pihole als DNS, dann wird der Fritzbox-DNS überhaupt nicht gefragt....

Der "DNS Aufbau" ist jetzt wie folgt:
DNS Server ist der Pihole. Als upstream DNS Server ist die FrtizBox eingetragen. In der FritzBox sind die xyz.com und cloud.xyz im DNS rebind eingetragen. Als DNS Server in der FritzBox sind die von Cloudflare eingetragen.

Die einfachste Lösung wäre zusätzlich IPv6 zu verwenden.
Dann läuft der Datenverkehr im lokalen Netzwerk immer direkt zum Ziel.

Ipv6 ist bei mir aktiv. Die FritzBox verteilt fleißig Adressen an die Geräte.

 

[brainDotExe]

Ipv6 ist bei mir aktiv. Die FritzBox verteilt fleißig Adressen an die Geräte

Und die cloud.xyz.com löst auch auf die IPv6 Adresse des Nextcloud Servers auf, sprich hat einen AAAA Record?
Bzw. Docker läuft auch mit IPv6 Unterstützung?

 

[burnout2000]

Und die cloud.xyz.com löst auch auf die IPv6 Adresse des Nextcloud Servers auf, sprich hat einen AAAA Record?
Bzw. Docker läuft auch mit IPv6 Unterstützung?

Die Domain hat keinen AAAA record und docker läuft auch nur im ipv4

 

[brainDotExe]

Dann wäre die einfachste Lösung das zu ändern

 

[suRe]

Hast du mit anderen Dockern ein ähnliches Problem?
Bei mir ist es nämlich das gleiche. Nextcloud kann ich einfach nicht im LAN erreichen, nur über die Subdomain Adresse (auch mit ReverseProxy). Hab 1:1 den selben Aufbau (ReverseProxy, PiHole und FritzBox etc.). Die Docker laufen alle auf einem unRAID Server. Alle anderen Docker kann ich über die IP Adresse erreichen, Nextcloud aber nicht, der Container geht nur über "https://cloud.xyz.com".

 

[burnout2000]

Hast du mit anderen Dockern ein ähnliches Problem?
Bei mir ist es nämlich das gleiche. Nextcloud kann ich einfach nicht im LAN erreichen, nur über die Subdomain Adresse (auch mit ReverseProxy). Hab 1:1 den selben Aufbau (ReverseProxy, PiHole und FritzBox etc.). Die Docker laufen alle auf einem unRAID Server. Alle anderen Docker kann ich über die IP Adresse erreichen, Nextcloud aber nicht, der Container geht nur über "https://cloud.xyz.com".

das Problem besteht nur mit dem Docker Container, der auch von außen über https erreichbar ist.
Alle anderen Container sind über die interne IPort erreichbar.
Wenn ich im Browser die IP eintippe (https://192.168.1.10 , wird automatisch auf https://cloud.xyz.com redirected und es passiert nichts. Kein Unterschied ob mit DNS rebind oder ohne. Einziger Effekt kommt von cloud.xyz.com aus dem lokalen DNS im Pihole rauszuwerfen, dann funktioniert es, aber halt alles über Inet und nicht mehr über lokale Verbindung....und das ist eben viel zu lahm

 

[Raijin]

DNS Server ist der Pihole. Als upstream DNS Server ist die FrtizBox eingetragen. In der FritzBox sind die xyz.com und cloud.xyz im DNS rebind eingetragen. Als DNS Server in der FritzBox sind die von Cloudflare eingetragen.

Welchen Zweck erfüllt denn dann noch die Fritzbox? Der Aufbau ist in meinen Augen totaler Quark. PI>Fritz>Cloudflare? PI>Cloudflare ist deutlich sinnvoller. Wenn man den DHCP des pihole nutzt, kommt man auch in den Genuss des deutlich umfangreicheren dnsmasq.

 

[suRe]

Alle anderen Container sind über die interne IPort erreichbar.

Und hier müsste das Problem liegen. Es kann nicht sein das alle anderen Container erreichbar sind, Nextcloud jedoch nicht. Ich hab z.B. Bitwarden genauso laufen - hier läuft LAN und WAN ohne Probleme.
Vielleicht eine Einstellung in den "Trusted Domains" von Nextcloud??

 

[burnout2000]

Welchen Zweck erfüllt denn dann noch die Fritzbox? Der Aufbau ist in meinen Augen totaler Quark. PI>Fritz>Cloudflare? PI>Cloudflare ist deutlich sinnvoller. Wenn man den DHCP des pihole nutzt, kommt man auch in den Genuss des deutlich umfangreicheren dnsmasq.

Pi>CLoudflare
genau so war es bis heute Morgen.
Aber da der DNS rebind dann wohl nicht funktioniert, habe ich die FritzBox mit dazugenommen, wo der DNS rebind eingetragen ist.
Wenn das auch über den PiHole machbar ist, fliegt die FB wieder raus aus der Kette.
Nichtsdestotrotz, es funktioniert mit beiden Ansätzen nicht

Ergänzung (21. Juni 2020)

Und hier müsste das Problem liegen. Es kann nicht sein das alle anderen Container erreichbar sind, Nextcloud jedoch nicht. Ich hab z.B. Bitwarden genauso laufen - hier läuft LAN und WAN ohne Probleme.
Vielleicht eine Einstellung in den "Trusted Domains" von Nextcloud??

sind sowohl die cloud.xyz.com und die IP 192.168.1.10 eingetragen

 

[Raijin]

WAS funktioniert denn nicht? Wenn nslookup cloud.gedingens die richtige IP auflöst, hat das nix mit Verbindungsproblemen zu tun. Ein DNS ist nur die Telefonauskunft für das Netzwerk und hat mit der Verbindung soviel zu tun wie die 11880 mit dem Anruf bei der Nummer, die du gerade dort erfragt hast.

 

[burnout2000]

WAS funktioniert denn nicht? Wenn nslookup cloud.gedingens die richtige IP auflöst, hat das nix mit Verbindungsproblemen zu tun. Ein DNS ist nur die Telefonauskunft für das Netzwerk und hat mit der Verbindung soviel zu tun wie die 11880 mit dem Anruf bei der Nummer, die du gerade dort erfragt hast.

nslookup löst aus dem internen Netz auf die externe IP auf, cloud.gedingens von extern wie intern erreichbar.
Zugriff von extern wie intern "lahme" Verbindung, der upload Geschwindgkeit meines Internetanschlusses entsprechend.

Eintrag im lokalen DNS vom Pihole cloud.gedingens auf 192.168.1.10
Zugriff von extern unverändert
Zugriff von intern nicht mehr möglich

 

[Mr. Robot]

Was heißt denn "nicht möglich"?
Gibt es eine Fehlermeldung, kommt ein Türsteher, explodiert der PC...? Lass dir doch nicht alles aus der Nase ziehen...

 

[burnout2000]

der Browser lädt die Seite nicht

NET::ERR_CERT_AUTHORITY_INVALID

(wenn cloud.xyz.com im lokalen DNS auf die 192.168.1.10 eingetragen ist)

 

[Raijin]

nslookup löst aus dem internen Netz auf die externe IP auf

Wie hast du im pihole denn den lokalen Eintrag erstellt?

 

[burnout2000]

über die "local DNS records"

 

[Raijin]

Und wenn du jetzt

nslookup cloud.dingens hier.die.ip.vom.pihole

am PC ausführst, dann kommt da nicht die 192.168....?