iOS DNS Auflösung Zugriff auf Port Forwarding geht auf Fritz

jokakilla

Lt. Junior Grade
Registriert
Dez. 2007
Beiträge
308
Hallo zusammen,
ich habe zu Hause einen Rechner mit Nextcloud laufen. In der Fritzbox ist ein Portforwarding von Port 443 auf die Nextcloud eingerichtet und ein DynDNS Account konfiguriert.

Wenn ich aus dem eigenen WLAN mit Windows/Ubuntu/Android Geräten auf https://meineDynDnsDomain gehe wird die Domain auf meine öffentliche IP aufgelöst, der HTTP Request geht an die Fritz und landet per Port-Forwarding auf dem Nextcloud Webserver.

Wenn ich aus dem lokalen WLAN versuche mit iOS auf https://meineDynDnsDomain zuzugreifen lande ich aber auf der Fritzbox statt der Nextcloud. Meine Vermutung: iOS kennt die öffentliche IP des WLANs mit dem es gerade im Netz ist sowie die IP von meineDynDnsDomain und merkt das beides gleich ist. Dann versucht es quasi abzukürzen indem der Request nicht an die öffentliche IP sondern das Standard-Gateway (welches die Fritz ist). Das Port-Forwarding greift natürlich bei https://192.168.1.1 nicht und so landet man auf der Fritz.

Ist das ein iOS Bug oder ein Feature :D Kann man daran etwas ändern?
 
Port 80 und 443 ist reserviert für http und https, das würde ich für Netxcloud nicht verwenden. Daher nimm mal einen anderen Port für Nexcloud und mach darauf das forwarding.
 
Du solltest zumindest das Port für das Webinterface von der Fritzbox ändern. Nimm statt 443 z.B. 8443, dann musst du das bei Zugriff auf die Fritzbox immer mit angeben https://192.168.1.1:8443.

Das ganze geht auch umgetreht, Nextcloud z.B. auf 8443 und die Fritzbox weiterhin 443. Es sollte nicht das gleiche Port für beide Dienste sein.
 
  • Gefällt mir
Reaktionen: DeusoftheWired
Aus deinem lokalen Netz möchtest du nicht den Umweg über den DynDNS-Namen und durch das das halbe Internet gehen, bis du wieder an deinem eigenen Anschluß rauskommst.
Bist du im heimischen (W)LAN, verwende die lokale IP für den Zugriff auf Nextcloud.
 
DeusoftheWired schrieb:
Aus deinem lokalen Netz möchtest du nicht den Umweg über den DynDNS-Namen und durch das das halbe Internet gehen, bis du wieder an deinem eigenen Anschluß rauskommst.
Bist du im heimischen (W)LAN, verwende die lokale IP für den Zugriff auf Nextcloud.

Und das geht wie? Dafür müsste ich doch jedes mal den Nextcloud Client umkonfigurieren je nach dem ob ich vom heimischen WLAN zugreifen will oder von woanders.

Ich kann gerade nicht nachsehen aber gäbe es einen Konflikt mit dem Port 443 auf der Fritz und dem Port-Forwarding müssten andere Geräte doch auch Probleme haben oder? Es ist aber nur iOS betoffen.
Ergänzung ()

Btw: Ich könnte verstehen wenn man einstellen kann dass der Fritzbox DNS die eigene DynDNS Domain lokal auf eine bestimmte IP auflöst.

Z.B. würde der Fritz DNS dann z.B. lokal die DynDNS Domain auf 192.168.1.2 auflösen. Geht aber nur wenn alle Port-Forwardings auf das gleiche System gehen. Z.B. 8443 auf 192.168.1.2 und 8080 auf 192.168.1.3 wäre dann schon problematisch.
 
Zuletzt bearbeitet:
jokakilla schrieb:
Und das geht wie? Dafür müsste ich doch jedes mal den Nextcloud Client umkonfigurieren je nach dem ob ich vom heimischen WLAN zugreifen will oder von woanders.

An der Nextcloud-Installation brauchst du dafür nichts zu ändern. Ihr ist egal, ob Clients aus dem WAN oder LAN auf sie zugreifen.

