[Frage] Port forwarding verhält sich seltsam: Externer Name führt auf Admin-UI

[daubsi]

Hallo Forum,

ich habe seit einigen Wochen ein Problem mit meiner FB/Port-Forwading/Namensauflösung, was ich mir nicht erklären kann und vermute, dass dies durch eine Änderung im FritzOS kam. Würde gerne wissen, ob noch jemand dieses Problem hat.

Zunächst: Ich nutze seit gut 7 Jahren diverse Fritzboxen, kenne mich also durchaus mit deren Konfiguration aus, auch was das Port-Forwarding angeht.

Zu meinem Setup:
Die Fritzbox ist rein Gateway zum Internet. Für DHCP und DNS wird NICHT die FB verwendet, sondern mein Linux-Server im internen LAN. Um diesen Server (192.168er Adresse) aus dem Internet zu erreichen gibt es z.B. Port forwarding rules in der Firtzbox die Port 443 und 22 auf diesen Server aus dem Internet weiterrouten. Für den DNS-Namen im Internet nutze ich DynDNS, d.h. ich kann meinen Server im Heimnetz via https://<meinserver> erreichen.
Funktioniert problemlos und so wie es soll.

Jetzt war es auch immer so, dass ich im Homelan über https://<meinserver> (also den Alias für die externe IP) meinen Server erreicht habe. Die Requests sahen so aus, als würden die Anfragen aus dem Internet kommen. Das war zwar etwas unschön, weil ich einen PW Dialog vorgeschaltet hatte, den ich ja aus dem internen Netz nicht brauchen würde, aber ok.
Heisst also: Auch aus dem internen Netz konnte ich z.B. https://<meinserver>/owncloud ansprechen und es funktionierte.

Nun zum eigentlichen Problem.
Seit einigen Wochen funktioniert der interne Zugriff nicht mehr verlässlich. Mit einer 50:50 Chance kommt tatsächlich die Seite des internen Servers, wenn ich eine URL anklicke und in in den anderen Fällen kommt die Web-Admin-Anmeldemaske der Fritzbox mit Username/PW! Der Zugriff auf htts://<meinserver> von extern funktioniert so wie es soll!

Das verstehe ich nicht den:
a) Meine Anmeldemaske beim internen Zugriff auf das AdminUI hat regular nur ein PW Feld. Hier ist es Username und PW. Ich vermute, dass es sich somit um das ins Internet sichtbare AdminUI handelt.
b) Darüberhinaus ist mein Admin UI ins Internet DEAKTIVIERT - trotzdem wird es hier dann angezeigt.
c) Eigentlich sollten die Port-Forwarding Regeln ja die HTTPS Requests transparent an den eigentlichen Server weitergeben und somit erst recht nicht die ohnehin deaktivierte Login-Seite der FB kommen. Das scheint aber beim internen Aufruf (manchmal!) nicht zu funktionieren.
d) An meiner Netzkonfiguration hat sich seit Monaten nichts geändert.
e) Manchmal kommt es dann nach 2,3 Reloads wieder und es kommt die "echte" Webseite. Auf einmal dann wieder die FB Seite beim Navigieren.

Ich kann mir das im Moment echt nicht erklären und habe die Vermutung, dass sich im Fritz-OS was geändert hat, dass Requests aus dem internen Netz an die externe IP/DynDNS Namen nicht immer durch die Port-Forwarding-Rules laufen.

Hat hier irgendjemand ne Idee?

 

[thtomate12]

Wenn dein Linux-Server DNS-Server ist warum löst er intern seinen nicht die interne IP auf?

 

[sf3978]

Für DHCP und DNS wird NICHT die FB verwendet, sondern mein Linux-Server im internen LAN.

Welche Software (Server) wird auf deinem Linux-Server, für DHCP und DNS verwendet?

Jetzt war es auch immer so, dass ich im Homelan über https://<meinserver> (also den Alias für die externe IP) meinen Server erreicht habe.

Wie wird in deinem Homelan, die Namensauflösung (DNS) für "https://<meinserver>" gemacht?

 

[daubsi]

Weil der Linux-Server ja nicht die Hoheit über die Domain *.homelinux.org von Dyn hat, in der ich meine dynamische Adresse bei der Verbindung mit dem Internet registriere. Der DNS-Server handelt nur für die interne DNS-Zone/Domain und als forwarding resolver für den "Rest" des Internets.

