“Wenn etwas nicht einfach zu verstehen ist,
muss es eben anders erklärt werden ...”

So testest Ihr IPv6 mit Ravello und SixXS in der Cloud

Habt Ihr Euch schon mit IPv6 auseinandergesetzt? Ich meine nicht nur in der Theorie - ich meine in der Praxis. Habt Ihr ein Gefühl dafür, wie sich die Stateless Address Autoconfiguration (SLAAC) verhält, wie Router Advertisements funktionieren oder wie das Neighbor-Discocery-Protocoll ARP ersetzt? Braucht Ihr bei IPv6 noch DHCP? Was genau ändert sich im DNS? Wie könnt Ihr am besten IPv6 parallel zu bestehenden IPv4-Diensten betreiben.

Ich selber wurde vor kurzem gebeten, zwei Workshops zum Thema IPv6 durchzuführen. Für diese Workshops wollte ich eine Demo-Umgebung bereitstellen. Gleichzeitig wollte ich - meine letzten Workshops zu diesem Thema sind schon eine Weile her - mein KnowHow zu diesem Thema wieder etwas auffrischen und auf den aktuellen Stand bringen.

Mit Ravello habe ich eine Lösung entdeckt, die auch für Euch interessant sein könnte: Mit Ravello lassen sich komplette Layer-2 Netze in den Cloud-Umgebungen von Google oder Amazon realisieren. Perfekt für alle, die - wie ich - viel von unterwegs arbeiten und zu faul sind, leistungsstarke Notebooks für den performanten Betrieb solcher Testumgebungen mit sich herumzutragen ;-)

In diesem Artikel möchte ich Euch zeigen, wie Ihr mit Ravello eine IPv6-Testumgebung realisiert, die Ihr mit SixXS an den IPv6-basierten Teil des Internet anbinden könnt.

Ravello - die Cloud in der Cloud

Wenn Ihr Euch schon etwas mit dem Testen von IPv6-Umgebungen beschäftigt habt, werdet Ihr vielleicht festgestellt haben, dass die Cloud-Umgebungen von Amazon oder Google im Moment maximal rudimentären IPv6-Support anbieten - das vernetzen der eigenen virtuellen Maschinen per IPv6 ist nicht möglich.

Um IPv6 ausgiebig testen zu können, müsste ich also auf das Hosten eigener virtueller Maschinen ausweichen oder es findet sich doch eine Möglichkeit, trotz der Beschränkungen der Cloud-Umgebungen IPv6 unter Amazon AWS oder der Google Compute-Engine zu realisieren.

Und so eine Lösung gibt es tatsächlich: Ravello Systems bietet mit seiner gleichnamigen Lösung die Möglichkeit der "nested virtualization" (also die verschachtelte Virtualisierung) in bereits virtualisierten Cloud-Infrastrukturen. Das ganze geht dann so weit, dass ihr mit Ravello sogar komplette vSphere-Umgebungen mit ESXi-Servern oder KVM-Virtualisierungshosts laufen lassen könnt. 

Für unsere Zwecke ist jedoch weitaus interessanter, dass ein wichtiger Bestandteil dieser Virtualisierungs-Lösung die Bereitstellung vollständiger Layer-2 Netzwerke zwischen einzelnen virtuellen Maschinen ist. Und diese Netzwerke können wir nutzen, um ungestört unsere IPv6-Tests durchzuführen.

Für den Einstieg bietet Ravello eine zweiwöchige Testphase an, während der Ihr bis zu einem gewissen Umfang komplett kostenfrei virtuelle Umgebungen betreiben könnt.

Aufbau der Testumgebung

Unser Ziel in diesem Artikel: Eine kleine Testumgebung soll zunächst aus zwei virtuelle Maschinen bestehen. Eine der beiden Maschinen wird das IPv6-Gateway. Diese Maschine binde ich per SixXS-Tunnel an das IPv6-Internet an, während die zweite virtuelle Maschine sich komplett selbstständig für IPv6 konfigurieren soll und über das Gateway nach außen kommuniziert.

