IPv6-DynDNS für Hosts im Subnet unter OpenWRT mit feste-ip.net

tl;dr

DynDNS mit IPv6 für Hosts innerhalb des Heimnetzes lässt sich zentral mit Feste-IP.net lösen. Die vom Anbieter vorgeschlagene FIP-Box braucht es dabei nicht, wenn man OpenWRT einsetzt.

Der Bedarf

Wie sehr hat es mich damals gefreut, als die Telekom im Herbst 2012 auf meinem neuen VDSL-Anschluss endlich damit begonnen hatte, IPv6-Präfixe zu verteilen. Für jemanden, der sich bereits jahrelang mit diesem Thema beschäftigt hatte, war das der lang ersehnte Moment des beginnenden Fortschritts.

Zuvor hatte ich, wie wohl die meisten anderen Anwender von IPv6 bis dahin auch den (kostenlosen!) Service von SixXS in Anspruch genommen, von wo man seinen eigenen IPv6-Adressbereich erhalten konnte, getunnelt über den normalen IPv4-basierten Internetanschluss und so die Möglichkeit, endlich im IPv6-basierten Internet zu kommunizieren.

Dieser Service hatte einen gewissen „Preis“: Da man, anders als vom eigenen Internetanschluss gewohnt, dort einen fest zugewiesenen Adressbereich erhielt, war dieser einem selbst nun fest zuortbar. Ich nahm das aber gerne in Kauf, denn IPv6 war für mich natürlich deshalb interessant, um den direkten Zugriff auf die eigenen Systeme und Dienste im Heimnetzwerk von außen zu ermöglichen. Dafür waren feste Adressen, die sich auch mit Host- und Domainnamen versehen ließen, natürlich ideal.

Dann kam die Telekom. Und getrieben vom Datenschutzgedanken (bei vehementer Forderung von Datenschützern) – und sicherlich auch vom Gedanken der Abgrenzung von Privat- und Geschäftskunden-Produkten – vergab sie bei ihrem IPv6-Rollout natürlich kein festes IPv6-Adresspräfix. Der Zugriff von außen ist damit zwar möglich, jedoch ändern sich die Adressen, wie die IPv4-Adresse eines typischen normalen Anschlusses auch, bei jeder Neueinwahl. Ein DynDNS-Service musste her.

Warum ich nicht SixXS weiter nutzen möchte

Natürlich besteht auch trotz nativer IPv6-Anbindung bei der Telekom weiterhin die Möglichkeit, die Tunnel-Lösung mit SixXS weiter zu benutzen und damit statische Adressen beizubehalten.

Aus verschiedenen Gründen möchte ich das gerne vermeiden:

• Der Aufwand, den Tunnel weiter zu betreiben, ist auch nicht ohne. Beim Einsatz vom neuen OpenWRT 14.07 (im RC) ist mir die Einrichtung des avaya-Clients nicht gelungen. Manchmal scheitert es auch an Änderungen des Systems, etc.
• Die sogenannten PoPs, an denen die Tunnel terminieren sind nicht immer zuverlässig verfügbar. Gelegentliche Ausfälle treten schon einmal auf. Der Trafficverlauf ist natürlich auch nicht optimal, schließlich muss er durch den Tunnel einen Umweg nehmen.
• Natürlich ist es „eleganter“, IPv6-Traffic nativ zu verschicken, als ihn in IPv4-Traffic verpacken zu müssen. Die Bytes des zusätzlichen IPv4- und UDP-Headers des Avaya-Protokolls mindern dadurch dann auch nicht mehr die maximale Paketgröße.

Das Problem

DynDNS-Dienste für IPv6 gibt es bereits seit vielen Jahren, vielleicht nicht ganz wie Sand am Meer, aber doch recht viele. Warum auch nicht? Prinzipiell ist der Betrieb eines DynDNS-Dienstes nicht schwierig und IPv6 unterscheidet sich prinzipiell nicht allzu sehr von IPv4. Also einfach den Service um IPv6-Adress-Updates für den dynamischen Host-Name erweitert und fertig, oder?

