[Frage] 7490 NAT loopback Problem noch vorhanden bei MyFritz-Nutzung im LAN? (DNS Rebind?)

[infinity85]

Hi,

ich liebäugle damit meine 7360 SL gegen eine 7490 auszutauschen. Dabei hätte ich allerdings noch die Frage, ob die 7490 mit den neuesten Firmwares noch das NAT loopback Problem hat, dass die Daten bei Nutzung einer MyFritz DynDNS im LAN zwar korrekterweise lokal geroutet werden, aber dennoch irgendwie doppelt durch die FritzBox Firewall geschickt werden und somit die Transferrate trotz GBit LAN auf ca 3MB/s beschränkt ist.

Es ist genau dieses Problem: http://www.heise.de/forum/Netze/New...er-in-allen-Fritz-Boxen/posting-4091279/show/

Bei meiner 7360 SL konnte ich das Problem noch mit einem Workaround lösen, indem ich per Telnet die

> nvi /var/flash/ar7.cfg

bearbeitet hatte:
In der ar7.cfg musste ich den LAN Hostnamen meines servers einfach umbenennen in die komplette MyFritz DynDNS Adresse, also xxxxxxx.myfritz.net

ip = 192.168.178.10;
                name = "xxxxxx.myfritz.net";

Danach konnte ich mit dem Laptop im LAN zum Server (trotz MyFritz DynDNS) mit ca 11MB/s (statt 3 MB/s) syncen. Und außerhalb des LANs war dann meine DSl Leitungs das Limit.

In den neuesten Firmwares der 7490 gibt es ja angeblich keine Möglichkeit mehr Telnet einzusetzen bzw die ar7.cfg zu bearbeiten.

Aber da meine 7360 SL bei Fritz!OS 6.30 stehen geblieben ist, kann ich nicht prüfen, ob dieses NAT-Loopback Problem für MyFritz weiterhin bestand hat.

Die Frage:
Kann mir jemand also sagen, ob bei seiner 7490 mit Fritz!OS >6.50 die LAN Geschwindigkeit beschränkt ist, wenn man im LAN einen kleinen Server oder so stehen hat, der eine MyFritz DNS Adresse hat?
also:

• Server oder Raspberry / ähnliches ist per LAN an der Fritzbox angeschlossen
• Für den Server ist eine MyFritz Adresse eingerichtet, damit man per Clients von Unterwegs zugreifen kann
• Aber wenn man zu Hause ist, sollten die Daten nicht den Umweg übers Internet gehen (dafür das NAT Loopback)
• Und zu Hause sollte der Speed dann auch wirklich dem LAN speed entsprechen und nicht durch mehrfaches Filtern in der Fritzbox auf 3 MB/s (7360 SL) oder vielleicht 5MB/s (weil die 7490 mehr Rechenleistung hat) einbrechen

===============================================================================================================================================

Zur Vorgeschichte (etwas ausführlicher):

Da ich im LAN einen kleinen seafile server (www.seafile.com: selfhosted dropbox klon) betreibe und diesen auch per MyFritz-DynDNS von außen erreiche, habe ich zunächst mit meiner 7360 SL das Problem gehabt, dass der SyncSpeed im LAN unterirdisch bei nur 3 MB/s lag. Ohne Myfritz DynDNS - also wenn ich den Server nur fürs LAN einrichte - konnte dieser mit ca 11 MB/s syncen. Konkret geht es folgendermaßen:

1. Server steht zu Hause im WLAN und hat eine MyFritz Adresse, damit ich den auch von Unterwegs erreichen kann. Greife ich mit meinem Laptop von außerhalb auf die MyFritz Adresse zu, limitiert natürlich meine 50er VDSL Leitung (1 MB/s Upload und 6MB/s Download).
2. Sobald mein Laptop zu Hause ist und der Seafile Client auf den Server durch die hinterlegte MyFritz Adresse zugreift, erkennt das NAT Loopback, dass der Lappy im gleichen LAN ist wie der Server mit der (MyFritz DynDNS) und routet korrekterweise durch das LAN, anstatt es langsam übers Internet zu lenken.
3. Das Problem ist, dass der Speed im LAN mit 3MB/s zwar schneller ist als übers Internet (Internet 1MB/s Upload limit), aber der Server locker auch 11MB/s schaffen würde. Also gibt's einen Flaschenhals