Spielwiese mit zwei virtuellen Maschinen ...

Als erstes habe ich mir in der Oberfläche con Ravello eine "Application" mit dem Namen "IPv6 Spielwiese" angelegt, in der ich meine virtuellen Maschinen und Netzwerke zusammenstelle.

Wenn Ihr möchtet, könnt Ihr bei Ravello eigene fertige virtuelle Maschinen importieren (OVF) oder selber Betriebssysteme über hochgeladene ISO-Images installieren. Für meine Test-Umgebung greife ich auf die bereitgestellten VM-Templates zurück, die ich per Drag-and-Drop auf den Arbeitsbereich ziehe.

Die zwei Testsysteme
Die Grundkonfiguration der Templates passe ich zunächst nicht weiter an: Ich vergebe lediglich einen Namen und assoziiere für den späteren Zugriff einen SSH-Key mit den VMs.

Konfiguration des Layer-2 Netzwerks

Das Layer-2 Netzwerk ist vorbereitet
Die beiden virtuellen Maschinen werden per Default per DHCP mit privaten IPv4-Adressen versorgt. Der Zugriff auf die virtuellen Maschinen erfolgt per SSH auf die öffentliche Adresse, die der jeweiligen virtuellen Maschine beim Start automatisch zugewiesen wird (wer möchte kann auch statische Adressen in Form von Elastic-IPs vergeben lassen).

Das Layer-2 Netzwerk müssen wir also zunächst nicht konfigurieren. Ich lasse anfangs IPv4 aktiviert, um die Konfiguration zunächst möglichst komfortabel per SSH aus dem IPv4-Netzwerk durchzuführen.

Und ab in die Cloud ...

Anfangs existiert die konfigurierte Umgebung lediglich auf dem Papier. Über einen Klick auf "Publish" wird die Anwendung veröffentlicht. Die Voreinstellungen dabei: Der Cloudanbieter wird anhand der anfallenden Kosten optimiert gewählt und ein Timer sorgt dafür, dass die Testumgebung nach 2 Stunden automatisch wieder beendet wird und so keine weiteren Kosten verursacht.

Publizieren der Anwendung in eine Cloud-Umgebung


Apropos Kosten: Während der 14-tägigen Testphase fallen bei Ravello zunächst keinerlei Kosten für den Betrieb von virtuellen Umgebungen an. Aber auch danach halten sich die Gebühren wirklich im Rahmen. Der Preis für unsere kleine Testumgebung aus 2 VMs beläuft sich im Moment auf 0,3421 Dollar / Stunde. Mein zweistündiger Test wird mich also nicht mehr als 70 US-Cent kosten.

Die Kosten halten sich im Rahmen


IPv6 Konfiguration

Als nächstes steht die IPv6-Konfiguration auf dem Plan. Ich verbinde mich per SSH und dem passenden SSH-Key mit den virtuellen Maschinen. Die dafür notwendige IP-Adresse findet Ihr nach dem Starten der Umgebung in der Übersicht zur jeweiligen VM.

Nach erfolgreicher Anmeldung könnt Ihr mit "ip address show" sehen, dass jedes der beiden Systeme bereits eine IPv6-Adresse erhalten hat. Wobei "erhalten" hier der falsche Ausdruck ist - die sichtbare IPv6-Adresse haben sich die virtuellen Maschinen selber zugewiesen. Dieser Mechanismus des IPv6-Standards sorgt dafür, dass Netzwerk-Knoten ohne weitere Konfiguration sofort miteinander kommunizieren können.

Wer genau hinschaut, kann erkennen, dass die so genannte Link-Local-Adresse von der MAC-Adresse des zugrunde liegenden physischen Interfaces abgeleitet ist: 

IPv6 Link-Local-Konfiguration auf dem Gateway


IPv6 Link-Local-Konfiguration auf dem Client


Das sind also die IPv6 Link-Local-Adressen der beiden Testsysteme:

  • fe80::2ec2:60ff:fe3e:a690/64 (Gateway)
  • fe80::2ec2:60ff:fe37:f3b2/64 (Client)