Nun, nicht ganz. Denn natürlich hat sich mit IPv6 (glücklicherweise) einiges geändert. Wer bisher DynDNS-Dienste nutzte, tat das meist deshalb, um den Zugriff beispielsweise auf das eigene NAS, das Web-GUI der Fritz.Box (und den daran angeschlossenen USB-Speicher) oder die Remote-Steuerung der eigenen VDRs zu ermöglichen, oder ähnliches. Bei Bedarf wurde einfach eine Portweiterleitung auf den gewünschten Dienst im Netz eingerichtet und somit waren über einen Hostnamen und unterschiedliche Portnummern nun alle gewünschten Dienste verfügbar. Zugegeben: Blödes Gefrickel, aber funktionierte.

Mit IPv6 ist das anders. Plötzlich hat jeder Service seine eigene öffentliche IP-Adresse, alles ist direkt erreichbar. Nun reicht ein Hostname nicht mehr aus, man möchte für jeden Rechner im Netz, für jeden Service, der von außen erreichbar sein soll, auch einen eigenen Hostnamen anlegen. Klassische DynDNS-Dienste sind davon überfordert. Zwar kann man dort oft fünf, zehn oder gar zwanzig Hostnames auch anlegen. Die Konfiguration von so vielen DynDNS-Update-Clients möchte jedoch niemand ernsthaft durchführen. Oftmals ist auch der Betrieb eines solchen DynDNS-Updaters auf dem gewünschten Host auch gar nicht möglich oder sinnvoll.

Die Lösung erscheint naheliegend: Der Host-Teil der IPv6-Adresse ist statisch (zumindest existiert immer auch neben dynamisch generierten „Privacy Extensions“-Adressen ein solches), nur das Präfix ändert sich regelmäßig. Warum also nicht einfach an einer Stelle im Netz zentral dem DynDNS-Service mitteilen, welches Präfix aktuell ist und alle dort hinterlegten Hosts automatisch mit den bekannten statischen Host-Einträgen und dem neuen dynamischen Präfix updaten?

So einfach dies klingt, so lange war das nirgends verfügbar. Fast hatte man den Eindruck, die Anbieter von DynDNS-Services sind zu sehr in ihrer IPv4-Welt verhaftet, um diesen Bedarf zu erkennen. Wahrscheinlich ist die Implementierung eines solchen Dienstes aber, wenn auch sicherlich nicht allzu schwierig, zumindest eben auch nicht unbedingt trivial. Dass es dabei noch ein Problem gibt, wurde mir erst etwas später klar.

Diese Situation veranlasste mich im April zum oben gezeigten Tweet.

Lösungsansätze

Der erste Service, der versuchte dieses Problem zu adressieren und über den ich stolperte, war der AVM-eigene MyFritz-Dienst. Ausprobiert habe ich ihn nicht und kann deswegen auch wenig darüber sagen. Der Grund ist einfach: er ist nur für Nutzer einer Fritz.Box verfügbar. Und so praktisch diese Hardware für die meisten Menschen sein mag, ich habe es gerne ein bisschen flexibler.

Im Mai stolperte ich dann über das Angebot von Feste-IP.net. Das war neu, denn hier gab es erstmals eine Lösung für ein weiteres Problem, das inzwischen um sich greift:

Da die verfügbaren IPv4-Adressen inzwischen bei vielen Netzbetreibern zur Neige gehen, sind einige davon gezwungen, Technologien einzusetzen, bei denen der einzelne Anschlussinhaber gar keine (eigene) öffentliche IPv4-Adresse mehr bekommt. Entweder teilt er sich beim „CGN“ diese mit anderen Kunden – ähnlich wie der Heimrouter schon seit Jahren mit nur einer öffentlichen Adresse alle Geräte im Heimnetz mit Zugang versorgt – wie im Mobilfunknetz auch schon lange üblich, oder aber, der Service-Provider bietet dem Kunden nur noch eine IPv6-Verbindung und IPv4-Verkehr wird über das Zusammenspiel von eigenem Router und Gegenstelle beim Service-Provider speziell behandelt. Hier kommt typischerweise das „Dual-Stack-Lite“-Verfahren (kurz DSlite) zum Einsatz (auf NAT64,464XLAT gehe ich mal nicht weiter ein).

Feste-IP.net hat nun ein Portmapper-Angebot entwickelt, bei dem über eine vom Dienstbetreiber bereitgestellte IPv4-Konnektivität der Zugriff aufs Heimnetzwerk über IPv6 am CGN vorbei ermöglicht wird. Für viele Kunden von Kabel Deutschland und vielen anderen ein nützlicher Service. Mir war dabei sofort klar, dass der Service auch die Verwaltung unterschiedlicher Host-Identifier einschließen müsste, genau das, was ich wollte!