Nach Recherche stellte sich heraus, dass die 7360 SL, aber auch alle anderen Fritzboxen bis dahin, zwar irgendwie NAT Loopack unterstützten, also bemerkten, wenn ein Gerät mit DynDNS Adresse im LAN steht und somit die Daten nicht über das Internet routeten, aber die Daten im LAN irgendwie zwei Mal oder so stumpf durch die Fritzbox Firewall schickten, wodurch sich das alles (wohl CPU Limit) verlangsamte... Der AVM support meinte Anfang des Jahres, dass es nunmal so sei und das keine Priorität hätte oder so.

• Das Problem wurde hier von einem anderen User so festgestellt und kann ich vollstens bestätigen: http://www.heise.de/forum/Netze/New...er-in-allen-Fritz-Boxen/posting-4091279/show/
• Hier hat ein Seafile User das dann auch bei Seafile bemerkt und nach Lösungen gesucht, da AVM keine Hilfestellung bieten konnte/wollte: https://forum.seafile.de/t/langsame...-fritzbox-als-fehlerursache-mit-dyndns/2376/1
• Hier wurde dann ein Workaround gepostet, der bei mir tatsächlich geholfen hat: http://www.ip-phone-forum.de/showthread.php?t=253852&p=1868095&viewfull=1#post1868095

Workaround:
Mit dem eben genannten Workaround konnte ich bei meiner 7360 SL (Fritz!OS 6.30) per Telnet (telnet über ein Dummy-Firmware-update temporär aktiviert) in der ar7.cfg die MyFritz DynDNS adresse als Hostnamen im LAN für meinen Seafile-Server in telnet festlegen. In der Fritzbox Oberfläche ging dieses Umbenennen nicht, weil wohl die Punkte in der Myfritz-DynDNS als Zeichen in Hostnamen nicht erlaubt sind.

