Geräte nicht nur über IP-Adresse aufrufen?

[new Account()]

Es gibt jedoch auch Geräte, die sich zwar beim DNS mit ihrem Namen registrieren, selbiger ist aber nicht konfigurierbar und dann steht da sowas wie "EinDrucker_4711", wobei die 4711 keine Modellnummer, sondern zB Teil der Seriennummer ist. Auch nicht wirklich intuitiv, oder?

Ist es nicht, aber wenn das der Fall ist, kann er das problemlos im Webinterface des Routers anpassen.

Beispielsweise wenn man von unterwegs mit einer DDNS-Domain auf das Heimnetzwerk zugreifen will und auf dem heimischen Sofa dieselbe DDNS-Domain nutzen möchte, ohne den Umweg quer durch die Bude über den WAN-Port des Routers zu gehen, sondern stattdessen direkt auf die IP des Zielgeräts.

? Wie geht das?
Wenn z.B. MyServer.com auf 192.168.1.2 zeigt, hilft mir das unterwegs afaik gar nicht, und ich müsste daher zumindest zwei subdomains einführen: local.myserver.com und remote.myserver.com - oder nicht?

Aber ist das nicht eh ein gelöstes Problem, dank NAT-Loopback?

ist ja nu kein Ding im DHCP eine IP zu reservieren - kann man im Falles eines Falles die IP als Fallback nutzen

Würde ich als unnötige Arbeit ansehen:
Wenn man eh Namen verwendet, wird man sich die Zahlen noch schlechter merken können. Daher würde man in dem Szenario das wohl irgendwo als Infos ablegen müssen, und bei Bedarf wieder rauskramen müssen. Wenn man das macht, kann man auch gleich im Webinterface die aktuelle IP anschauen.

 

[Raijin]

? Wie geht das?
Wenn z.B. MyServer.com auf 192.168.1.2 zeigt, hilft mir das unterwegs afaik gar nicht, und ich müsste daher zumindest zwei subdomains einführen: local.myserver.com und remote.myserver.com - oder nicht?

Aber ist das nicht eh ein gelöstes Problem, dank NAT-Loopback?

Nope.

Wenn du einen DDNS benutzt, weil du beispielsweise einen Minecraft-Server hostest, dann würdest du von unterwegs ja mein.ddns.bla bei der Verbindung eingeben. Wenn du aber zu Hause bist und auch auf dem Server spielen willst, müsstest du die lokale IP / Namen des Server eingeben. Hast du nun aber im lokalen DNS-Server einen manuellen Eintrag - oftmals einfach nur über die dortige hosts-Datei realisiert - würdest du auch von daheim mein.ddns.bla benutzen können, weil der heimische DNS dann explizit nicht die WAN-IP der DDNS-Domain zurückgibt, sondern stets die lokale IP. An dieser Stelle greift aber der DNS-Rebind-Schutz der Fritzbox, weil eine vermeintlich öffentliche Domain nicht auf eine lokale IP aufgelöst werden darf.

Bei NAT-Loopback wird kein lokaler DNS-Eintrag benötigt, soweit so gut. Also wird die Domain mein.ddns.bla vom DNS-Forwarder im Router an den Provider-DNS weitergeleitet und darüber dann auf die aktuelle WAN-IP des Routers aufgelöst. Da diese aber nach wie vor "im Internet" liegt, schickt der Client nun alle seine Daten erstmal zum Router. Dieser schiebt auch jedes Paket erstmal in die WAN-Queue und merkt dann im letzten Moment vor dem Abschicken an das Provider-Gateway, dass das ja seine eigene WAN-IP ist. Hey, cool, also um 180° gedreht und ab mit dem Paket in die NAT-Pipeline. Also Portweiterleitung und alles drumherum. Funfact: Wenn man die Portweiterleitung auf eine Source-IP gematched hat (zB Büro-IP-only), wäre an dieser Stelle sogar Schluss, weil die Source-IP ja der Router selbst ist (hat er ja bereits "ausgehend" geNATtet).

Auf den ersten Blick klingt das alles super. Problematisch wird es dann, wenn es sich nicht um ein banales Spiel wie Minecraft handelt, sondern eine bandbreiten-hungrige Anwendung. Der Router wird nämlich bei NAT-Loopback jedes einzelne Paket durch die Portweiterleitung jagen und somit im worst case auch an seine WAN<>LAN Routing-Performancegrenze stoßen. Zudem nehmen die Pakete je nach Infrastruktur einen großen Umweg quer durch das Haus (zB Dachgeschoss -> Keller -> Dachgeschoss) obwohl der Server vielleicht nur 2 Meter entfernt am selben Switch hängt wie der Client.