Das einzige, was du ändern mußt, ist, anstatt des DynDNS-Namens in der Adreßleiste des Browsers die lokale IP oder – sofern er in deinem LAN aufgelöst wird – den lokalen Hostnamen der Nextcloud-Büchse einzugeben. Also anstatt jokakilla.myfritz.net eben 192.168.1.2 bzw. jokakillasnextcloudbuechse.

jokakilla schrieb:
Btw: Ich könnte verstehen wenn man einstellen kann dass der Fritzbox DNS die eigene DynDNS Domain lokal auf eine bestimmte IP auflöst.

Im Auslieferungszustand verhindern FRITZ!Boxen das sogar. Läßt sich aber deaktivieren. https://avm.de/service/fritzbox/fri...Auflosung-privater-IP-Adressen-nicht-moglich/
 
jokakilla schrieb:
Btw: Ich könnte verstehen wenn man einstellen kann dass der Fritzbox DNS die eigene DynDNS Domain lokal auf eine bestimmte IP auflöst.
Das ist der "richtige" Weg, wenn man das denn so nennen möchte. Wie @DeusoftheWired aber schon gesagt hat, verhindert der DNS rebind Schutz der Fritzbox das, kann aber wie verlinkt abgeschaltet werden.

Von intern auf einen "lokalen" DDNS zuzugreifen ist netzwerktechnisch ganz platt ausgedrückt bescheuert. Dadurch kommt man nämlich in das Feld des NAT loopback oder auch NAT hairpin. Dabei löst ein Client via DNS ganz normal die DDNS-Domain auf, merkt, dass diese ja im Internet liegt (der Client weiß ja nix von der WAN-IP) und routet das dann zum Standardgateway, dem Internetrouter. Dieser merkt dann, wenn er NAT loopback unterstützt, dass seine eigene WAN-IP gemeint ist. Allerdings passiert das erst im allerletzten Moment, bevor die Daten das WAN-Interface in Richtung Provider verlassen. Der Router dreht die Verbindung dann um und leitet sie exakt so wie externen Traffic in den WAN-Port ein.

Nu könnte man sagen "Ja und?" Das Problem ist, dass diese Verbindung dann eben auch die komplette NAT-Pipeline durchläuft, also auch die Portweiterleitungen. Soweit noch unkritisch, oder etwa doch nicht? Nun ja, je nach Performance des Routers kommt hier nun aber seine NAT-Performance zum Tragen. Hat man also ggfs einen Router, der eben nicht mit 1 Gbit/s WAN zurecht kommt, sondern zB max 500 Mbit/s schafft, dann ist eben auch die Verbindung vom lokalen Client auf den vermeintlich lokalen Server mit 500 Mbit/s gedeckelt, weil jedes einzelne Datenpaket zwischen Client und Server den Umweg über den Router und dessen WAN-Port/NAT-Engine nimmt. Bei einem schnellen Router merkt man das unter Umständen gar nicht, aber es ist schon absurd, dass zwei potentiell direkt nebeneinander stehende und am selben Switch angeschlossenen Geräte im worst case erstmal quer durchs Haus zum Router, WAN-Port, NAT und dann wieder quer durchs Haus zum Ziel gehen. Die Antwort nimmt im übrigen denselben Weg zurück.

Die sinnvollste Lösung ist daher der manuelle DNS-Eintrag im Router (oder im worst case über die hosts Datei des Clients). Dadurch wird bereits die DNS-Abfrage nach der vermeintlichen externen DDNS-Domain mit der lokalen IP aufgelöst und der Traffic zwischen Client und Server nimmt den direkten Weg. Bei der Fritzbox muss das jedoch wie @DeusoftheWired verlinkt hat zunächst frei- bzw. abgeschaltet werden.
 
Danke für die Erklärung. Ich teste das heute Abend mal mit der Ausnahme im DNS Rebind Schutz :)

Den Client jedes mal umzukonfigurieren wäre mir zu kompliziert. Beim Browser mag es ja noch gehen wenn man im WLAN ist auf die lokale private IP zu gehen und von außen auf die DynDNS Domain. Aber die Nextcloud App auf dem Smartphone jedes mal zu umzukonfigurieren ist nicht praktikabel.
 