Das IPv6 tatsächlich auch zwischen den Systemen funktioniert, zeigt ein einfaches ping6. Die Besonderheit beim Kommunizieren mit Link-Local-Adressen ist, dass das für die Kommunikation zu verwendende Interface angegeben werden muss - hier mit dem Kommandozeilenschalte "-I eth0".

Beim ping6 über link-local-Adressen muss das Interface mit angegeben werden

Anbinden an das IPv6-Internet per SixXS

Über SixXS könnt Ihr IPv6-Präfixe und IPv6-Tunnel
kostenfrei beantragen.
Wenn unsere Testumgebung mit der Außenwelt per IPv6 kommunizieren soll, benötigen wir eine IPv6-Adresse (genauer: einen IPv6-Präfix) und einen Netzwerk-Tunnel, der unseren IPv6-Datenverkehr durch unsere IPv4-Internetabindung tunnelt.

Das Projekt "SixXS" bietet die Möglichkeit, beides kostenlos zu realisieren. Auf der Website des Projektes (https://www.sixxs.net/) kann man nach dem Einrichten eines Kontos einen eigenen IPv6-Präfix beantragen.

Anbinden des Gateways mit Hilfe von aiccu

Als Tunnel-Software kommt aiccu zum Einsatz, das bei Ubuntu als Paket in den Standard-Repositories enthalten ist. Während der Installation werden unter Ubuntu die SixXS-Zugangsdaten für den zu nutzenden Tunnel abgefragt, ansonsten können die Werte später auch per Hand in /etc/aiccu.conf eingetragen werden.

Für den Test installiere ich aiccu auf der Gateway-VM (apt-get install aiccu). Danach konfiguriere ich die Zugangsdaten und starte den Tunnel.

aiccu: Konfiguration und Restart


Nach dem erfolgreichen Tunnelstart gibt es auf dem Gateway ein neues Netzwerk-Interface mit dem Namen "sixxs", über das wir bereits direkt den IPv6-basierten Teil des Internet erreichen können. Zum Testen verwende ich hier die IPv6-Adresse eines öffentlichen DNS-Servers von Google und eine Website der selben Firma.

Das IPv6-Internet ist erreichbar


Mein Gateway kann also bereits direkt per IPv6 mit der Außenwelt kommunizieren. In meiner Testumgebung fehlt jetzt nur noch das Routing der Client-VM über das Gateway.

Konfiguration des "Router Advertisement Daemon"

Die oft genannte automatische Konfiguration im IPv6-Netzwerk basiert zum Großteil auf dem "Router Advertisement Protocol". Wenn dieses Protokol im Netzwerk implementiert ist, kann ein Client die wichtigsten Netzwerk-Konfigurationen erfahren, indem er einfach einen Router im Netzwerk um diese Informationen bittet. Anders als beim DHCP-Protokoll schickt der Client seine Konfigurations-Anfrage allerdings nicht per Broadcast in das gesamte Netz, sondern er fragt über eine spezielle Multicast-Adresse nur bei den aktiven Routern im Netzwerk nach. Gleichzeitig geben Router Ihre Informationen in regelmäßigen Abständen allen Knoten im Netzwerk bekannt, die sich dann automatisch auf geänderte Konfigurationen einstellen können.

Folgende Informationen sollen in unserem Fall durch das Gateway zur Verfügung gestellt werden:
  • das zu verwendende IPv6-Netzwerk (der IPv6-Präfix)
  • das zu nutzende Gateway
  • einen nutzbaren DNS-Server
Als Software kommt dazu auf dem Gateway der Router Advertisement Daemon zum Einsatz (bei debian: apt-get install radvd). Dessen Konfiguration liegt unter /etc/radvd.conf und sieht in unserem Beispiel wie folgt aus:

interface eth0
{
    AdvSendAdvert on;
    minRtrAdvInterval 3;
    maxRtrAdvInterval 10;
    prefix 2001:4dd0:ff00:9cf0::/64 {
        AdvOnLink on;
        AdvAutonomous on;
    };
    RDNSS 2001:4760:4860::8888 {} ;
};

Der angegebene Präfix ist das Subnetz, welches uns bei SixXS für unseren Tunnel zugewiesen worden ist. Dem Gateway gebe ich eine feste Adresse aus dem neuen IPv6-Subnetz und aktiviere das IPv6-Forwarding. Anschließend wird der radvd gestartet:

Ohne aktiviertes IPv6-Forwarding verweigert der radvd den Start.

Automatische IPv6-Konfiguration auf dem Client

Nach dem Starten des Router-Advertisement-Daemons auf dem Gateway ist es Zeit, dass wir auf der Client-VM nach dem Rechten schauen: Und wie gehofft, hat die Client-VM eine IPv6-Adresse aus unserem neuen IPv6-Subnetz erhalten - und der Ping an die bekannte Google-Adresse liefert auch schon eine Antwort:

Der Client hat sich automatisch eine IPv6-Adresse aus dem Präfix des Gateways gegeben.


Das Untersuchen der Routing-Tabelle überlasse ich Euch als Übung ;-)

