IPv6-Gateway mit Router Advertisement Daemon einrichten (Raspberry Pi)

Ein Raspberry Pi soll als Gateway IPv6 in einem lokalen Netzwerk verfügbar machen. Dazu muss der Raspberry Pi als IPv6-Tunnel-Endpunkt eingerichtet sein.
Die Ausgangssituation ist die, dass man einen 6in4-Tunnel von SixXS hat und den über den Raspberry Pi allen anderen Teilnehmern verfügbar machen will. Der Raspberry Pi wird dabei als IPv6-Gateway eingerichtet, der seinen zugeteilten Präfix an die anderen IPv6-fähigen Teilnehmer weiterreicht.

Hinweis: Bitte beachten, dass der Betrieb eines IPv6-Gateways eine IPv6-Firewall einschließen muss, weil sonst die IPv6-Clients ungeschützt mit dem Internet verbunden sind.

Aufgabe

1. Schalten Sie auf dem Raspberry Pi IPv6-Forwarding ein.
2. Richten Sie einen Dienst ein, der per Router Advertisement den Präfix ins lokale Netzwerk weiterreicht.
3. Prüfen Sie die anderen Teilnehmer im lokalen Netzwerk, ob die sich aus dem Präfix eine globale IPv6-Adresse generiert haben.
4. Prüfen Sie, ob mit diesen Teilnehmern IPv6-Connectivity möglich ist.
5. Installieren sie einen Nameserver für die Namensauflösung mit IPv6.

Vorbereitung

Damit die folgende Lösung funktioniert muss der Raspberry Pi IPv6-fähig sein und er muss bereits als Endpunkt für einen SixXS-Tunnel konfiguriert sein.

• IPv6 auf dem Raspberry Pi einschalten
• Raspberry Pi als IPv6-Tunnel-Endpunkt für SixXS mit aiccu einrichten

Lösung: IPv6-Routing einschalten

Zuerst muss man IPv6-Forwarding einschalten. Das sorgt dafür, dass der Raspberry Pi die IPv6-Pakete zwischen dem LAN und dem SixXS-Tunnel routet. Hierzu muss eine Konfigurationsdatei geändert werden.

sudo nano /etc/sysctl.conf

Hier sucht man folgende Zeile, setzt den Wert hinter dem Gleichheitszeichen auf "1" und entfernt das "#" am Anfang der Zeile.

net.ipv6.conf.all.forwarding=1

Anschließend die Datei speichern und schließen: Strg + O, Return, Strg + X.
Damit die Einstellung übernommen werden empfiehlt sich ein Reboot. Man kann das an dieser Stelle auch überspringen, weil ein Reboot später nochmal notwendig ist.

sudo reboot

Nach dem Neustart muss man dem Raspberry Pi noch eine feste IPv6-Adresse aus dem von SixXS zugeteilten Subnetz zuweisen. Dazu öffnen wir die Konfigurationsdatei mit den Netzwerk-Einstellungen.

sudo nano /etc/network/interfaces

Dort fügen wir folgende Minimal-Konfiguration zusätzlich ein:

# IPv6
iface eth0 inet6 static
pre-up modprobe ipv6
address 2001:db8::1
netmask 64

Die hier verwendete IPv6-Adresse muss durch eine Adresse aus dem eigenen Subnetz ersetzt werden. Wichtig ist hier, dass die IPv6-Adresse aus dem "Subnet Prefix" gewählt wird und nicht aus dem Präfix des Tunnels!
Das IPv6-Gateway braucht zwingend eine statische IPv6-Adresse, damit das Routing funktioniert.
Anschließend die Datei speichern und schließen: Strg + O, Return, Strg + X.

Damit die Einstellung übernommen werden sollte jetzt ein Reboot vorgenommen werden.

sudo reboot

Nach dem Neustart schadet es nicht, wenn man mit "ifconfig" kurz prüft, ob sich der Raspberry Pi die fest konfigurierte IPv6-Adresse zugewiesen hat. Sie sollte der Schnittstelle "eth0" mit dem Vermerk "Global" zugewiesen sein.

Lösung: Präfix im lokalen Netzwerk verteilen (Router Advertisement)

Damit der Raspberry Pi als Gateway dienen kann, muss er den zugewiesenen Präfix (Subnetz) im lokalen Netzwerk per Router Advertisement verteilen. Hierfür eignet sich der Router Advertisement Daemon "radvd", der installiert und dann konfiguriert werden muss.

sudo apt-get install radvd

Nach der Installation muss "radvd" konfiguriert werden.

sudo nano /etc/radvd.conf

In die noch leere Datei trägt man folgende Minimal-Konfiguration ein:

interface eth0 {
AdvSendAdvert on;
AdvLinkMTU 1280;
MaxRtrAdvInterval 120;
prefix 2001:db8::/64 { };
AdvSourceLLAddress on;
};

