Kategorie:IPv6/Link

Beschreibung

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.