[Frage] Gibt es schon eine Lösung für "400 Bad Request" für 7490 Laborfirmware?

[koyaanisqatsi]

Moin


Übrigens auch bei "Doppel NAT" ganz ohne DynDNS...

( 7590 mit 7.01 mit aktivierten HTTPS Fernzugang auf Port 443 )
...von NAT 1 nach NAT 2 ( Nur bei HTTPS ).
Wenn der von NAT 1 vergebene Hostname benutzt wird.
Und natürlich steht dieser Hostname nicht bei den "alternativen Namen" im Zertifikat.

 

[hyphone]

@PeterPawn ja klar, vertan - es geht wirklich um den hier diskutierten Fehler 400! (und nicht "not found")

 

[odoll]

Tatsächlich kann man das Problem auch umgehen, indem man einfach "localhost" in diese Ausnahme-Liste zum neuen DNS-Rebind-Schutz (FB Netzwerkeinstellungen ganz unten) einträgt - zum Glück auch ohne Restart. Das Problem hängt also eindeutig damit zusammen.

Ich würde allerdings sagen, das ist ein "Bug" bzw. ein ungewollter Nebeneffekt dieser Schutzfunktion? Denn zumindest oberflächlich ist dabei ja nur von einer Anpassung der DNS-Auflösung die Rede, die hier gar nicht im Spiel ist. Doch die Liste wird offensichtlich auch verwendet, um für eine (neue) Prüfung des Host-Header bei internen Anfragen Ausnahmen zu bekommen.

Also nochmal zusammengefasst: anders als die anderen in diesem Thread komme ich _nicht_ direkt von aussen, ich habe den Fernzugang nicht konfiguriert. Ich komme über einen internen Server via Port-FW defakto "von innen"! Trotzdem behindert einen dabei der neue Rebind-Schutz, Lösung siehe oben. Vermutlich bin ich da ja auch nicht der einzige und vielleicht hilft das mal jemandem.

Nun, das Problem habe ich ja schon auf der Zielgeraden zu jeder der Laborversionen angemeckert. Nur hilft es in meinem Fall leider nicht meine (offizielle) Domain oder die von mir für die FBen vorgegebenen FQDNs im Rebind-Schutz einzutragen. (Ein dnsmasq ist bei mir im lokalen Netz für dhcp zuständig. Meine offizielle Domain zeigt auf meine offiziellen IPs (Provider Independent), bzw. sind auch die PTR-Records "kongruent" öffentlich im in-addr.arpa. Name Space definiert. Nur die GUI der einen 7490 im IP-Client-Modus kann ich lokal mit Ihrer FQDN nutzen, statt wie die auf L3 "forwardenden" 7490 und 6490 nur mit ihrer IP-Adresse.)

PS: In der Konfigurationseinstellung unter Heimnetzfreigabe und auch als FRITZ!Box-Name sind brav die Namen der FBen wie auch im DNS a la "name A 194.x.y.z" eingetragen (sowie die bei mir verwendete samba Domain als Arbeitsgruppe)

 

[hyphone]

@odoll
Ich bin jetzt nicht wirklich in der Lage anhand Deiner Ausführungen das Setup im Detail zu verstehen, aber ich interpretiere mal zumindest soviel:
Bei Dir geht es wirklich um 100% interne Zugriffe aus dem LAN auf die FB-GUI (nicht wie bei mir via port-forwarding über eine ssh-Sitzung). Sobald man statt der internen IP der FB einen dafür definierten Domainnamen (FQDN) nutzt, gibt es auch den "bad request". Naja, auch da steht dann eben der DN im Host-Header des Request (und auch da könnte also HTTP 1.0 helfen, falls Du es testen willst). Die FB prüft offensichtlich den Host-Header und versucht dann vermutl. den DN aufzulösen (bei mir "localhost"). Und da greift dann dieser Rebind-Schutz und ein Eintrag in der Ausnahme-Liste sollte eigentlich helfen. Ohne ist ja die Frage, wie die FB den Namen überhaupt auflösen soll, wenn das im LAN ein dnsmasq tut - oder hat die FB diesen als Nameserver eingetragen? Aber auch wenn - irgendwie gehts ja mit dem Rebind-Schutz darum, dass die FB eben keine Namen auf LAN-IPs auflösen will (aus Gründen, mit denen ich mich jetzt nicht wirklich tiefer befasst habe).
Was mit "forwarden auf L3" gemeint ist weiss ich nicht, da könnten mir auch die Grundkenntnisse fehlen..

 

[odoll]

Hallo, ich denke Du hast mein "krudes" Setup schon gut verstanden, aber denke, das Problen liegt nicht im Rebind-Schutz begraben, denn der funktioniert bei mir IMO wie gewünscht:

Z.Z. ist es bei mir so, dass der dnsmasq die IP der 6490 sowohl als Default-GW als auch DNS-Server an die Klienten im LAN per DHCP zuweist. Und da meine Domain als Ausnahme im Rebind-Schutz eingetragen ist, werden Anfragen an diese von ihr auch korrekt mit der richtigen IP im LAN beantwortet, auch die ihres eigenen FQDNens. (denn sonst bekäme ich den Fehler nicht, da der Aufruf ja gar nicht an die FB ginge)

IMO bist Du mit dem Host-Header schon auf der richtigen Spur: Nach meiner Vermutung beantwortet der Webserver der FB im IP-Client-Modus alle Anfragen, unabhängig vom HH. [*]
Allerdings scheint AVM dieses Verhalten für FBen im "Router-Modus" (auf fritz.box und localhost?) eingeschränkt zu haben?!
Es fehlt die Möglichkeit der FB ihren (tatsächlichen) FQDN, oder ihre Domain mitzuteilen. (aus letzteren und ihrem Namen, könnte sie ihn ja selbst für ihre Webserver ACL zusammen setzen)

[*] es macht übrigens keinen Unterschied, ob die IP der IP-Client fest eingetragen ist oder auch per DHCP gelernt wird, wo der Domain-Name auch genannt wird.