IPv6/Link/Namensauflösung
Namensauflösung
- Was den Nodes am Link jetzt noch fehlt, ist ein Nameserver für die Namensauflösung
- Test
user@linux:~ $ ping -6 -c 3 ipv6.foxtom.de unknown host
Ohne die Möglichkeit Namen aufzulösen, verschafft selbst die beste Konnektivität wenig Vorteile
Konfiguration DNS
Der Router agiert bereits als zentraler Anlaufpunkt für alle Daten die den Link verlassen sollen
- Es bietet sich daher an, ihm auch die Aufgabe der Namensauflösung zuzuteilen
Abbildung: Zielkonfiguration
Der Router selbst, aber auch die Hosts können dann DNS-Anfragen an den installierten Resolving DNS Server (RDNSS) weiterleiten
- Dieser kümmert sich um die Auflösung des Namens und teilt dem Anfragenden das Ergebnis mit
- Der Einsatz eines Caches sorgt dafür, das zukünftige Anfragen teilweise oder komplett aus diesem beantwortet werden können
- Die Geschwindigkeit, mit der eintreffende Anfragen beantwortet werden, wird so im Laufe der Zeit optimiert
Unbound
Nameserver festlegen
Wenn der Server wie erwartet antwortet, definieren wir ihn, falls das System es nicht bereits in vorrauseilendem Gehorsam getan hat, auf router als Standard-Nameserver:
root@router:~# resolvconf -u root@router:~# cat /etc/resolv.conf nameserver ::1
In der Datei /etc/resolv.conf sind unter Ubuntu GNU/Linux die Adressen der Nameserver des Systems hinterlegt
- Das eben ausgeführte Kommando hat die Datei überschrieben und dabei die Loopback Address als neue Nameserver-Adresse festgelegt
- Mit dem Kommando cat haben wir uns den Inhalt der Datei anzeigen lassen
Erreichbarkeit testen
- Die Erreichbarkeit des Nameservers testen wir sicherheitshalber auch von einem der Hosts aus
Zum Beispiel durch eine einfache Namensauflösung auf linux
user@linux:~ $ host www.ipv6-workshop.de 2 a 1 :198:2 Using domain server : Name : 2 a 1 :198:2 :8 a23 ::1 Address : 2 a 1 :198:2 :8 a23 ::1#53 www.ipv6-workshop.de has IPv6 address 2 1:67 c :26 f4 :8 ::6:8:8 a23 ::1
Die korrekte Auflösung zeigt, dass der Nameserver funktioniert und von den Hosts erreicht und verwendet werden kann
RDNSS
- Die RDNSS Option
Nameserver-Adressen lassen sich auch als Option im Router Advertisement unterbringen und so bequem auf dem Link verteilen
- Die Option heißt RDNSS Option, ist in RFC 6106 [JPBM10] spezifiziert, und reiht sich ein in die lange Liste der ICMPv6-Optionen
- Insgesamt bietet sich uns damit der gleiche Komfort wie beim Betrieb eines sehr einfach gehaltenen DHCP-Servers, nur eben ohne einen dedizierten DHCP-Server für derartige Informationen bereitstellen zu müssen
RDNSS Option im Router Advertisement
Mit der Verteilung der Router Advertisements hatten wir Radvd beauftragt
- Wir ergänzen die Konfigurationsdatei gemäß Abbildung 5.20 um die RDNSS Option
Damit die Änderungen wirksam werden, ist ein Neustart von Radvd erforderlich:
root@router:~# service radvd restart Stopping radvd : radvd Starting radvd : radvd
Router Advertisement
Selbstverständlich schauen wir uns das neue Router Advertisement in Wireshark an
- Auf router fangen wir eines auf Interface eth1 auf
- Mit dem notwendigen Vorgehen sind wir inzwischen bestens vertraut
Abbildung: Router Advertisement
Neu hinzugekommen ist die ICMPv6-Option vom Typ 25
- Sie enthält die Gültigkeitsdauer des Nameservers in Sekunden sowie die Adresse des Nameservers selbst
- Die Gültigkeit mag auf den ersten Blick sehr kurz erscheinen, schließlich ändern sich die Adressen von Nameservern üblicherweise nicht jede Minute
Abbildung: Konfiguration von Radvd mit RDNSS Address
Abbildung: Router Advertisement mit RDNSS Address
- /etc/radvd.conf
interface eth1 { AdvSendAdvert on ; MinRtrAdvInterval 15; MaxRtrAdvInterval 6 ; AdvCurHopLimit 64; AdvManagedFlag off ; AdvOtherConfigFlag off ; AdvMobRtrSupportFlag off ; AdvDefaultPreference medium ; AdvDefaultLifetime 3 ; AdvReachableTime ; AdvRetransTimer ; AdvLinkMTU 128 ; prefix 2 a 1 :198:2 :8 a23 ::/64 { AdvOnLink on ; AdvAutonomous on ; AdvRouterAddr off ; AdvValidLifetime 36 ; AdvPreferredLifetime 18 }; RDNSS 2 a 1 :198:2 :8 a23 ::1 { }; AdvSourceLLAddress on ; };
- Alte Denkweise abschütteln
- Es ist unter IPv6 keine Seltenheit, wenn ein Link mit mehreren Routern ausgestattet ist
- Und jeder Router preist unter Umständen seine ganz eigenen Nameserver an
- Verlässt ein Router den Link, sollten auch alle Konfigurationsvariablen die er zuvor verteilt hat, zeitnah an Gültigkeit verlieren
- Als Höchstwert für die RDNSS-Lifetime wird das doppelte maximale Sendeintervall (MaxRtrAdvInterval) empfohlen
- Mit 60 Sekunden sind wir unter diesem empfohlenen Höchstwert geblieben
Betriebssysteme und die RDNSS Option
- Unterstützung für die RDNSS Option ist nicht in allen Betriebssystemen vorhanden
- Die Betriebssysteme iOS und OS X von Apple geben ein gutes Bild ab, was die Unterstützung der RDNSS Option angeht
- Googles Android funktionierte zwar schon sehr früh gut mit IPv6, wertete aber auch Anfang 2013 bisher nicht die RDNSS Option aus
Unter Linux extrahiert das von vielen Distributionen und Desktop- RDNSS Option Umgebungen verwendete Programm NetworkManager die Na- unter Debian meserver-Adressen aus den Router Advertisements
- Anschlie- GNU/Linux ßend fügt es die Informationen in die Datei /etc/resolv.conf des jeweiligen Systems ein
- Wir hatten den NetworkManager auf lynx in Abschnitt 4.1 Debian GNU/Linux 6 vorläufig entmachtet
- Jetzt wo das Netz in seinen Grundzügen steht, darf der NetworkManager wieder die Kontrolle über die Interfaces auf lynx übernehmen
Wir starten ihn wieder:
root@lynx:~#/etc/init.d/network-manager start Starting network connection manager : NetworkManager
Damit der NetworkManager auch nach einem Neustart noch arbeitet, fügen wir ihn wieder in die Boot-Sequenz ein
root@lynx:~# update-rc
- d network - manager enable update - rc .d: using dependency based boot sequencing
Abbildung: NetworkManager - Einstellungen und Profile
Abbildung: Profil Auto eth0 auf lynx
Konfiguration durch NetworkManager
- Auf dem Desktop befindet sich der NetworkManager in der oberen Leiste
- Ein Symbol bestehend aus zwei verbundenen Computern bietet Zugriff auf die Oberfläche des Programms
- Mit einem Linksklick werden die verfügbaren Profile angezeigt und mit einem Rechtsklick gelangt man in das Konfigurationsmenü
- In letzteres begeben wir uns und wählen dann den Punkt Edit Connections (Abbildung 5.22) aus
Nun öffnet sich eine nach Interfaces sortierte Liste verfügbarer Profile
- Im Tab Wired suchen wir ein Profil zum Interface eth0, der Name könnte zum Beispiel Auto eth0 lauten
- Mit einem Klick auf Edit gelangen wir zu den Einstellungen des Profils (Abbildung 5.23)
Die Einstellungen für IPv4 stellen wir auf Disabled, die für IPv6 auf Automatic
- Weitere Angaben sind nicht nötig für unseren Link, denn dort verteilen wir alle wichtigen Informationen mit den Router Advertisements
- Wir schließen die offenen Dialoge und aktivieren das eben bearbeitete Profil mit einem Linksklick auf das NetworkManager-Symbol
- Das Symbol zeigt für einen kurzen Augenblick Aktivität an und beruhigt sich wieder, sobald die Konfiguration erfolgreich verlaufen ist
Überprüfen der Konfiguration
Davon werden wir uns überzeugen und lassen uns die Adressen des Interfaces anzeigen:
user@lynx :~ $ ip addr show dev eth 2: eth : < BROADCAST , MULTICAST ,UP , LOWER_UP > mtu 15 ' qdisc pfifo_fast state UP qlen 1 link / ether : : :6 : d :1 e brd ff : ff : ff : ff : ff : ff inet6 2 a 1 :198:2 :8 a23 :2 : ff : fe6 : d1e /64 scope ' global dynamic valid_lft 36 sec preferred_lft 18 sec inet6 fe8 ::2 : ff : fe6 : d1e /64 scope link valid_lft forever preferred_lft forever
Es zeigt sich das gewohnte Bild, die Autoconfiguration hat korrekt gearbeitet
- Mit dem Kommando cat lassen wir uns den Inhalt der Datei /etc/resolv.conf anzeigen:
user@lynx :~ $ cat /etc/resolv.conf # Generated by NetworkManager nameserver 2 a 1 :198:2 :8 a23 ::1
Der NetworkManager hat die Nameserver-Adresse richtig aus dem Router Advertisement extrahiert und sie dem System bekannt gemacht
- Der obligatorische Test beweist das Funktionieren der Namensauflösung und des Routings auf lynx:
user@lynx :~ $ ping6 -c 3 ping
RDNSS Option unter Windows 8 Windows 8 unterstützt die RDNSS Option leider nicht von Haus aus
- Es gibt ein Programm namens rdnssd-win32 welches die Funktionalität nachrüstet, dieses stammt aber nicht
- Abbildung 5.24: Einstellungen von LAN1 aufrufen
- Abbildung 5.25: Protokolle von LAN1
von offizieller Seite (http://sourceforge.net/projects/rdnssd-win32/).Die Hoffnungen ruhen auf einer Nachrüstung durch eines der kommenden Service Packs
- Es bleibt uns nichts anderes übrig, als die Adresse des Nameservers manuell einzutragen
Dazu öffnen wir das Connection and Sharing Center und wählen dann Change adapter settings (Abbildung 5.24) Ein Rechtsklick auf den Adapter LAN1 und dann auf Properties bringt uns zur Liste der Protokolle
- In der Protokollliste, dargestellt in Abbildung 5.25, ist IPv4 deaktiviert und IPv6 aktiviert
Wir wählen IPv6 aus und öffnen mit einem Klick auf Properties den Dialog zur IPv6-Konfiguration
- Abbildung 5.26: IPv6Konfiguration von LAN1
- Abbildung 5.27: Website des KAME-Projekts
Während die Einstellungen für die Adresse unverändert auf automatically stehen bleiben, erfordern die Nameserver-Einstellungen unser Zutun
- Wie in Abbildung 5.26 gezeigt, tragen wir die Nameserver-Adresse ein
Bitte beachten Sie: Ihre Nameserver-Adresse wird anders lauten als jene in den Abbildungen
- Die korrekte Adresse können Sie Ihrer Radvd-Konfiguration entnehmen
Nach der Konfiguration schließen wir alle noch offenen Dialoge und schreiten zum Test der Einstellungen Zur Abwechslung besuchen wir diesmal die Website des Überprüfen der KAME-Projekts unter http:// www.kame.net
- Mit der Namensauf- Konfiguration lösung und der tanzenden Schildkröte (Abbildung 5.27) ist der Nachweis erbracht, dass auch auf felis alle Einstellungen korrekt vorgenommen wurden