Fazit: NAT-Loopback ist eine Krücke.


Zum Rest: Ich denke das ist Geschmackssache. Deine Argumente kann ich nachvollziehen und auch weitestgehend unterschreiben. Ich bin es gewohnt, massiv mit IPs zu arbeiten, weil ich beruflich mit buchstäblich Hunderten VPN-Verbindungen zu tun habe - da helfen Namen herzlich wenig

Daher würde man in dem Szenario das wohl irgendwo als Infos ablegen müssen, und bei Bedarf wieder rauskramen müssen.

Du meinst, dass man das Netzwerk sogar dokumentieren müsste? Geht ja gar nicht, Blasphemie!

 

[Pandora]

Das geht so leider nicht. Der Name der da anscheinend standardmäßig eingetragen wurde (ck-plus) funktioniert nicht; ich gebe in den Browser: "ck-plus.local" ein.

Der Terminus lautet NAME.fritz.box also z.b. cloudkey.fritz.box

 

[new Account()]

Hast du nun aber im lokalen DNS-Server einen manuellen Eintrag - oftmals einfach nur über die dortige hosts-Datei realisiert - würdest du auch von daheim mein.ddns.bla benutzen können

So haut das hin.

Auf den ersten Blick klingt das alles super. Problematisch wird es dann, wenn es sich nicht um ein banales Spiel wie Minecraft handelt, sondern eine bandbreiten-hungrige Anwendung.

Dann hat man aber auch keinen Bedarf an externem Zugriff, oder?
Wenns im Heimnetz problematisch wird, dann erst Recht, wenns übers Internet läuft.

Klar, nicht perfekt, aber die drawbacks dürften daheim auch egal sein
Trotzdem gut zu wissen, danke

Du meinst, dass man das Netzwerk sogar dokumentieren müsste? Geht ja gar nicht, Blasphemie!

Also ich mach mir ja keinen unnötigen Aufwand - was beim Heimnetz bzgl. Dokumentation (die über das Webinterface des Routers hinausgeht) meistens zutreffen dürfte...

Ergänzung (3. Dezember 2019)

Der Terminus lautet NAME.fritz.box also z.b. cloudkey.fritz.box

cloudkey bzw. http://cloudkey sollte auch hinhauen

 

[Raijin]

Wenn die DNS Suffix-Suchliste aktiviert und korrekt konfiguriert ist, also fritz.box enthält, wird eben dieses fritz.box implizit an den Namen angehängt bevor der DNS-Request abgeschickt wird. Ein "nslookup cloudkey" würde dann den DNS-Request "cloudkey.fritz.box" zur Folge haben. Ist die Suchliste leer oder deaktiviert, muss man fritz.box selbst anhängen. Da können übrigens auch mehrere Einträge drinstehen, die dann nacheinander abgearbeitet werden, um einen Treffer zu landen.

Das erklärt auch warum hier im Thread teilweise davon die Rede ist, dass man fritz.box anhängen muss, aber andererseits in anderen Posts zu lesen ist, dass es bei demjenigen auch ohne geht. --> Mal steht fritz.box in der Suchliste, mal nicht.

Zu finden ist die DNS Suffix-Suchliste übrigens bei "ipconfig /all" ganz oben. Ändern kann man sie mit gpedit.msc (muss ggfs nachinstalliert werden).

Dann hat man aber auch keinen Bedarf an externem Zugriff, oder?
Wenns im Heimnetz problematisch wird, dann erst Recht, wenns übers Internet läuft.

Klar, nicht perfekt, aber die drawbacks dürften daheim auch egal sein

Das Ding ist ja, dass durch NAT-Loopback eine Verbindung, die gar nicht über den Router und schon gar nicht durch dessen WAN-Interface gehen müsste, eben genau in diese Richtung gezwungen wird. Zudem wird der Router unnötig mit Traffic belastet, den er in einem geswitchten Netzwerk niemals zu Gesicht bekäme.
Bei einem schnellen Router, der einen hohen WAN<>LAN Durchsatz hat, merkt man davon tendentiell natürlich weniger. Router aus dem Mittelfeld, die zB nur 100-250 Mbit/s WAN<>LAN schaffen, bremsen eine Verbindung, die direkt 1 Gbit/s schnell sein könnte, schön runter, wenn man den Weg des NAT-Loopback wählt und eben nicht mit lokalen DNS-Einträgen arbeitet. Wie dem auch sei, das geht nu ein wenig am eigentlichen Thema vorbei bzw. darüber hinaus.