Tücken der Freigabe von Diensten (Webserver, etc.) bei IPv6 mit der FritzBox

[Barungar]

Hallo zusammen,

ich habe hin und wieder beobachtet, dass zwei spezielle Herausforderungen dem ein oder anderen Kopfschmerzen verursachen, wenn er zeitgemäß einen Dienst nicht nur per IPv4 sondern, sehr löblich, auch per IPv6 freigeben möchte. Das sind die "korrekte IPv6-Adresse" im AAAA-Record des DynDNS und der "DNS-Rebind-Schutz" in der FritzBox. Beides passiert, weil vom Anwender eventuell noch zu sehr in (ver-)al(te)ten IPv4-Gedankenmustern gedacht wird.

Ich möchte in diesem Dokument nicht auf die Risikien oder die Sinnhaftigkeit der Freigabe eines Dienstes von daheim eingehen. Dies liegt in der Eigenverantwortung eines jeden Anwenders selbst. Mein Fokus in diesem Dokument liegt ausschließlich auf der Technik hinter den beiden häufigen Fallstricken mit IPv6.

Beginnen wir daher einfach mal auf bekannten Teritorium. Der Freigabe eines Dienstes bei IPv4.

Das Vorgehen ist immer eine Variation des folgenden "Kochrezeptes":

• DynDNS einrichten (oder eventuell DNS, wenn man eine statische IPv4 hat)
• TCP- und/oder UDP-Portweiterleitungen in der Firewall (in der FritzBox) freigeben

--> Fertig!

Der DynDNS-"Client" läuft dabei in 99% der Fälle auf der FritzBox selbst. Sei es nun, dass man MyFritz! nutzt oder einen der anderen unter Internet -> Freigabe -> DynDNS angebotenen Dienste. Für IPv4 klappt das auch wunderbar, für IPv6 aber so nicht wirklich. Das Problem an dieser Stelle ist nämlich, dass in diesem Fall dem DynDNS-Anbieter die IPv4 und die IPv6 der FritzBox selbst mitgeteilt werden.

Das die falsche IPv6, nämlich die der FritzBox, im AAAA-Record für Euren Dienst steht, erkennt ihr typischer Weise an folgendem Fehler.

Wenn Ihr den seht, könnt ihr zeimlich sicher sein, dass der AAAA-Record auf die FritzBox und nicht auf den "Server" zeigt.
Was muss ich also tun, damit es dann auch bei IPv6 funktioniert?

Das IPv6-DNS-"Problem"
In Bezug auf das DynDNS muss man entweder den kompletten DynDNS-Anteil von der FritzBox weg auf das "Server"-System verlagern, oder aber zumindest wenigstens den IPv6-Teil. Im Fall von IPv6 macht die FritzBox nämlich keine Portweiterleitung, wie bei IPv4, sondern eine Portfreischaltung. Das heißt, die FritzBox lässt im Fall von IPv6 den konfigurierten Port für die öffentliche IPv6 des "Servers" zu und nicht, wie noch bei IPv4, für ihre eigene, öffentliche IPv4.

Beispiel:
Unser FritzBox hat vom Provider die IPv4 203.0.113.46 und das IPv6-Präfix 2001:db8:364d:96ae::/56 erhalten. Für sich selbst erzeugt die FritzBox die öffentliche IPv6 2001:db8:364d:96ae:35:564:9dea:734f auf Basis des Präfixes. Unser "Server" hat intern die IPv4 192.168.178.23 sowie die IPv6 2001:db8:364d:96ae::23 von uns erhalten. Ihr erkennt hier vielleicht schon direkt den Unterschied, die IPv4 unseres "Server" ist privat, die IPv6 aber öffentlich. Die "korrekten" DNS-Einträge für unseren Services lauten somit beim A-Record 203.0.113.46 und 2001:db8:364d:96ae::23 für den AAAA-Record. Wird unser Service nun unter TCP-Port 8080 angeboten, so erteilen wir der FritzBox folgenden Auftrag (ich umschreibe!): "Anfragen auf TCP-Port 8080 an die IPv4 203.0.113.46 leitest Du in das Heimnetz an den TCP-Port 8080 der privaten IP 192.168.127.23 weiter!" Bei IPv6 heißt der Arbeitsauftrag aber: "Anfragen auf TCP-Port 8080 an die IPv6 2001:db8:364d:96ae::23 sind okay, die darfst Du ins Heimnetz reinlassen."