Der Apache auf dem internen Server hat einen entsprechenden VirtualHost/NameAlias Eintrag für den externen Namen. Apache-seitig ist aber auch alles OK.

 

[daubsi]

Welche Software (Server) wird auf deinem Linux-Server, für DHCP und DNS verwendet?

isc-dhcp-server für DHCP und bind für DNS.

Wie wird in deinem Homelan, die Namensauflösung (DNS) für "https://<meinserver>" gemacht?

"Gar nicht". Die Adresse wird wie jede andere Internet Adresse auch aufgelöst, und zeigt auf meine externe IP des externen Interfaces der FB.

 

[sf3978]

"Gar nicht". Die Adresse wird wie jede andere Internet Adresse auch aufgelöst, und zeigt auf meine externe IP des externen Interfaces der FB.

OK, und weil deine FritzBox ja "Hairpin-NAT" kann bzw. macht, solltest Du auch in deinem Homelan deinen Linux-Server, mit der externen/öffentlichen IP-Adresse deiner FritzBox, erreichen können.
Wenn das z. Zt. nicht so ist oder nicht richtig funktioniert, könnte z. B. evtl. der dns-rebind-Schutz in deinem Homelan, zuständig/verantwortlich sein. Hast Du in letzter Zeit, den bind-Server updatet? Evtl. auch mal mit einer Ausnahme-Eintragung, beim dns-rebind-Schutz der FritzBox, versuchen.

 

[daubsi]

OK, und weil deine FritzBox ja "Hairpin-NAT" kann bzw. macht, solltest Du auch in deinem Homelan deinen Linux-Server, mit der externen/öffentlichen IP-Adresse deiner FritzBox, erreichen können.

Exakt. So war es bislang und so soll es sein. Klappt aber halt auf einmal nicht mehr immer.

Das mit dem DNS Rebindschutz habe ich in der FB Oberfläche gesehen und jetzt mal für mein internes LAN und den externen Namen die Ausnahmen definiert. Das mit dem Rebind soll sich aber doch nur auswirken, wenn der DNS der FB genutzt wird, oder? Der ist ja wie gesagt, nirgends in Benutzung. Gestern hat die Namensauflösung mal wieder geklappt. Mal sehen.

 

[daubsi]

OK, und weil deine FritzBox ja "Hairpin-NAT" kann bzw. macht, solltest Du auch in deinem Homelan deinen Linux-Server, mit der externen/öffentlichen IP-Adresse deiner FritzBox, erreichen können.

"Hairpin-NAT"... interessant, diesen Ausdruck kannte ich noch gar nicht. Aber ja, ist genau das, was sie machen soll.
http://wiki.mikrotik.com/wiki/Hairpin_NAT

 

[daubsi]

Hab zu dem Thema nochmal ein bisschen gesucht und gesehen, dass ich da ja offenbar nicht der einzige mit diesem Problem bin:
http://www.ip-phone-forum.de/showthread.php?t=93792&page=2

Allein, es erklärt nicht, warum es nun auf einmal nicht mehr funktionieren soll. Die Posts sind ja relative alt.. - und wie sf3978 oben schreibt, soll es ja auch gehen?

 

[sf3978]

Das mit dem Rebind soll sich aber doch nur auswirken, wenn der DNS der FB genutzt wird, oder?

Ja, das sollte so sein, nur wenn der DNS der FritzBox genutzt wird. Aber evtl. weiß man nicht was die FritzBox macht, wenn die interne IP-Adresse des Servers als externe IP-Adresse (source-NAT), dem Client im (W)LAN mitgeteilt wird. Es sollte ja nur getestet werden.
Evtl. macht auch dein bind (nach einem update) im LAN (jetzt per default) "stop-dns-rebind" und dann Du in der config des bind, evtl. eine Ausnahme für dein LAN oder einzelne Clients in deinem LAN, eintragen.

 

[PeterPawn]

habe die Vermutung, dass sich im Fritz-OS was geändert hat, dass Requests aus dem internen Netz an die externe IP/DynDNS Namen nicht immer durch die Port-Forwarding-Rules laufen.

Seit 06.20 stellt AVM ja die Dienste des FRITZ!Box-GUI auch per HTTPS im internen Netz bereit. Der Standard-Port dabei ist natürlich TCP/443.

