|
|
| (7 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.
| |
| | |
| {{:IPv6/Link/Präfix}}
| |
| | |
| === Stateless Address Autoconfiguration ===
| |
| ==== Zweck ====
| |
| Die Stateless Address Autoconfiguration, kurz SLAAC, dient der automatischen Konfiguration von Adressen und Routen der Hosts am Link.
| |
| * Damit reduziert IPv6 als Protokoll die
| |
| | |
| Abhängigkeit von dritten Komponenten zur Organisation des Links.
| |
| * Die Nutzung von Stateless Address Autoconfiguration erfordert keine manuelle Konfiguration der Hosts und nur sehr wenige Konfigurationsschritte auf dem Router.
| |
| * Damit einher geht der Verlust einer strengen Zuordnung von Adressen zu bestimmten Hosts.
| |
| * In Umgebungen wo die Zuordnung von Adressen zu Hosts zentral gesteuert werden soll, ist dieser Ansatz nicht ausreichend.
| |
| * Dort würde man auf DHCPv6 zurückgreifen.
| |
| * Aber auch ein simultaner Betrieb von DHCPv6 und Stateless Address Autoconfiguration wäre denkbar.
| |
| | |
| ==== Autoconfiguration ====
| |
| SLAAC ist Bestandteil der Autoconfiguration, die drei wesentliche Aufgaben hat:
| |
| * Generieren einer Link-local Address
| |
| * Durchführen der Stateless Address Autoconfiguration
| |
| * Sicherstellen der Eindeutigkeit der generierten Adressen (Duplicate Address Detection)
| |
| | |
| ==== Prinzipieller Ablauf ====
| |
| : Abbildung 5.9 Prinzip von SLAAC
| |
| | |
| Den ersten Schritt macht der Host, indem er mittels Router Solicitation nach einem Router Advertisement fragt.
| |
| * Alternativ könnte er auch ein periodisches Router Advertisement abwarten, diese Geduld beobachtet man aber eher selten.
| |
| Der Router verschickt das angeforderte Router Advertisement, welches alle konfigurationsrelevanten Daten enthält (Wir gehen der Einfachheit halber von nur einem Router aus.)
| |
| | |
| Daraufhin führt der Host die Konfiguration des Interfaces durch und prüft die Eindeutigkeit der selbst erzeugten Adressen.
| |
| * Erst wenn diese Eindeutigkeit angenommen werden kann, ist die Konfiguration des Interfaces vollständig und gilt als beendet.
| |
| | |
| ==== Duplicate Address Detection ====
| |
| Hinter der Duplicate Address Detection verbergen sich eigentlich mehrere Neighbor Solicitations.
| |
| * Wenn ein Node feststellen möchte, ob eine Adresse schon von einem anderen Node genutzt wird, dann versucht er die zugehörige Linklayer Address aufzulösen.
| |
| * Bleibt eine Antwort aus, benutzt offensichtlich kein anderer Node auf dem Link die überprüfte Adresse.
| |
| * Um Fehlschlüsse aufgrund von Paketverlusten zu vermeiden, sollen mehrere Neighbor Solicitations verschickt werden.
| |
| Ab wann eine Adresse als eindeutig gilt, hängt von den Parametern der jeweiligen Implementierung ab.
| |
| * Jede Adresse hat anfangs den Status tentative (probeweise).
| |
| * Erst wenn die Duplicate Address Detection vollständig durchlaufen wurde, und keine Anzeichen darauf schließen lassen, dass die
| |
| Adresse bereits in Benutzung ist, wird die Adresse valid (gültig).
| |
| | |
| ==== Autoconfiguration mitschneiden ====
| |
| Wir werden versuchen eine komplette Autoconfiguration von lynx mit Wireshark aufzufangen.
| |
| * Vom Hochfahren des Interfaces bis zu seiner endgültigen Konfiguration.
| |
| Dazu öffnen wir ein root-Terminal auf lynx und fahren das Interface eth0 herunter:
| |
| root@lynx :~# ip link set down dev eth
| |
| | |
| Nun starten wir Wireshark und lassen ihn auf dem PseudoInterface any lauschen.
| |
| Danach fahren wir eth0 wieder hoch:
| |
| root@lynx :~# ip link set up dev eth
| |
| | |
| In Wireshark können wir bereits Aktivität beobachten.
| |
| * Wir warten den Abschluss der Konfiguration ab, sie ist erfolgreich verlaufen wenn wir Adressen mit den Parametern scope global und dynamic sehen:
| |
| 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 3578 sec preferred_lft 1778 sec inet6 fe8 ::2 : ff : fe6 : d1e /64 scope link valid_lft forever preferred_lft forever
| |
| | |
| Wireshark kann jetzt den Mitschnitt beenden.
| |
| * Von den vielen Paketen die wir mitgeschnitten haben sind nicht alle von Interesse.
| |
| | |
| ==== Multicast DNS ====
| |
| Insbesondere die Pakete vom Typ Multicast DNS (mDNS) werden wir an dieser Stelle ignorieren.
| |
| * Multicast DNS erlaubt die Auflösung von Namen der Domain .local zu Linklocal Addresses.
| |
| * Leider belastet es dazu den Link ungefragt mit allerlei Paketen.
| |
| * Da wir im Workshop keine lokale Namensauflösung auf Multicast-Basis nutzen, kümmern wir uns nicht weiter um dieses Protokoll.
| |
| * Mehr zu Multicast DNS und seinem Nutzen für kleine Netze findet sich auf der gemeinsamen Website der Beteiligten Interessensgruppen. (http://www.multicastdns.org/)
| |
| | |
| ==== Multicast Listener Report (Solicited Node) ====
| |
| Das erste interessante Paket im Mitschnitt ist ein Multicast Listener Report und wurde von lynx verschickt.
| |
| * Der IPv6-Header ist in Abbildung 5.10 zu sehen.
| |
| | |
| : Abbildung 5.10 SLAAC Paket 1: IPv6-Header
| |
| | |
| Als Quelladresse hat lynx die Unspecified Address gewählt.
| |
| Das heißt, zum Zeitpunkt des Versendens stand keine passende, gültige Adresse zur Verfügung.
| |
| * Die Zieladresse ist die Multicast Address für alle MLDv2-fähigen Router.
| |
| * Zu finden auch in der Tabelle 4.5 in Abschnitt 4.5 Multicast.
| |
| * Uns fällt das für MLDv2 Messages typische Hop Limit von 1 auf.
| |
| * Bemerkenswert ist auch der Einsatz des Hop-by-Hop Options Extension Headers.
| |
| * Neben der Padding Option, welche den Extension Header auf eine einheitliche Länge auffüllt, ist auch eine Router Alert Option vorhanden.
| |
| * Sie informiert Multicastfähige Router darüber, dass sich eine MLDv2 Message im Paket befindet.
| |
| * Interessierte Router werten die Nachricht dann aus und ziehen daraus Schlüsse für ihr Multicast Routing.
| |
| * Die MLDv2 Message kann in Abbildung 5.11 eingesehen werden.
| |
| | |
| Genaugenommen handelt sich um eine MLDv2 Message der Art Changed to Exclude.
| |
| * Wir haben in Abschnitt 4.5 Multicast bereits besprochen wie dieser Typ zu interpretieren ist.
| |
| * Hier wird die Multicast Address ff 2::1:ff6 :d1e für alle potentiellen Multicast-Quellen freigegeben.
| |
| * Die Nachricht entspricht dem Beitritt zur Multicast Group ff 2::1:ff6 :d1e.
| |
| * Es handelt sich dabei um die Solicited Node Multicast Address von Interface eth0 auf lynx.
| |
| | |
| ==== Gruppenbeitritt ====
| |
| Zu diesem Zeitpunkt hat lynx also bereits einen Interface Identifier erzeugt.
| |
| * Der Beitritt zur entsprechenden Multicast Group gewährt ihm Zugang zu den Paketen dieser Gruppe.
| |
| | |
| : Abbildung 5.11 SLAAC Paket 1:Multicast Listener Report
| |
| | |
| So hat er die Chance, frühzeitig zu erfahren, ob sein Interface Identifier schon verwendet wird.
| |
| * Würde ein anderer Node seinen Interface Identifier bereits verwenden, so wäre dieser Node ebenfalls Mitglied der Multicast Group.
| |
| * Eine doppelt vorkommende Adresse würde dadurch schneller auffallen.
| |
| | |
| ==== Gruppen mit mehreren Mitgliedern ====
| |
| Es wäre allerdings auch möglich, dass ein anderer Node eine ähnliche Adresse verwendet.
| |
| * Beispielsweise eine Adresse bei der sich die letzten 24 Bits gleichen.
| |
| * Beide Nodes wären nun in derselben Gruppe, jene mit der gemeinsamen Solicited Node Multicast Address.
| |
| * Beide Nodes würden auch Pakete empfangen, die nicht für sie bestimmt wären, die aufgrund der Ähnlichkeit der Adresse aber an die gemeinsame Gruppe geschickt wurden.
| |
| * Jeder Node muss deshalb prüfen, ob ein Paket, welches an die Gruppe adressiert wurde, auch wirklich für ihn von Belang ist.
| |
| * Auch lynx könnte Pakete empfangen, nach der Prüfung des Inhaltes aber feststellen, dass der eigene Interface Identifier davon nicht betroffen ist.
| |
| | |
| ==== Duplicate Address Detection (Link-local) ====
| |
| Möchte lynx nun feststellen, ob die von ihm gewählte Adresse nicht nur vielleicht eindeutig ist, dann ist eine Duplicate Address Detection erfolgsversprechender.
| |
| * Wenn sie fehlschlägt, dann ist die von lynx gewählte Adresse sehr wahrscheinlich
| |
| | |
| : Abbildung 5.12: SLAAC Paket 2: Neighbor Solicitation
| |
| | |
| auf dem Link noch nicht vergeben.
| |
| * Eine endgültige Gewissheit ist mit der Duplicate Address Detection nicht zu erreichen.
| |
| * Im ungünstigsten Fall gehen genau jene Pakete verloren, die auf eine doppelte Adresse hinweisen würden.
| |
| * Dazu sendet lynx eine Neighbor Solicitation für die selbst erzeugte Adresse aus (siehe Abbildung 5.12).
| |
| Als Quelladresse wählt er wieder die Unspecified Address, da die Link-local Address noch nicht als eindeutig gilt.
| |
| * Die Neighbor Solicitation geht an die Solicited Node Multicast Address der zu überprüfenden Link-local Address.
| |
| * Im Feld Target Address taucht die gewünschte Adresse fe8 ::2 :ff:fe6 :d1e schließlich auf.
| |
| Das Ausbleiben eines Neighbor Advertisements wertet der Node als Anzeichen für die Eindeutigkeit seiner Adresse auf dem Link.
| |
| * Sie wird dann dem Interface zugewiesen und gilt fortan als valid.
| |
| | |
| ==== Router Solicitation ====
| |
| Nachdem lynx nun eine gültige Link-local Address hat, versucht er auch eine gültige Adresse für den Global Scope zu erhalten.
| |
| * Dazu lässt er sich von jedem Router am Link ein Router
| |
| | |
| : Abbildung 5.13: SLAAC Paket 3: Router Solicitation
| |
| | |
| Advertisement zukommen.
| |
| * Die Anforderung der Router Advertisements geschieht mit Hilfe einer Router Solicitation, die in Abbildung 5.13 zu sehen ist.
| |
| | |
| Die Nachricht wird von der Link-local Address des Hosts gesendet, hier von der Adresse fe8 ::2 :ff:fe6 :d1e.
| |
| * Als Zieladresse wird die All Routers Multicast Address ff 2::2 verwendet, die wir schon in der Tabelle 4.5 in Abschnitt 4.5 Multicast gesehen haben.
| |
| * Angehängt an die Router Solicitation ist, eine ICMPv6-Option mit der Link-layer Address des Absenders.
| |
| | |
| ==== Router Advertisement ====
| |
| Alle Router am Link antworten auf die Router Solicitation mit einem Router Advertisement.
| |
| * Da wir nur einen Router am Link haben, nämlich fuzzball, erhalten wir auch nur ein Router Advertisement.
| |
| | |
| Wir werden es hier nicht genauer besprechen, denn das haben wir in Abschnitt 5.1 Ein Präfix für den Link schon getan.
| |
| * Ein auffrischender Blick in das Paket wird aber sicher nicht schaden.
| |
| | |
| : Abbildung 5.14: SLAAC Paket 5: IPv6-Header
| |
| | |
| Nach dem Erhalt des Router Advertisements erzeugt lynx eine Global Unicast Address.
| |
| * Dazu verwendet er das von fuzzball verteilte Präfix und den bereits vorhandenen Interface Identifier.
| |
| | |
| ==== Multicast Listener Report (Solicited Node, Multicast-DNS) ====
| |
| Auch für diese Adresse muss eine Duplicate Address Detection durchgeführt werden.
| |
| * Die beginnt wieder mit dem Beitritt zu der passenden Multicast Group.
| |
| * Obwohl sich die Solicited Node Multicast Address für die Global Unicast Address nicht von der für die Link-local Address unterscheidet, versendet lynx einen neuen Multicast Listener Report.
| |
| * Der wesentliche Unterschied ist die Quelladresse des Paketes, siehe auch Abbildung 5.14.
| |
| | |
| Anstatt der Unspecified Address kommt diesmal die Link-local Address zum Einsatz.
| |
| * Der Rest des Paketes ist in Abbildung 5.15 dargestellt.
| |
| | |
| Unverändert geblieben ist der Beitritt zur Solicited Node Multicast Group, der erneut mithilfe von Changed to Exclude erreicht wurde.
| |
| * Und einen weiteren Gruppenbeitritt können wir
| |
| | |
| : Abbildung 5.15 SLAAC Paket 5: Multicast Listener Report
| |
| | |
| im Paket entdecken, der Beitritt zur Gruppe ff 2::fb.
| |
| * Dies ist die Multicast DNS Address für die Verwendung mit IPv6, und für unser Netz nicht weiter wichtig.
| |
| | |
| ==== Duplicate Address Detection (Global Unicast) ====
| |
| Der letzte Schritt ist die Durchführung der Duplicate Address Detection für die Global Unicast Address.
| |
| * Dazu sendet lynx wieder eine Neighbor Solicitation, zu sehen in Abbildung 5.16, aus.
| |
| | |
| Mit dem Ausbleiben einer Antwort ist die Stateless Address Autoconfiguration abgeschlossen.
| |
| * Das Interface eth0 ist nun fertig konfiguriert.
| |
| | |
| ==== Konnektivitätstest ====
| |
| Einem Test der Konnektivität von lynx steht nun nichts mehr im Wege.
| |
| * Dazu verschicken wir Echo Requests von lynx an den Tunnelendpunkt von SixXS:
| |
| | |
| user@lynx :~ $ ping6 -c 3 2 a 1 :198:2 : a23 ::1
| |
| PING 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) 56 data '
| |
| bytes
| |
| 64 bytes from 2 a 1 :198:2 : a23 ::1: icmp_seq =1 ttl =63 '
| |
| time =8. 2 ms
| |
| 3 packets transmitted , 3 received , % packet loss , time '
| |
| 2 3 ms
| |
| | |
| : Abbildung 5.16: SLAAC Paket 6: Neighbor Solicitation
| |
| | |
| Da Echo Replies eintreffen, können wir davon ausgehen dass das Routing funktioniert.
| |
| * Den Beweis können wir auch mit traceroute6 antreten:
| |
| user@lynx :~ $ traceroute6 -n 2 a 1 :198:2 : a23 ::1
| |
| traceroute to 2 a 1 :198:2 : a23 ::1 (2 a 1 :198:2 : a23 ::1) , '
| |
| 3 hops max , 8 byte packets
| |
| 1 2 a 1 :198:2 :8 a23 ::1 2.2 4 ms
| |
| .162 ms
| |
| .193 ms
| |
| 2 2 a 1 :198:2 : a23 ::1 13.255 ms 13.412 ms 19.135 ms
| |
| | |
| An erster Stelle steht der nächste Hop, in unserem Fall die Adresse des Interfaces eth1 von fuzzball.
| |
| * Schon in der zweiten Zeile ist das Ziel erreicht.
| |
| | |
| ==== SLAAC unter Windows 8 ====
| |
| Nun werden wir die eben erworbenen Fähigkeiten zur Analyse einer Autoconfiguration auf felis anwenden.
| |
| * Bei dieser Gelegenheit werden wir auch Unterschiede entdecken, die durch Aktivierung von Privacy Extensions auftreten.
| |
| * Dazu öffnen wir als Administrator ein Terminal und stellen sicher das die Privacy Extensions aktiviert sind.
| |
| * Nach dem Betätigen der Tastenkombination Windowstaste+X erscheint ein Menü in dem wir den Punkt Command Prompt (Admin) auswählen:
| |
| | |
| : Abbildung 5.17 SLAAC unter Windows 8
| |
| C :\ Users \ user > netsh interface ipv6 set global randomizeidentifiers = enabled
| |
| Ok.
| |
| | |
| Leider kommt es unter Windows 8 beim Betrieb von Wireshark manchmal zu Problemen.
| |
| * Der benötigte Treiber zum Mitschnitt von Daten heißt Windows Packet Capture (WinPcap), je nach Update-Stand von felis kann er funktionieren oder auch nicht.
| |
| * Als Lösung bietet es sich an, den Verkehr von eth1 auf fuzzball mitzuschreiben, auch dort kommen die Pakete vorbei.
| |
| Sobald Wireshark bereit ist, deaktivieren wir die LAN-Verbindung auf felis und aktivieren sie anschließend wieder.
| |
| * Bei einer Beobachtung von fuzzball aus, können wir alternativ auch einen Neustart von felis durchführen.
| |
| * In beiden Fällen ergibt sich ein Mitschnitt, der dem aus Abbildung 5.17 ähnlich sieht.
| |
| | |
| ==== Eigene Untersuchungen ====
| |
| Untersuchen Sie die einzelnen Pakete und finden Sie heraus, zu welchem Zweck jedes einzelne versendet wurde.
| |
| * Sie können sich dabei auf ICMPv6 beschränken und auch die
| |
| Teile von MLDv2, die sich um Multicast DNS drehen, ignorieren.
| |
| * Erkennen Sie anhand der Informationen in den Paketen, ob diese sich auf einen zufälligen (Privacy Extensions)
| |
| oder auf einen EUI-64-basierten Interface Identifier beziehen?
| |
| | |
| : Abbildung 5.18: Interner Link mit DNS-Server
| |
| | |
| === 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.
| |