Würde in unserem Beispiel das DynDNS komplett auf der FritzBox laufen, so würde die FritzBox an den DynDNS-Anbieter die falsche IPv6, nämlich die eigene, melden. Wenn Ihr das mit dem Arbeitsauftrag vergleicht, erkennt ihr, dass das nicht funktionieren kann. Bei IPv4 ist das egal, da hier ein andere Art von Auftrag vorliegt.

Fazit: Bei IPv6 muss der AAAA-Record stimmen, dass tut er nicht, wenn der DynDNS-Client zu 100% auf der FritzBox läuft.


Das IPv6-Rebind-Schutz-"Problem"
Wenn nun alles eingerichtet ist und der Aufruf des eigenen Dienstes aus dem Internet per IPv6 (über den Namen) funktioniert, stellt man eventuell fest, dass es am eigenen Client nicht funktioniert. Hier schlägt dann der DNS-Rebind-Schutz der FritzBox zu. Diese Funktion der FritzBox verhindert es, dass aus öffentlichen DNS-Quellen Antworten an Euch weitergeleitet werden, deren IP-Angabe auf eine interne IP im Heimnetz zeigt. Bei IPv4 ist diese Situation eher nicht zu erwarten und wenn, dann ist sie in vielen Fällen tendenziell böswillig. Daher auch dieser Schutzmechnismus.
Bei IPv6 und der abweichenden Archtitektur hingegen ist diese Situation nicht unüblich. Im DNS AAAA-Record für unser "Server" steht ja wirklich seine öffentliche IPv6 drin und diese befindet sich auch tatsächlich in unserem Heimnetz. Es sind also alle Bedingungen erfüllt, damit der DNS-Rebind-Schutz aktiv wird.

Unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen findet ihr ein Eingabefeld für den DNS-Rebindschutz. Hier tragt ihr den korrekten Namen (FQDN) Eures Dienstes ein. Anschließend lässt die FritzBox auf DNS-Anfragen für diesen Namen zu, selbst wenn sie eine IP aus dem Heimnetz liefern.

Viel Spaß!

 

[Mavalok2]

Gut geschrieben. Da bekommt man richtig Lust IPv6 einzurichten.

Wenn man dies so liesst, drängt sich allerdings der Gedanke auf, dass die Fritzbox für IPv6 noch nicht ganz fit ist, oder besser gesagt noch nicht so Endbenutzer freundlich ist wie sie sein sollte. Denn dies entspricht nicht ganz der sonstigen Bedienung der Fritzbox.

 

[Spielebernd]

Ich bin hier weiß Gott kein Profi aber ich denke das Problem liegt hier eher im IPv6 Standard statt in der FB.

Die FB teilt so wie in Ihr eingerichtet dem DynDNS Ihre IPv6 mit wie bei IPv4 auch was soll sie auch sonst übermitteln. Ergo kommst du beim Aufruf bei der FB raus. Hier kannst du auch wie bei IPv4 ne Portweiterleitung setzen aber auf die IPv6 Interface ID die mit dem IPv6 DHCP ausgehandelt wurde.

wenn ich das jetzt ab hier noch richtig zusammenbekomme reagieren die Geräte auf die „lokale IPv6“ nicht oder nicht immer von Haus aus. Ist das richtig hier bin mir nicht mehr sicher. @Barungar kann da sicher etwas Licht ins Dunkel bringen.

 

[Barungar]

@Spielebernd Eine Portweiterleitung ist in sich bereits eine "Perversität". Eine nachträgliche Mangelbeseitigung zum "schönen Normal" zu erheben, da wird mir ganz grausig.