Auf meine Rückfrage, ab wann denn mein Anwendungsszenario eines simplen DynDNS für unterschiedliche IPv6-Hosts unterstützt werde, bekam ich Antwort, dass dies schon möglich sei. Damit war das für mich gekauft und ich registrierte mir einen Account.

Das kleine Problem

Eines jedoch hatte ich nicht bedacht und es wurde mir erst klar, als ich die teilweise doch recht komplizierten Anleitungen für das Handling mit dem CGN sah: zwar ist es denkbar einfach, dass der Router zuhause das DynDNS-Update auch bei feste-ip.net durchführt (inzwischen haben die meisten Router ja eine solche Option, die sich auch anbieterunabhängig konfigurieren lässt), leider entspricht jedoch die Adresse, mit der dieses Update vom Router durchgeführt wird nicht der des internen Netzes, sondern der des WAN-Interfaces. Und diese Adresse hat eben genau nicht das Präfix der Geräte des internen Netzes, die man erreichbar machen möchte!

Feste-IP.net schlägt dafür zwei Lösungsmöglichkeiten vor. Die erste Variante ist, dem Service den Zugriff auf die eigene CPE zu ermöglichen, damit dieser das Präfix des internen Interfaces ausliest. Aus meiner Sicht kommt das nicht in Frage und zwar nicht nur deshalb, weil OpenWRT nicht von Feste-IP.net unterstützt wird. Fairerweise muss man aber sagen, dass der Serviceanbieter selbst von dieser Methode nach möglichkeit eher abrät.

In der zweiten Variante übernimmt nicht der Heimrouter selbst, sondern ein anderes Gerät im Heimnetz das DynDNS-Update. Feste-IP.net schlägt hierfür die FIP-Box auf RaspberryPi-Basis vor. Zwar habe ich einen solchen hier zur Verfügung, die Lösung erscheint mir aber unelegant und hat einen Nachteil: Das Gerät selbst übernimmt nicht die WAN-Kommunikation, das DynDNS-Update kann also nicht nahtlos an eine Neueinwahl anschließend getriggert werden (ob die FIP-Box automatisch bei einem neuen globalen Präfix ein Update triggert, ist mir nicht bekannt).

So funktionierts mit OpenWRT

Es hat dann letztlich doch einige Monate und mehrere Anläufe gebraucht, bis ich eine Lösung gebastelt habe, mit der ich zufrieden bin. Dass es sich mit einem offenen Router-Betriebssystem wie OpenWRT irgendwie sicher umsetzen ließe, war von vornherein klar. Nur sollte sich die Lösung auch gut in das System einfügen und so möglichst kleinen „Pflegeaufwand“ haben. Erst als ich in den bestehenden ddns-scripts den möglichen Parameter script als ip_source in der Dokumentation fand, der im WebGUI nicht verfügbar ist, war das Problem einfach zu lösen.

Feste-IP.net-Account anlegen

Zunächst brauchen wir einen Account bei Feste-IP.net. Der Account selbst ist nicht kostenpflichtig, die Bereitstellung des DynDNS-Service, also die Möglichkeit, den Hostname upzudaten, kostet jedoch einen Credit pro Tag. 365 Credits sind für 4,95€ zu haben. 50 Credits Startkapital sind dabei, so dass sich der Dienst sieben Wochen kostenlos testen lässt.

Sobald wir einen Account haben, können wir nun einen neuen (Haupt-)Host-/Domainnamen anlegen:

Die einzelnen, per IPv6 erreichbaren Hosts, werden später als Subdomain davon angelegt. Beim Anlegen wird einem sofort die Host-ID, sowie ein generiertes Passwort angezeigt. Die Host-ID dient dabei als individueller Benutzername für das DynDNS-Update. So können mit einem Account mehrere DynDNS-Hostnames, bspw. für unterschiedliche Heimnetzwerke, angelegt werden, ohne dass überall die selben Credentials benutzt werden müssen. Das Passwort wird an dieser Stelle nur einmalig angezeigt. Wird es nicht notiert, muss später ein neues generiert werden!

Die Übersicht der Hostname-Konfiguration sieht dann folgendermaßen aus:

Augenmerk gerichtet werden muss auf die Option IPv4/IPv6 Verhalten. Standardmäßig wird nur ein Protokoll gleichzeitig unterstützt. Wir sind an dieser Stelle natürlich an einem IPv6-Eintrag interessiert, daher empfiehlt sich die feste Einstellung auf „IPv6“.

Achtung: Es funktioniert auch ein gleichzeitiges Update von IPv6- und IPv4-Einträgen. Diese müssen jedoch getrennt voneinander geupdated werden. Bei der Konfiguration der ddns-scripts weiter unten, ist demnach ein eigenes Setup für IPv4 anzulegen!

Rechts unten über IPv6-Features gelangt man zu einem Menü, wo die einzelnen Hosts des internen Netzes als „Subhosts“ angelegt werden können. Klickt man darauf kommt man zu dieser Eingabemaske:

Hier kann der hostname, der vor den „Haupt-Hostname“ mit Punkt getrennt gesetzt wird, gewählt werden, sowie der IPv6-Host-Identifier angegeben werden. Der Host-Identifier ist die hintere Hälfte einer IPv6-Adresse, also die hinteren vier Blöcke, die mit Doppelpunkten getrennt werden, oft genau der Abschnitt hinter den „zwei Doppelpunkten“, falls die IPv6-Adresse in Kurzschreibweise dargestellt wird/werden kann. Wichtig ist es, darauf zu achten, dass hier ein statischer Host-Identifier gewählt wird und kein „temporärer“, der durch die sogenannten Privacy-Extensions zufällig generiert wurde. Auf unixoiden Systemen enthält dieser Host-Identifier typischerweise die Zeichenfolge ff:fe, auf Windows-Systemen wird auch das verwürfelt. Wer sichergehen möchte, leitet sich den Host-Identifier aus der „Link-Local-Adresse“ seines Netzwerkinterfaces ab. Wichtig ist der doppelte Doppelpunkt, um den Host-Identifier gültig einzugeben.

Ist der Subhost angelegt, sieht das so aus

und ab dem nächsten Update des Haupt-Hostnames, wird auch dieser Subhost im DNS verfügbar sein. Dieses Vorgehen ist nun für jeden einzelnen Host im eigenen Netz zu wiederholen, den man per Hostname erreichen möchte.

Ist das erledigt, können wir uns mit der „Host-ID“ und dem Passwort bewaffnet an die Konfiguration des DynDNS-Updaters unter OpenWRT machen.

ddns-scripts konfigurieren

Die Nutzung von DynDNS-Diensten mit einem OpenWRT-Router setzt zunächst die Installation entsprechender Plugins voraus. Per CLI lauten die dafür nötigen Befehle:

opkg update
opkg install ddns-scripts

Es gibt auch ein passendes Plugin für das luci-Webfrontend (luci-app-ddns), jedoch bietet das NICHT die Möglichkeit die notwendige Quelle der IP-Adresse skriptbasiert zu konfigurieren.

Um nun den DynDNS-Dienst auf dem CLI zu konfigurieren, benutzen wir das UCI-Interface. Zunächst jedoch muss ein Bezeichner gewählt werden, unter dem wir diese DynDNS-Updater-Instanz geführt wird. Der Standardwert ist dabei myddns, im Beispiel hier verwenden wir festeip, um sich von einem bestehenden Setup abzugrenzen. Möchte man IPv4 und IPv6 parallel updaten lassen, empfiehlt sich ggf. die Anlage zweier Instanzen, die unterschiedlich benannt werden müssen.

uci set ddns.festeip.enabled=1
uci set ddns.festeip.ip_source='script'
uci set ddns.festeip.ip_script='/root/get-internal-ipv6-net.sh'
uci set ddns.festeip.update_url='http://[USERNAME]:[PASSWORD]@v6.members.feste-ip.net/nic/update?system=dyndns&hostname=[DOMAIN]&myip=[IP]'
uci set ddns.festeip.domain='hostname.feste-ip.net'
uci set ddns.festeip.username=<die zuvor notierte Host-ID>
uci set ddns.festeip.password=<das zuvor notierte Passwort>
uci commit ddns