Intern geh ich über hosts-Eintrag am PC (damit ich den vollen Gigabit Sync habe), am Handy ist es mir eh wurscht und lasse es bei DynDNS. Sehe für mich keinen Grund das intern zu ändern, ich lad ja keine Gigabyte auf mein Handy aus der Cloud runter. Und für den Rest reichts ja völlig.
Die Nextcloud selbst kommuniziert mit Reverse Proxy und wird von der Fritze auf 8080 und 8443 am Server weitergeleitet. Würde man in der Fritze eine DNS Weiterleitung einfach einrichten können würde ich das machen, aber irgendwelche Sicherheitsfeatures zu deaktivieren sehe ich auch nicht ein. Dafür reicht der hosts Eintrag vollkommen aus an Desktops, woanders brauch ich die volle Leistung nicht.
 
Obwohl es doof ist, eine Runde durch das halbe Internet zu drehen, wenn das gewünschte Gerät nur ein paar Meter weiter von einem steht, kann man das bei Kleinkram ignorieren. Filme, Backups und alles andere Große solltest du darüber aber weder auf die Nexctcloudbüchse schieben noch von ihr herunterladen. Schiebst du im LAN einen Film über den DynDNS-Namen auf deine Nextcoudbüchse, schickst du den mit dem Upstream deines eigenen Anschlusses erst zu deinem Provider, ein bißchen durch sein Netz, (bei bekloppter Konfiguration durch den Provider auch noch durch andere Netze) und schließlich wieder zu deinem eigenen Anschluß, dessen Downstream du dafür benutzt. Du siehst, daß das von hinten durch die Brust ins Auge ist, oder? Ein Gigabitswitch im LAN macht dir das zwanzigmal schneller.

Es kommt also auf die Größe der Dateien an, die du mit Nextcloud nutzt.
 
Für große Daten hab ich noch ein OpenMediaVault :) Ausprobieren werde ich die Fritz rebind Geschichte trotzdem mal. Denn irgendwie scheint iOS mit der aktuellen konfiguration ja ein gravierendes Problem zu haben. Auf allen anderen Geräten funktioniert es einwandfrei auch wenn man dabei den Umweg übers Internet geht.
 
Bei NAT loopback sieht der Provider kein einziges Bit vom vermeintlichen Traffic über die eigene externe IP, weil der Router den Traffic selbst umdreht bevor er überhaupt den WAN-Port verlässt.

Dennoch bleibt das ein unnötiger und je nach Größe des Netzwerks auch völlig absurder Umweg, der wie oben erwähnt eben auch massiv auf die Leistung drücken kann. Selbst wenn man diese Leistung nicht braucht bzw. die NAT-Performance des Routers ausreicht, würde ich das so nicht machen. Der Sinn eines geswitchten Netzwerk ist ja gerade, dass die Pakete den direkten Weg zum Ziel nehmen und nicht mehrmals quer durch das Netzwerk geschossen werden.....

Den DNS Rebind Schutz der Fritzbox muss man dazu auch nicht komplett abschalten, sondern kann lediglich eine Ausnahme für eben diese DDNS-Domain erstellen.
 
Ich habe jetzt meine DynDNS Domain jetzt beim DNS-Rebind Schutz als Ausnahme eingetragen. So richtig habe ich noch nicht verstanden was das bewirkt. Kann das nochmal jemand für dumme erklären?

Nach einem ipconfig /flushdns und einem ping auf meine DynDNS Domain antwortet der Fritz DNS noch immer mit meiner Public IP. Im Wireshark sehe ich auch dass die TCP Verbindung zu meine Public IP geht wenn ich im Browser die Nextcloud Seite öffne.
Für die Desktop Rechner im lokalen Netz wäre das Anpassen der hosts Datei auch ein weg.
Kann man auf der Fritz im DNS nicht hart A-Records eintragen? Also abc.mydomain.de geht auf IP sowieso.

Vielleicht setze ich mir doch noch einen PiHole auf :D
 
Zurück
Oben