In der letzten Release-Version der 7490 (06.23) ist das sogar ordentlich gesondert einstellbar - auch wenn der externe Zugriff nicht aktiviert ist - und es werden auch die internen Adressen der FRITZ!Box inzwischen dort aufgeführt (auch wenn die "fritz.box"-Adresse natürlich von der Nutzung des DNS-Servers in der Box selbst ausgeht):

http://fritz.box/internet/remote_https.lua

Anhang anzeigen 80618

Vorher war die Kopplung an den HTTPS-Port des externen Interfaces nur implizit und der Port ließ sich nur ändern, wenn man wenigstens kurzzeitig den externen Zugriff aktivierte.

Ich würde trotzdem den HTTPS-Port umstellen, wenn Du eine Portweiterleitung für 443 auf einen Server im LAN verwenden willst.

Die Ursache der unterschiedlichen Reaktion der FRITZ!Box auf Anfragen an ihre externe IP-Adresse unter Port 443 würde ich irgendwo bei unterschiedlichen Zuständen im Packet-Accelerator suchen. Ob allerdings das Umstellen des Ports tatsächlich hilft, diesen Konflikt im internen Routing zu vermeiden, bin ich mir auch nicht sicher. In jedem Falle sollte aber eine Änderung des Verhaltens erfolgen, ob das dann schon (durch Wiederholung seitens des Browsers) immer zum richtigen Ergebnis führt, ist auch schwer zu sagen.

Das hängt wahrscheinlich von den konkreten Umständen ab ... ich stelle mir das im Moment so vor, daß ein Teil der Pakete tatsächlich zum DSLAM geschickt wird und von dort dann eben wieder an die Box zurück, wo dann das Portforwarding greift (das sind für mich die Verbindungen, die "beschleunigt" sind, da dabei wohl die Zielabfrage nicht mehr "in der Box" stattfindet und damit nicht dort schon festgestellt wird, daß es eigentlich um Pakete an die eigene IP-Adresse geht). Der andere Teil wird dann - um erst einmal eine "beschleunigte Verbindung" einzurichten - durch den kompletten IP-Stack der Box gejagt und dabei dann anhand der Zieladresse die Box selbst als Ziel ausgemacht. Wenn das "unterhalb" der Portforwardings erfolgt, landet das Paket auf der Box selbst und nicht am eigentlichen Ziel.

Wenn diese Vermutung stimmen sollte, müßte der erste Verbindungsversuch - nachdem man sich vergewissert hat, daß der PA keine aktive Verbindung mehr hat - eigentlich immer auf dem FRITZ!Box-GUI landen. Wird dabei dann trotzdem eine "fast lane" für diese Verbindung eingerichtet, geht der nächste Verbindungsversuch u.U. bis zum DSLAM und kommt von dort zurück, wobei er dann auch über das Portforwarding läuft.

Da Du ja offenbar durchaus in der Lage bist, mit einem Traffic-Analyzer umzugehen, würde ich an Deiner Stelle mal einen Mitschnitt auf der externen Schnittstelle der Box machen (1. Internetschnittstelle) und mir ansehen, ob und wenn ja welche Pakete für die eigene öffentliche IP-Adresse da rausgehen. Auch ein paralleler Mitschnitt an der "Routing-Schnittstelle" wäre ein interessanter Punkt, denn dort sollte auch der "interne Verkehr" noch zu sehen sein, der dann zum Aufruf des FRITZ!Box-GUI führt (also "Routing = 1. Internetschnittstelle + interner Verkehr an die eigene öffentliche IP-Adresse"). Das Dumme ist halt nur, daß hier wahrscheinlich die Messung das Ergebnis schon beeinflußt, wenn der PA im "Packet-Dump"-Modus läuft. Wenn ich die Theorie dahinter richtig verstehe, müßte allerdings ein tcpdump auf "dev dsl" nur die initialen Pakete anzeigen (dabei wird dann die beschleunigte Verbindung eingerichtet) und der Rest geht dann an der Routing-Schnittstelle vorbei (weil tcpdump den PA ja nicht umschaltet).