• ip_source Die Standardmöglichkeiten dieser Option lesen die IP-Adresse, die dem DynDNS-Dienst mitgeteilt werden soll, vom WAN-Interface oder von einer Website, etc. Wir möchten hier jedoch explizit die IPv6-Adresse des internen Interfaces, das so von den Standardmethoden nicht unterstützt wird. Indem wir diese Aufgabe ein eigenes Skript erledigen lassen, haben wir Kontrolle darüber, was hier zum Server geschickt wird.
• ip_script Hier wird der Pfad zum genannten Skript festgelegt. Name des Skripts und der Ablageort können natürlich bei Bedarf angepasst werden. Zum Skript selbst später mehr.
• update_url Diese URL wird verwendet, um explizit die IPv6-Adresse beim Feste-IP.net-Service upzudaten. Die URL muss natürlich ohne Zeilenumbrüche eingegeben werden. Achtung, die URL ist so wie hier angegeben zu übernehmen, Username (=Host-ID) und Passwort werden in den jeweiligen Optionen angepasst
• domain Bezeichnet den zuvor selbst angelegten Hostnamen.

Der Rest ist hoffentlich selbsterklärend.

Möchte man die Instanz des IPv4-Updaters anlegen, so ist für ip_source der Standardwert ‘network’ zu wählen, statt ip_script die Option ip_network und ihr Wert auf ‘wan’ zu setzen.

Die Konfiguration ist dabei dann auch über das Webinterface möglich.

Aus der Update-URL ist die Zeichenfolge ‘v6.’ wegzulassen.

uci commit ddns übernimmt die konfigurierten Änderungen ins System. Wer zunächst testen möchte, kann den Parameter enabled auch zunächst deaktiviert lassen und später erst aktivieren.

Wer weitere Einstellungen anpassen möchte, zum Beispiel die Update-Intervalle anpassen möchte, kann hierzu einen Blick ins OpenWRT-Wiki werfen.

Source-Skript

Bleibt noch zu klären, woher wir uns nun die IPv6-Adresse des internen Interfaces besorgen. Hierfür brauchen wir nun noch den Inhalt des Skripts, das wir bei der Konfiguration von ddns-scripts angegeben hatten. Bei mir liegt dieses Skript im Homeverzeichnis von root und es sieht so aus

get-internal-ipv6-net.sh:

#!/bin/sh
ip addr show dev br-lan scope global to 2000::/3 | \
awk '/inet6/{print $2}' | cut -d / -f 1

• ip addr … ruft die Ausgabe der IP-Adresse auf.
• br-lan ist das (hier Bridge-)Interface des internen Netzes, dessen Präfix wir haben wollen.
• to 2000::/3 sorgt dafür, dass ausschließlich Global-Unicast-Präfixe ausgewählt werden, denn leider werden trotz scope global ohne diese Option auch eventuell vorhandene Unique-Local-Präfixe ausgegeben.
• awk … schneidet uns die eigentliche IPv6-Adresse aus der Ausgabe heraus und cut … die Angabe der Präfixlänge hinten ab, so dass die reine Adresse zum Schluss übrig bleibt.

Anlegen lässt es sich die Datei mit vi /root/get-internal-ipv6-net.sh, der Inhalt nach drücken von I einfügen und mit :wq abspeichern.

Testen

Ob das Update auch erfolgreich funktioniert, kann man auf dem CLI testen, indem man folgenden Befehl ausführt:

/usr/lib/ddns/dynamic_dns_updater.sh festeip

Für festeip ist an dieser Stelle der Bezeichner einzusetzen, der bei der Anlage des DynDNS-Service im UCI von OpenWRT gewählt wurde. Die Ausgabe von „Update-Output“ gibt einem dann Gewissheit, dass das Update funktioniert.

Fazit

Endlich gibt es eine Möglichkeit, auch bei dynamisch wechselnden IPv6-Präfixen einen DynDNS-Service mit mehreren Endgeräten im Heimnetz zu benutzen und dies zentral auf dem eigenen mit OpenWRT betriebenen Heimrouter upzudaten, ohne zusätzliche Hardware.

Disclaimer: ich stehe in keinerlei Verbindung zum Betreiber von Feste-IP.net, außer dass ich selbst dort Kunde dieses Service bin.

Ich freue mich über Feedback, Verbesserungsvorschläge, etc. Dieses Blog hat keine Kommentarfunktion, daher am besten unter den gelisteten Kontaktmöglichkeiten.