Was noch fehlt (zumindest bei meinem ubuntu-Testclient) ist die automatische Konfiguration des DNS-Servers. Dieser wird zwar vom Gateway durch den radvd übermittelt (der Parameter "RDNSS 2001:4760:4860::8888 {} ;" in der /etc/radvd.conf), fehlt bei meinem Client-System aber in der /etc/resolv.conf.

Um die Konfiguration abzurunden, installiere ich auf dem Ubuntu-Client den "IPv6 recursive DNS server discovery daemon" - kurz rdnssd (apt-get install rdnssd). Anschließend verlasse ich auf dem Client die SSH-Sitzung und melde mich direkt in der Konsole an, die bei Ravello im Browser per VNC zur Verfügung gestellt wird.

Dort gibt es jetzt den abschließenden Funktionstest: Ich deaktivere das Interface eth0. Nach dem erneuten Aktivieren des Interfaces - ausschließlich über "ip link set up dev eth0" - ist die vollständige IPv6-Konnektivität gegeben:

Für die Netzwerkkonfiguration muss ausschließlich das Interface aktiviert werden.

Und es funktioniert ...

Die einzige Konfiguration, die wir auf dem Client-System durchgeführt haben, ist die Installation des rdnssd. Danach genügt es, dass Netzwerk-Interface auf Layer-2 zu aktivieren und der Client erreicht IPv6-Systeme im Internet und ist auch direkt von dort aus zu erreichen.

Und über den letzten Halbsatz solltet Ihr Euch bei der Einführung von IPv6 definitiv genauere Gedanken machen: während interne IPv4-Systeme meist durch NAT auf gewisse Art und Weise vom Internet abgeschottet sind, sind IPv6-Clients normalerweise vollwertig erreichbare Systeme. Entsprechend solltet Ihr Euer Sicherheitkonzept mit der Einführung von IPv6 dahingehend neu durchdenken.

Und was jetzt?

Ihr wisst jetzt, wie Ihr mit Ravello und SixXS ein voll funktionsfähiges Testsystem in der Cloud aufbauen könnt. Dort könnt Ihr die IPv6-Konzepte durchspielen und beobachten, wie sich verschiedene Client-Betriebssysteme in der von Euch geschaffenen Umgebung verhalten. Ihr könnt dort DHCPv6 implementieren, um den Clients weitere Netzwerk-Informationen mit auf den Weg zu geben. Ihr könnt einen Nameserver aufsetzen, der Namen in IPv6-Adressen und umgekehrt auflöst. Ihr könnt Euch Gedanken machen, wie Euer optimales IPv6-Regelwerk auf dem Paketfilter des Gateways aussehen könnte ...

Buchtipp:

Zum Schluss habe ich noch eine Buchempfehlung für Euch: Das Buch "IPv6-Workshop" von Dan Lüdtke (gibt es auch als Kindle Eitition) gibt einen guten Einblick in das IPv6-Protokoll anhand von Beispielen und beschreibt Übergangstechnologien für die Umstellung auf IPv6.