Aber der PA ist ja eigentlich nicht neu ... insofern ist das ältere Verhalten der Firmware und das neuere nicht nur durch die reine Existenz des PA zu erklären. Wenn aber z.B. aus irgendeinem Grund eine Reihenfolge bei der Einrichtung einer "accelerated connection" geändert wurde und damit jetzt - fälschlicherweise oder nicht, darüber kann man trefflich streiten, denn die "Ansprache" der FRITZ!Box mit der öffentlichen IP-Adresse ist ja auch ein zweischneidiges Schwert - eine solche Verbindung auch dann eingerichtet wird, wenn es eigentlich lokaler Traffic ist, dann wäre das eine logische Erklärung. Und bei der Reaktion der FRITZ!Box auf eine Anfrage an ihre externe Adresse aus dem LAN hat auch jeder unterschiedliche Vorstellungen. Der eine will damit tatsächlich die Box selbst erreichen und der andere eben das "äußerste Interface" der Box, wo dann auch wieder die Regeln für Portweiterleitungen von externem Verkehr greifen.

EDIT: Die vorstehende Bemerkung zu den unterschiedlichen Erwartungshaltungen gilt natürlich nur, solange AVM nicht RFC 5382 explizit umsetzt ... dann wäre das ordentlich geregelt.

 

[daubsi]

Hallo PeterPawn,

danke für die ausführlichen Erläuterungen. Das wäre natürlich eine plausible Erklärung für das Verhalten. Diese internen Abläufe in der FB waren mir allerdings nicht bekannt. Die Idee mit dem Sniffer ist gut, das probiere ich mal aus.

Ich entnehme der allgemeinen Reaktion, dass das was ich beobachte aber offenbar kein Massenproblem ist?

 

[Theo Tintensich]

generiere im LAN einfach deine eigene DNS-zone und benutze 'drinnen' nur diese.
(Einfach eine kurze Buchstabenkombination nehmen, die 'draußen' nicht verwendet wird. So ist z.B. die TLD ".dd" frei ;-)
Damit kannst du allen internen Geräten brauchbare Namen vergebe.

 

[daubsi]

Hallo Theo,

ich habe intern eine eigene DNS Zone. Der Punkt ist ja, dass ich z.B. meinen Webserver - oder eben owncloud - sowohl intern wie extern über den gleichen Namen ansprechen möchte. Es bringt mir ja nix, wenn ich es extern via <servername>.homelinux.org (via Dyn dynamic name) erreiche, aber von intern nur unter dem namen <server>.myfantasydomainname.de - der Server soll ja stets über den gleichen Namen erreichbar sein.

Die restlichen LAN Komponenten kann ich über den eigenen DNS ja problemlos auflösen - aber die sind ja auch nicht von aussen erreichbar.

 

[thtomate12]

So ist z.B. die TLD ".dd" frei ;-)

Nachher holt sich Dresden bald eine eigene TLD wie koeln, bayern etc

 

[Theo Tintensich]

der Server soll ja stets über den gleichen Namen erreichbar sein.

Dann richte eine Zone ein, die nur das System <server>.myfantasydomainname.de enthält und auf die interne IP weißt.
Alle anderen Namen in myfantasydomainname.de musst du dann ins Internet weiterleiten.

Wobei:
Es könnte sein, dass du nicht auf deinen Server kommt, weil du die "Rebind-Regel" in der F!B nicht passend gesetzt hast.
Heimnetz => Netzwerk => Netzwerkeinstellung.
Hier ganz unten gibt es den Punkt "DNS-Rebind-Schutz"


Hier den Namen deines dDNS-Eintrages mal testen.

 

[alarbiere]

Theo's Idee ist eigentlich der richtige Ansatz.

Du kannst auch intern die DNS Domain von Dyn benutzen, aber eben nur für den einen Server der bei dir im internen Netz steht. Alles andere kannst du dann immer noch zum Internet forwarden.
Dies ist ähnlich mit dem sogenannten Split-Brain DNS. Hierbei stellt ein DNS server zwei verschiedene Ansichten einer Zone zur Verfügung. Bei BIND macht man das mit views.
Wenn du jedoch nur einen einzigen public host hast, dann leg einfach eine Zone mit dem öffentlichen Namen dieses Hosts an und füge eine IP Adresse für die Zone selbst hinzu (mit @).
Dann löst dein DNS Server diesen einen Namen intern auf, fragt jedoch für alles andere trotzdem im Internet nach.

Dies ist zwar nicht die Lösung des technischen Problems mit deiner FB, wird es aber einfach umgehen, ganz ohne NAT (fastlane oder nicht).

Ich habe das bei mir mit einer ganzen Domain so laufen. Ich mache dabei nur eine forwarding zone für die zwei Namen die ich immer im Internet aufgelöst haben will (also andersrum also oben beschrieben). Funktionniert ganz hervoragend seit mehren Jahren.