Auch die Väter des IPv4 wollten nie, das Menschen sich mit NAT und Portweiterleitung rumärgern mussten. Im Grundgedanke sollte jedes Gerät "im Internet" seine eigene, eineindeutige IPv4 haben. Dann hätte das IPv4 genau so funktioniert, wie nun das IPv6 funktioniert. Das IPv6 schafft durch einen großen Addressraum einfach die Möglichkeit zu den Grundideen zurückzukehren und von den Irrwegen abzukehren.

Der Haken ist einfach... im IPv4 erhalte ich vom Provider nur eine IPv4. Durch diesen "Mangel" werde ich zu NAT und anschließender Portweiterleitung "gezwungen". Beim IPv6 erhalte ich vom Provider ein Subnetz ("IPv6 Präfix"). Um das vergleichen zu können, müsste der Provider Dir z.B. beim IPv4 nicht nur die IP 203.0.113.46 zuweisen sondern direkt das Netz 203.0.113.0/24 ... Dann hättest Du das gleiche Szenario. Deine FritzBox wäre 203.0.113.1 und Dein "Server" 203.0.113.23. Würde dann die FritzBox den DynDNS auf 203.0.113.1 setzen, würde Dein Service auch nicht funktionieren.

Hier kannst du auch wie bei IPv4 ne Portweiterleitung setzen aber auf die IPv6 Interface ID die mit dem IPv6 DHCP ausgehandelt wurde.

Nein, das stimmt so nicht. Da ist AVM leider sehr unscharf in der Bezeichnung. Vermutlich, weil sie denken, dass ihre Klientel mental nicht mit der Wahrheit ungehen könnte. Seit IPv4 kennt "jeder" das Prinzip eine Portweiterleitung, also nennen wir es weiterhin Portweiterleitung. Da findet aber effektiv keine Portweiterleitung statt, sondern ganz korrekt ein Routing. Die InterfaceID wird benötigt, damit die FritzBox dynamisch, bei einem Präfixwechsel, ohne Umschweife sofort die korrekte neue GA des Geräte hat. Denn die öffentliche IPv6 (GA) des Servers ist immer IPv6-Präfix + InterfaceID.

Ein guter Hinweis, dass hier verschiedene Dinge, nämlich eine "Portweiterleitung" bzw. ein Routing passieren, kann man mittels traceroute feststellen. Man braucht dazu lediglich einen Host, der im Internet steht. Man macht nach einander ein traceroute -6 meinservice.meinedomäne.de und ein traceroute -4 meinservice.meinedomäne.de

Den Unterschied erkennt man sofort. Das 4er Traceroute endet an der FritzBox, die Portweiterleitung ist transparent. Das Gegenüber kann nicht feststellen, dass hinter der FritzBox noch etwas passiert. Für ihn "terminiert" die TCP-Verbindung an der FritzBox.
Das 6er Traceroute zeigt Dir als Hop Deine FritzBox (mit deren IPv6) und danach den Hop Deines "Servers" (mit seiner IPv6). Es wird also korrekt geroutet.

wenn ich das jetzt ab hier noch richtig zusammenbekomme reagieren die Geräte auf die „lokale IPv6“ nicht oder nicht immer von Haus aus.

Ich verstehe hier leider nicht, was Du meinst.

 

[Spielebernd]

@Spielebernd Eine Portweiterleitung ist in sich bereits eine "Perversität". Eine nachträgliche Mangelbeseitigung zum "schönen Normal" zu erheben, da wird mir ganz grausig.

Punkt für dich hat sich halt irgendwie so eingebürgert.

Nein, das stimmt so nicht.

Danke für die Aufklärung das hatte ich in der Tat anders verstanden. Im Grunde bin ich sogar davon ausgegangen das hier ich nenne es mal eine pseudo private IPv6 gebastelt wird die ähnlich IPv4 auch wieder mit NAT und allem entsteht.

Damit ist auch die Frage passé . Danke für die sehr gute Beschreibung.