Hier muss der Präfix durch den eigenen Präfix ersetzt werden. Wichtig ist hier, dass man als "prefix" den von SixXS zugewiesenen "Subnet Prefix" mit der Standard-Netzmaske "/64" einträgt und nicht den Präfix des Tunnels!
Anschließend speichern und schließen: Strg + O, Return, Strg + X.

Nach den Änderungen an der Konfigurationsdatei muss man den Daemon manuell starten.

sudo service radvd start

Wenn der Daemon bereits läuft, ist ein Neustart des Daemons notwendig.

sudo service radvd restart

Jetzt kann man von einem anderen Rechner aus versuchen auf einen IPv6-fähigen Server zuzugreifen. Beispielsweise mit dem Browser auf http://test-ipv6.com/. Hier kann man auch gleich die eigene Connectivity auf IPv6-Fähigkeit testen.

Wenn das nicht funktioniert, also keine IPv6-Fähigkeit vorhanden ist, dann liegt das in der Regel daran, dass "radvd" den falschen Präfix verteilt hat. Typischerweise hat man den Präfix des Tunnels mit dem des Subnetzes verwechselt. Auch wenn sich diese Präfixe ähnlich sind, muss man hier unterscheiden.

Lösung: Nameserver (optional)

Was jetzt noch fehlt ist ein Nameserver für IPv6. Dazu verwenden wir "unbound". Er eignet sich zur Namensauflösung und das Cachen der Ergebnisse. Das Ausliefern von Zonendaten hingegen ist nur sehr begrenzt möglich. Da empfiehlt sich eher "bind9". Aber das ist eine andere Hausnummer und für den Zweck eines IPv6-Gateways völlig überdimensioniert.

sudo apt-get install unbound

Nach erfolgreicher Installation geht es ans Konfigurieren.

sudo nano /etc/unbound/unbound.conf

Hier trägt man als Minimal-Konfiguration folgende Zeilen ein:

server:
verbosity: 1
interface: ::1
interface: 2001:db8::1
port: 53
access-control: ::1/128 allow
access-control: 2001:db8::/64 allow

Hier der Hinweis, dass wir sowohl auf dem Gateway, als auch aus dem lokalen Netz DNS-Anfrage beantworten wollen. Deshalb bedarf es der Angabe für den "localhost" und dem globalen Präfix.
Hier muss sowohl die statische IPv6-Adresse des Gateways (interface) und der eigene Präfix (access-control) eingesetzt werden. Wenn man mit einem Tunnel von SixXS arbeitet, dann ist hier wichtig, den von SixXS zugewiesenen "Subnet Prefix" einzutragen und nicht den Präfix des Tunnels!
Die Eingabe der link-lokalen IPv6-Adresse bzw. des link-lokalen Präfixes mit "fe80" ist an dieser Stelle nicht sinnvoll. Dann wird "unbound" nicht funktionieren.
Anschließend speichern und schließen: Strg + O, Return, Strg + X.

Damit die Einstellungen übernommen werden ist ein Restart des Nameservers notwendig.

sudo service unbound restart

Jetzt wollen wir natürlich wissen, ob er funktioniert. Dazu testen wir den Nameserver mit einer Namensauflösung.

host www.google.de ::1

Das Ergebnis sollte eine Liste mit mehreren IP-Adressen sein. Darunter IPv4- und IPv6-Adressen.
Ob unser Nameserver funktioniert wissen wir aber noch nicht. Dazu schauen wir uns an, welcher Nameserver in die IP-Konfiguration eingetragen ist:

cat /etc/resolv.conf

Hier sollte eine Zeile mit "nameserver ::1" stehen. Wenn nicht, dann muss man ein wenig nachhelfen. Hierzu installieren wir "resolvconf".

sudo apt-get install resolvconf

Danach machen wir noch einmal eine Namensauflösung, führen "resolvconf" aus und schauen uns die Datei "resolv.conf" noch einmal an.

host www.google.de ::1
sudo resolvconf -u
cat /etc/resolv.conf

Jetzt sollte "nameserver ::1" eingetragen sein. Wenn nicht, dann ist irgendetwas an der Gesamtkonfiguration des Systems faul.
Man kann im Prinzip den Nameserver auch händisch in die Konfigurationsdatei schreiben. Allerdings ist das ziemlich sinnlos, weil der Inhalt der Datei automatisch überschrieben wird.

Wenn sichergestellt ist, dass "unbound" lokal auf dem Gateway funktioniert, dann muss man sich noch um das Verteilen der Nameserver-Adresse kümmern. Das erfolgt per Router Advertisement zusammen mit dem Präfix mit der RDNSS-Option. Dazu müssen wir die Konfigurationsdatei des Router Advertisment Daemons ändern.

sudo nano /etc/radvd.conf

Hier fügt man noch vor der schließenden Klammer von "interface etho {" folgende Zeilen ein:

  # Announce DNS Server
RDNSS 2001:db8::1 { };

Hier sollte die IPv6-Adresse des Gateways eingetragen sein. Und zwar die globale, nicht die link-lokale IPv6-Adresse. Manche Betriebssysteme akzeptieren keine link-lokale Nameserver-Adresse.
Anschließend speichern und schließen: Strg + O, Return, Strg + X.