Nachdem ich also in der ar7.cfg die myfritz dyndns als hostname der entsprechenden lokalen IP meines Servers zugeordnet habe, konnte ich mit dem Laptop im LAN zum Server (trotz MyFritz DynDNS mit ca 11MB/s (statt 3 MB/s) syncen. Das läuft bei mir bis heute so auf meiner 7360 SL und wird auch so bleiben, da es wohl keine neueren Fritz!OS mehr geben wird, als die jetzige 6.30.

Nun geht aber Telnet ja offenbar nicht mal mehr durch ein Dummy-Firmware-Update bei den neueren Fritz!OS... daher weiß ich nicht, ob das Problem bei der 7490 überhaupt irgendwie gelöst werden könnte.

Danke im Voraus für alle Hinweise :/

 

[PeterPawn]

Das wird weniger an dem Fehlen von Telnet scheitern als an der Option, dem "name"-Eintrag weiterhin "mehrstufige" Einträge unterzujubeln.

Die betreffende Sektion (landevices) in der ar7.cfg wird von der Box praktisch mit jedem neuen "neighbor" erneut geschrieben und beim Erstellen eines Eintrags findet seit einiger Zeit offenbar auch noch eine Gültigkeitsprüfung (eben auf einen gültigen Namen und da gehört der Punkt nicht zum Zeichenvorrat) statt.

Normalerweise löst man so ein Problem auch durch das Vermeiden der Namensauflösung über den DNS-Server der FRITZ!Box. Dort bringt logischerweise auch ein Eintrag in der /etc/hosts nichts, weil die für Anfragen von Clients gar nicht berücksichtigt wird und nur von einer lokalen Resolver-Lib gelesen wird.

Wenn hier schon ein zusätzlicher Server vorhanden ist, kann der ja auch einen solchen zusätzlichen DNS-Service bereitstellen (der dann auf Anfragen nach der myfritz.net-Adresse aus dem LAN mit der lokalen IP-Adresse antwortet anstelle der öffentlichen IP-Adresse der FRITZ!Box) - seit der 06.5x (aus dem Kopf, ohne mich festlegen zu wollen) kann der DHCP-Server der FRITZ!Box instruiert werden, den Clients einen anderen DNS-Server zu verkünden.

Ansonsten legt man auf dem Client automatisiert bei der Einrichtung der Netzwerk-Verbindung durch das OS einen zusätzlichen Eintrag in der "hosts"-Datei an, mit dem man die Namensauflösung über den DNS-Server verhindert, solange der Client sich in demselben Subnet befindet wie der gesuchte Sync-Host. Wenn ein Client das nicht kann (z.B. ein iOS-Gerät ohne Jailbreak), dann muß man eben doch (Variante 1) den DNS-Server ersetzen.

 

[infinity85]

Vielen Dank für die Antwort. Das Fehlen von Telnet ist also mittlerweile nicht nur das einzige Problem beim Workaround... oh man... :/

Wenn hier schon ein zusätzlicher Server vorhanden ist, kann der ja auch einen solchen zusätzlichen DNS-Service bereitstellen (der dann auf Anfragen nach der myfritz.net-Adresse aus dem LAN mit der lokalen IP-Adresse antwortet anstelle der öffentlichen IP-Adresse der FRITZ!Box) - seit der 06.5x (aus dem Kopf, ohne mich festlegen zu wollen) kann der DHCP-Server der FRITZ!Box instruiert werden, den Clients einen anderen DNS-Server zu verkünden.

Wie sähe eine Lösung dieser Art aus? Ich kenne mich da nicht aus, bzw. weiß nicht nach welchen Stichworten ich da genau suchen sollte. Ich möchte auf jeden Fall weiterhin MyFritz als DNS service nutzen. Ist mit "kann der ja auch einen solchen zusätzlichen DNS-Service bereitstellen" , dass ich bei dyndns.org oder so noch einen weiteren DNS service abonnieren muss?

Mein Server ist ein banana Pi mit ARMBian drauf, also einem Debian für ARM SOCs.

Dennoch steht die Frage noch immer im Raum, denn der Bandbreitenverlust ist ja eigentlich eher ein "Fehler" in der Firmware, oder eher eine Unzulänglichkeit.... Vielleicht wurde das Problem ja bereits gelöst und die Daten flutschen bereits ohne Bandbreitenverlust durch die 7490 mit den aktuelleren Firmwares?

Ich würde mich jedenfalls über Beiträge von Usern freuen, die entweder positives oder negatives bei Ähnlicher Konfiguration zu berichten hätten

 

[PeterPawn]

Den Standpunkt, daß es sich um einen Fehler handelt, muß man sicherlich nicht teilen.

Wenn ein Request die öffentliche IP-Adresse verwendet, denn geht der eben auch an das Interface, welches diese Adresse "trägt" und das ist nun mal das externe ... damit muß dieser Traffic wie jeder andere auch erst einmal durch das Reverse-NAT kommen.

Aber am NAT auf der Box führt dann eben auch kein Weg vorbei, es ist ja z.B. auch denkbar, daß man an der Box den Port 8888 freigegeben hat und der aber am Gerät auf den Port 88 gemappt werden soll.

All diese "Unwägbarkeiten" sind nun mal mit der Benutzung der "falschen" IP-Adresse verbunden, bei direkter Verwendung der korrekten (LAN-)IP muß der gesamte Verkehr gar nicht mehr durch die FRITZ!Box gehen (solange die nicht auch noch den WLAN-AP geben muß) und nur damit hat man die Bandbreiten-Limitierung durch das OS der Box nicht.

Ansonsten muß man auf dem Banana Pi eben einen eigenen DNS-Server installieren (von bind9 bis dnsmasq gäbe es da Möglichkeiten) und der muß dann eben die Anfragen nach den lokalen Clients über die Domain "myfritz.net" aus seinen eigenen Daten (mit der jeweiligen LAN-IP) beantworten und den Rest über einen Forwarder erledigen lassen. Wer dann diesen Forwarder gibt (die FRITZ!Box oder direkt ein Server beim Provider oder sogar Google oder OpenDNS), steht auf einem ganz anderen Blatt und hängt sicherlich auch davon ab, wie automatisch man auf Änderungen reagieren will (das naheliegendste wäre die FRITZ!Box als Forwarder für den eigenen DNS-Server auf dem BananaPi).

 

[infinity85]

Nein, als wirklichen Fehler will ich das auch nicht wirklich gemeint haben, denn es ist ja irgendwie so gewollt, und die Daten werden ja korrekt innerhalb des Lokalen Netzwerks, statt übers Internet übertragen. Jedoch halt unnötigerweise mit niedriger Geschwindigkeit. AVM könnte ja eigentlich einfach eine Abfrage in die Firmware einbauen, die das Routing komplett Intern übernimmt. Schließlich funktioniert das ja, sobald ich die ar7.cfg manuell bearbeite.

Ich kenne mich leider nicht wirklich mit den Funktionsweisen bzw. Implementierungen von NAT in Fritzboxen aus, aber da es mit dem ar7.cfg Trick funktioniert, sehe ich die von dir beschriebe Problematik mit den Ports, Reverse-NAT, dass kein Weg am NAT der Box vorbeiführt usw. nicht wirklich. Schließlich reicht ja ein simples auflösen des Hostnamens, um genau das alles zu verhindern.

Daher erneut die Frage, ob das nicht bereits von AVM schon implementiert wurde? Es ist ja nur ein Kniff im Sinne von:

1. MyFritz-Adresse wird extern von einem client mit externer IP (nicht passendes Subnet) angesprochen: Box leitet die Daten über den vorgegebenen HTTPS Port 443 an den dahinterliegenden Server durch.
2. MyFritz-Adresse wird von einer lokalen IP (selbes Subnetz) angesprochen: Box setzt interne Route, da DynDNS Ursprung selbes Subnetz hat wie Lokales Netzwerk, also einfach Hostnamen matchen und schon gibts keine Flaschenhälse.

Das dürften doch nur 2 Codezeilen sein. Oder es würde sogar reichen die Punkte als Sonderzeichen zuzulassen und den Hostnamen somit mit dem Selben Namen wie die MyFritz Adresse zu erlauben oder im Hintergrund das trotz verbotener Sonderzeichen selbst zu machen.

Soweit ich weiß gibt es ja Router, die genau dieses Problem nicht haben. Dafür ist doch NAT Loopback eigentlich da, oder etwa nicht? Es ist nur ungenügend implementiert, was ja der lächerlich simple Kniff mit ar7.cfg zeigt?

Oder verstehe ich irgendwas grundsätzlich falsch? Das Portforwarding ist dann doch gar kein Thema in diesem Fall? Dies wird doch komplett umgangen, oder nicht?



EDIT
Leider verstehe ich das mit DNSMasq und dem Forwarder nicht so ganz. Bzw eigentlich verstehe ich das schon. Nur verstehe ich nicht, wie das mit dem in der Fritzbox eingebauten MyFritz gehen soll? Mit einem externen DynDNS service sollte es ja klappen, wenn der Banana Pi das DynDNS zeugs übernimmt, aber ich kann auf dem ja kein MyFritz DNS einrichten, das ist ja an die Fritzbox gebunden, oder nicht?

 

[PeterPawn]

Ich behaupte mal: "oder nicht".

Aber das kannst Du ja ganz einfach probieren ... wenn Du Deinen Service im LAN auf einem Port betreibst, der nicht 1:1 dem auf der FRITZ!Box freigegebenen Port entspricht (denn dieser Dienst muß ja irgendein Forwarding benutzen, wenn er extern verwendbar sein soll), dann sollte der Zugriff aus dem LAN über den externen Port der FRITZ!Box weiterhin funktionieren, aber nicht mehr, wenn Du den internen Port zusammen mit der myfritz.net-Adresse verwendest oder die interne Adresse mit dem externen Port.

Das, was Du da gerne hättest, nennt sich bei bind9 dann "view" und ist schon für ausgebildete DNS-Admins nicht immer ganz leicht zu betreiben (besonders bei der Fehlersuche). Das gibt es (m.W.) auf der FRITZ!Box nicht und wie bereits geschrieben, würde ein nicht 1:1 umgesetztes Port-Mapping automatisch auch dagegen sprechen, daß man da eine unveränderte Adresse von intern und von extern gleichzeitig benutzen kann, wenn das nicht über "NAT hairpinning" auf dem Router geregelt wird. Dort wird dann eben sowohl die Adresse als auch der Port "umgeschrieben", man sollte es schon daran sehen, daß solche Zugriffe auf den Server dann mit der IP-Adresse der FRITZ!Box und nicht der des Clients erfolgen.

Was macht man, wenn man zwei verschiedene Server in seinem LAN betreibt, die jeder einen Service auf ihrem lokalen Port 80 ins WAN über eine FRITZ!Box bereitstellen sollen? Dann geht ohne ein abweichendes Mapping für mind. einen der beiden nichts mehr.

Dein fett hervorgehobener Satz in #5 verdeutlicht den Irrtum schon hervorragend ... das hat nämlich zur Zeit bei Dir mit dem FRITZ!Box-Routing gar nichts mehr zu tun. Durch die Änderung in der ar7.cfg wurde nicht die Route irgendwelcher Pakete geändert, es wird die Zieladresse beeinflußt, weil der DNS-Server des FRITZ!OS für eine Abfrage nach "xxxx.myfritz.net.fritz.box." (das wäre der "FQDN" so eines Hosts) die interne IP-Adresse liefert anstelle der externen und damit der Verkehr (wenn die beiden Hosts sich in einer Broadcast-Domain und einem IP-Subnetz befinden, mithin die MAC-Adresse zur IP-Adresse über ARP zu ermitteln ist) gar nicht mehr bei der FRITZ!Box vorbeikommt. Das ist also mehr ein "Unfall" und genau einen solchen Unfall erneut zu erzeugen, bezweck(t)en die beiden Alternativen, die ich Dir vorgeschlagen habe.

Bisher nutzt Du eine Fehlfunktion der FRITZ!Box aus ... daraus kann man auch keine sinnvolle Implementierung bauen (zumindest dann nicht, wenn es kein 1:1-Mapping des Ports gibt und das ist auch die Voraussetzung, damit der Vorschlag mit einem anderen DNS-Server mit passenden "views" überhaupt greifen kann) und schon gar keine, die für viele Leute eine sinnvolle Funktion ergibt.

Auch die Feststellung "MyFritz-Adresse wird extern von einem client mit externer IP (nicht passendes Subnet) angesprochen:" verstehe ich nicht ... wenn Du hier eine IP-Adresse meinst mit "MyFritz-Adresse", dann kann doch die Box gar nicht mehr wissen, über welchen Namen diese (IPv4-)Adresse aufgelöst wurde und wenn ein externer Host den DNS-Namen "abc.myfritz.net" auflösen will, dann fragt der doch nicht die FRITZ!Box, sondern den DNS-Server von AVM für die Domain "myfritz.net". Die IP-Adresse nach außen ist doch für alle "MyFRITZ!-Services", die Du da vielleicht freigegeben haben könntest, immer dieselbe (eben die externe IP-Adresse der FRITZ!Box) und über IPv6 (wo der Host im LAN dann vielleicht tatsächlich seine eigene IPv6-Adresse hat) kannst Du ja eigentlich nicht schreiben, wenn hier von "NAT" die Rede ist.

 

[infinity85]

hmm okay... ich habe da einfach zu wenig Hintergrundwissen dafür :/...

Danke auf jeden Fall für die ausführlichen Antworten! Das hilft schon mal weiter, damit ich weiß wo ich anknüpfe um über das ganze mal zu recherchieren.

Was erstmal hängengeblieben ist, ist die Tatsache, dass ich ja tatsächlich durchs Bearbeiten der ar7.cfg das ganze mit dem NAT umgehe und das auch genau so möchte. Im LAN ändert sich ja dadurch nichts an der Tatsache, dass jeder Rechner seine eigene IP hat und somit auch keine Konflikte entstehen.

Meine ursprüngliche Frage kann ich glaub ich trotzdem erneut an alle stellen (entschuldige, falls ich nicht bemerkt habe, ob du sie eigentlich schon beantwortet hast, da ich bei den Fachbegriffen (NAT hairpinning, bind9 view, FQDN) die Bezüge zu meinen Fragen nicht immer erkenne):

Hat jemand MyFritz am laufen und kann etwas von der Performance im LAN berichten? Ich finde im Netz nur berichte, die mindestens 1 bis 2 Jahre zurückliegen und somit vielleicht schon lange keine Gültigkeit mehr haben.


EDIT:

Ich bin eben über folgenden Artikel gestolpert:

https://adrian-jagusch.de/2015/03/domains-abfangen-mit-der-fritzbox-als-dns-server/#comment-521

Dort beschreibt einer, wie man mit dem FBEditor die ar7.cfg ohne Telnet bearbeiten kann. Ich habs eben ausprobiert auf meiner 7360 SL mit Fritz!OS 6.30 indem ich einfach mal bei einem meiner Geräte, die einen einfachen Hostnamen RASPBERRY in RASPBERRY.PI geändert habe (der Punkt dürfte ja eigentlich nicht möglich sein). Und die Box hat es akzeptiert und der name ist nun tatsächlich unter Heimnetz mit dem Punkt aufgeführt. Danach hab ichs natürlich in der Weboberfläche wieder Rückgängig gemacht.

Kann vielleicht jemand mit Fritz!OS 6.60 testen, ob das bei ihm auch möglich ist mit dem FBEditor? Man kanns ja mit einem Phantasienamen probieren... hauptsache ein Punkt ist drin. Danach kann mans manuell wieder rückgängig machen in dem Webinterface. Wäre klasse, wenn das ginge

Falls es klappen sollte, wäre natürlich die Frage, ob das auch nach dem Anmelden eines neuen Gerätes weiterhin bestand haben würde, weil PeterPawn in Post #2 ja gesagt hat, dass die Datei immer wieder überschrieben und auf checksum geprüft wird, sobald ein neuer Hostname auftaucht.

 

[infinity85]

[...]

Die betreffende Sektion (landevices) in der ar7.cfg wird von der Box praktisch mit jedem neuen "neighbor" erneut geschrieben und beim Erstellen eines Eintrags findet seit einiger Zeit offenbar auch noch eine Gültigkeitsprüfung (eben auf einen gültigen Namen und da gehört der Punkt nicht zum Zeichenvorrat) statt.

[...]

Tjoa... Durch die Erkenntnis, dass der FBEditor die ar7.cfg ohne telnet auslesen kann, habe ich mir nun eine 7490 zugelegt und kann direkt bestätigen, dass diese dumme Gültigkeitsprüfung auch auf diesem Wege das Ganze verhindert. Du hattest völlig recht... Sobald ein Sonderzeichen drin ist, wird der "name"-Eintrag einfach gelöscht.

Gibt es einen Ansatz, wie oder wo man diese Gültigkeitsabfrage evtl deaktivieren könnte? . Vielleicht ein Stichwort unter dem man ggf. bereits dazu vorhandene Foreneinträge finden könnte?


EDIT
Wäre das Umleiten der DynDNS adresse im LAN durch bearbeiten der ar7.cfg (landevices - Sektion) mit einer Freetz Firmware oder ähnlichen Modifikationen wieder möglich, oder kann diese Gültigkeitsprüfung aug Sonderzeichen nicht abgestellt bzw. umgangen werden?