|
|
| (5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| === Beschreibung ===
| | [[Kategorie:IPv6]] |
| ; Zur Zeit ist Link internal noch unbelebt
| |
| * Die Nodes haben gelegentlich über Link-local Addresses miteinander kommuniziert, dabei die gegenseitige Erreichbarkeit nachgewiesen und ihre Neighbor Caches gepflegt.
| |
| * Was den Hosts fehlt, ist der Zugang zur großen weiten IPv6-Welt.
| |
| * Da könnte fuzzball weiterhelfen, er hat dank des Tunnels bereits Zugang zu ihr.
| |
| * Im Folgenden werden wir daher den Router fuzzball bestimmungsgemäß einsetzen, die Hosts mit gültigen, weltweit eindeutigen Adressen versorgen sowie ihre Konnektivität überprüfen.
| |
| | |
| === Präfix ===
| |
| [[IPv6/Link/Präfix]] | |
| | |
| === Stateless Address Autoconfiguration ===
| |
| [[IPv6/Link/Präfix/SLAAC]]
| |
| | |
| === 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.
| |
| | |
| ==== Installation von Unbound ====
| |
| Ein schlanker und einfach zu konfigurierender Nameserver ist Unbound.
| |
| * Seine Stärke ist das Auflösen von Namen und das Cachen der Ergebnisse.
| |
| * Das Ausliefern von Zonendaten hingegen ist nur sehr begrenzt möglich.
| |
| * Wenn Sie auch auf diesem Gebiet experimentieren möchten, sollten Sie zu Bind9 als Nameserver greifen.
| |
| * Im Workshop werden wir mit Unbound arbeiten, ein Austausch ist aber jederzeit möglich.
| |
| | |
| Installiert wird Unbound über die Paketverwaltung:
| |
| root@fuzzball :~# apt - get 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 von Unbound ====
| |
| 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.
| |
| | |
| Unter Beachtung der eben genannten Anforderungen ergibt sich eine Konfiguration wie in Abbildung 5.19 gezeigt.
| |
| Sobald die Konfigurationsdatei geschrieben wurde, starten wir den Nameserver neu:
| |
| root@fuzzball :~# 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
| |
| | |
| : Abbildung 5.19 Konfiguration von Unbound
| |
| | |
| /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
| |
| | |
| 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@fuzzball :~# resolvconf -u
| |
| root@fuzzball :~# 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@lynx :~ $ 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 uns, 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@fuzzball :~# 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.
| |
| * In Abbildung 5.21 ist das Router Advertisement zu sehen.
| |
| | |
| 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 5.20: Konfiguration von Radvd mit RDNSS Address
| |
| | |
| : Abbildung 5.21: 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 ;
| |
| };
| |
| | |
| | |
| Wie so häufig, müssen wir auch hier wieder eine 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 ====
| |
| Die hostseitige Unterstützung für die RDNSS Option ist leider 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 noch 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 5.22 NetworkManager: Einstellungen und Profile
| |
| | |
| : Abbildung 5.23 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.
| |