So testest Ihr IPv6 mit Ravello und SixXS 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.

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.

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 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.

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.

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.

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.

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: 

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".

Ü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.

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.

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.

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.

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:

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:

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.