|
|
| Zeile 8: |
Zeile 8: |
| ==== Links ==== | | ==== Links ==== |
| ===== Weblinks ===== | | ===== Weblinks ===== |
|
| |
|
| |
| = Namensauflösung =
| |
| Was den Nodes am Link jetzt noch fehlt, ist ein Nameserver für die Namensauflösung
| |
| * Ein kleiner Test deckt den Missstand auf:
| |
| user@lynx :~ $ ping6 -c 3 ping
| |
| * ipv6 - workshop
| |
| * de unknown host
| |
|
| |
| Ohne die Möglichkeit Namen aufzulösen, verschafft selbst die beste Konnektivität wenig Vorteile
| |
|
| |
| ==== Zielkonfiguration 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
| |
| * Die Zielkonfiguration ist in Abbildung 5.18 zu sehen
| |
| Der Router selbst, aber auch die Hosts können dann DNSAnfragen 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 ==
| |
| ; Schlanker und einfach zu konfigurierender Nameserver
| |
| * Auflösen von Namen und das Cachen der Ergebnisse
| |
| * Ausliefern von Zonendaten ist nur begrenzt möglich (siehe auch [[BIND9]])
| |
|
| |
| == Installation ==
| |
| root@router:~# '''apt install unbound'''
| |
| Reading package lists ..
| |
| Done
| |
| After this operation , 2 ,261 kB of additional disk space will be used
| |
| Do you want to continue [Y/n ]? '''y'''
| |
| Setting up unbound (1.4.16 -1) ..
| |
| Starting recursive DNS server unbound [ OK ]
| |
|
| |
| == Konfiguration ==
| |
| ; Der Nameserver soll sowohl für die Hosts am Link, als auch für fuzzball selbst, zuständig sein
| |
| * Er muss daher auf der Loopback Address und auf einer der Adressen von Interface eth1 lauschen
| |
| * Auf den ersten Blick mag sich da die Linklocal Address anbieten, schließlich befindet sich keiner der potentiellen Benutzer außerhalb des lokalen Scopes
| |
| * Leider akzeptieren nicht alle Betriebssysteme einen Resolving Nameserver mit einer Link-local Address
| |
| * Manche stören sich auch an der Schreibweise mit Interface hinter der Adresse: fe8 ::1%eth
| |
| * Es bleibt uns also nichts anderes übrig, als eine Global Unicast Address zu verwenden
| |
| * Der Dienst soll auf dem Standard-Port 53 angeboten werden
| |
| * Eine Zugriffskontrolle erlaubt dem Präfix des Links internal den Zugriff auf den DNS-Server
| |
| * Versuchen Sie sich ruhig selbst an der Konfiguration! Mit dem Kommando man unbound.conf erhalten Sie alle benötigten Informationen zur Konfigurationsdatei
| |
|
| |
| ; Konfiguration
| |
|
| |
| /etc/unbound/unbound.conf
| |
| server :
| |
| verbosity : 1
| |
|
| |
| interface : ::1
| |
| interface : 2a01:198:200:8a23::1
| |
|
| |
| port : 53
| |
|
| |
| access - control : ::1/128 allow
| |
| access - control : 2a01:198:200:8a23::/64 allow
| |
|
| |
| ; Neustart des Nameservers
| |
| root@router:~# '''service unbound restart'''
| |
| Restarting recursive DNS server unbound [ OK ]
| |
|
| |
| === Nameserver testen ===
| |
| ; Mit dem Kommando host können wir uns von der Funktion des Nameservers überzeugen
| |
| * Das erste Argument ist der aufzulösende Hostname, das zweite und optionale Argument benennt den zu befragenden Nameserver
| |
| * Wir werden natürlich unseren eigenen Nameserver befragen, weshalb wir ihn auf der Loopback Address ansprechen:
| |
|
| |
| user@fuzzball :~ $ host www
| |
| ipv6 - workshop
| |
| de ::1
| |
| Using domain server :
| |
| Name : ::1
| |
| Address : ::1#53
| |
| www
| |
| ipv6 - workshop
| |
| de has IPv6 address '
| |
| 2 1:67 c :26 f4 :8 ::6:8
| |
|
| |
| == Nameserver festlegen ==
| |
| Wenn der Server wie erwartet antwortet, definieren wir ihn, falls das System es nicht bereits in vorrauseilendem Gehorsam getan hat, auf fuzzball 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 lynx:
| |
|
| |
| 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
| |
|
| |
| == 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 fuzzball 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
| |
|
| |
| [[Kategorie:IPv6/Link]]
| |
| </noinclude>
| |