Damit die Einstellungen übernommen werden und die Adresse des Nameservers verteilt wird, muss noch ein Neustart des Router Advertisement Daemons erfolgen.

sudo service radvd restart

Nach dem Neustart ist das IPv6-Gateway vollständig eingerichtet.

Hinweis zum Nameserver

Manche Betriebssysteme kennen die RDNSS-Option leider nicht. Bei diesen Betriebssystemen müsste man den Nameserver statisch festlegen oder die RDNSS-Option nachträglich installieren.
Dass die RDNSS-Option bei manchen Clients fehlt, spielt in einer Dual-Stack-Umgebung (IPv4 und IPv6 im Parallelbetrieb) keine Rolle. Nur in einer reinen IPv6-Umgebung muss jeder Client die RDNSS-Option unterstützen oder den DNS-Server per DHCPv6 zugewiesen bekommen.
Es ist ausreichend, wenn die Clients die Adresse des DNS-Servers über DHCPv4 zugewiesen bekommen. Aus diesem Grund kann man auch auf die Installation des Nameservers für IPv6 verzichten. Zur Namensauflösung verwendet der Client dann einfach IPv4 und bekommt die IPv4-Adresse und falls vorhanden auch die IPv6-Adresse zurück. Sofern der Client eine globale IPv6-Adresse hat wird er die Verbindung wahlweise über IPv4 oder IPv6 aufbauen.
Allerdings ist ein IPv6-Gateway ohne eigenen Nameserver eine ziemlich unfertige Lösung, weil dadurch keine reine IPv6-Connectivity möglich ist. Für die Namensauflösung ist immer noch IPv4 notwendig. Das ist dann doch etwas unbefriedigend. Deshalb macht ein Nameserver für IPv6 durchaus Sinn.

Hinweis zum IPv6-Gateway

Der Raspberry Pi ist ein günstiges Allround-Talent den man für sehr viele Dinge "missbrauchen" kann. Insbesondere auch als Gateway oder Server im eigenen LAN. Dabei sollte man beachten, dass dieser Mini-Computer nicht besonders leistungsfähig ist. Die begrenzte Hardware, was Rechenleistung oder Arbeitsspeicher angeht, sind in diesem konkreten Fall weniger das Problem. Es geht eher um die Geschwindigkeit der Ethernet-Schnittstelle, die am USB hängt und deshalb von der Datenübertragung aller USB-Geräte begrenzt wird. Außerdem hat das IPv6-Gateway keine getrennten Ethernet-Schnittstellen für den ein- und ausgehenden Datenverkehr, sondern nur eine, über die die Datenpakete rein- und wieder rausgehen. Hier sollte man keine Geschwindigkeitswunder erwarten.
Die begrenzte Hardware-Leistung hat natürlich Konsequenzen für die Nutzung des IPv6-Tunnels. Der Dual-Stack (IPv4 und IPv6 im Parallelbetrieb) der Clients werden Dank globaler IPv6-Adresse wahlweise IPv4 und IPv6 benützen. Allerdings wird in der Regel das bevorzugt, was die bessere Connectivity liefert. Da spielt auch die Geschwindigkeit eine Rolle. Wenn der IPv6-Tunnel über den Raspberry Pi zu langsam ist, dann wird ein Client in der Regel IPv4 bevorzugen.

Hinweis zum IPv6-Tunnel

Der Betrieb eines IPv6-Tunnels ist immer langsamer als natives IPv6 und bringt unter Umständen zusätzliche Probleme mit sich. Man sollte also nicht davon ausgehen, das immer dann, wenn IPv6 möglich ist auch immer IPv6 verwendet wird. Dem ist nicht so. Ein Client wird sich in einer Dual-Stack-Umgebung immer für das IP entscheiden, dass die bessere Connectivity liefert. Und das bei einem IPv6-Tunnel tendenziell nicht der Fall.
Trotz aller Einschränkungen und eventueller Probleme kann man die hier dargestellte Lösung in der Praxis dauerhaft betreiben. Allerdings ist ein IPv6-Tunnel "immer" eine vorübergehende (Not-) Lösung, die irgendwann durch einen Dual-Stack (IPv4 und IPv6 im Parallelbetrieb) mit nativem IPv6 abgelöst werden sollte.

Sicherheitshinweis zum IPv6-Tunnel

Achtung! Mit dem Betrieb eines IPv6-Tunnel ist "jeder Rechner im LAN" mit einer eigenen globalen IPv6-Adresse weltweit erreichbar. Jeder kann, sofern eine IPv6-Adresse aus dem LAN bekannt ist, auf diese Rechner zugreifen. Es ist jetzt nicht mehr so, dass man sich wie bei IPv4 per NAT hinter einem Router verstecken kann. Das bedeutet, dass man dafür sorgen muss, dass auf dem Raspberry Pi als Tunnel-Endpunkt eine entsprechend konfigurierte Firewall aktiv ist.

• IPv6-Firewall auf dem Raspberry Pi einrichten