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

ELektronik-KOmpendium.de
Online

Preis auf Anfrage

Wichtige informationen

  • Kurs
  • Online
Beschreibung

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.

Wichtige informationen

Was lernen Sie in diesem Kurs?

Service
Router
Server
Interface
Firewall
DNS
Installation
Access

Themenkreis

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

Den Status von "unbound" prüft man wie folgt:

sudo service unbound status

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.

Troubleshooting: Wenn das IPv6-Gateway mal nicht funktioniert

In der Regel wird das IPv6-Gateway mehrere Wochen und Monate ohne Probleme und damit ohne Aufsicht durchlaufen. Wenn es nicht oder nicht richtig funktioniert wird man davon in der Regel nichts mitbekommen, weil IPv4 nebenher parallel läuft. In der Regel wird man ein Problem nur dann erkennen, wenn bei typischen IPv6-Gegenstellen kein IPv6 mehr verwendet wird.

Wenn das Gateway mal nicht richtig funktioniert, dann hilft im einfachsten Fall ein Neustart.

sudo reboot

Wenn das IPv6-Gateway nicht funktioniert, also keine IPv6-Verbindungen möglich sind, dann sollte man die Schnittstellen auf dem Gateway prüfen.

ifconfig

Es müssen standardmäßig 4 Schnittstellen vorhanden sein: eth0, lo, sit0 und sixxs. Fehlt eine, dann stimmt was nicht. eth0 und lo werden immer da sein. Die Schnittstellen sit0 und sixxs sind virtuelle Schnittstellen für den Tunnel. Sie werden von "aiccu" eingerichtet. Fehlt eine davon, dann kann das Gateway natürlich nicht funktionieren.

Den Status des Tunnel-Dienstes erfährt man wie folgt:

sudo service aiccu status

Eventuell hilft ein Restart des Tunnels:

sudo service aiccu restart

Wenn das nicht die Lösung ist, dann sollte man prüfen, ob die Clients globale IPv6-Adressen vom RA-Daemon bekommen haben. Wenn nicht, dann sollte man den Status des RA-Daemons prüfen.

Den Status des RA-Daemons erfährt man wie folgt:

sudo service radvd status

Eventuell hilft ein Restart:

sudo service radvd restart

Grundsätzlich sollte man nach einem Restart des RA-Daemons einen Reboot vornehmen. Nur dann man sicher sein, dass das Gateway auch nach einem Neustart ordnungsgemäß funktioniert. Ein Neustart kann auch durch einen Stromausfall verursacht werden.

Unter Umständen funktioniert die Namensauflösung nicht.

Den Status von "unbound" prüft man wie folgt:

sudo service unbound status

Eventuell hilft ein Restart:

sudo service unbound restart

Prüfen sollte man auch, ob das System den richtigen Nameserver übernommen hat.

cat /etc/resolv.conf

Hier sollte eine Zeile mit "nameserver ::1" stehen. Wenn nicht muss man händisch etwas nachhelfen.

sudo resolvconf -u

Wenn das IPv6-Gateway im Netzwerk Probleme macht, dann kann man es auch einfach mal außer Betrieb nehmen und prüfen, ob das Netzwerk ohne Gateway funktioniert. Dazu setzt man den RA-Daemon außer Betrieb.

sudo service radvd stop

Das Gateway muss aber nicht zwangsläufig mit Netzwerk-Problemen zu tun haben, aber eine Komponente weniger, ist eine Fehlerquelle weniger. Wenn das Netzwerk auch ohne Gateway nicht richtig funktioniert, dann muss man im lokalen Netzwerk auf die Suche gehen. Sind die behoben, dann kann man das IPv6-Gateway wieder in Betrieb nehmen.

sudo service radvd start

Ein Reboot ist zu empfehlen.

sudo reboot

Anschließend sind die IPv6-Gateway-Dienste zu prüfen.

sudo service aiccu status sudo service radvd status sudo service unbound status cat /etc/resolv.conf 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. Dabei bekommt er 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 je nach Modell, die Hardware Grenzen hat. Außerdem hat der Raspberry Pi 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.

Was man auch wissen sollte ist, dass man in dieser Konstellation auf Aktualisierungen per "apt-get upgrade" verzichten sollte. Es kann nämlich vorkommen, dass danach das Gateway nicht richtig oder gar nicht funktioniert. In so einem Fall muss man sich viel Zeit für die Fehlersuche nehmen und eventuell eine Neueinrichtung vornehmen.

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. Wenn der IPv6-Tunnel zu langsam ist, dann wird ein Client in der Regel IPv4 bevorzugen.
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-Tunnels ist "jeder Rechner im LAN" mit einer eigenen globalen IPv6-Adresse weltweit erreichbar. Jeder kann von extern, 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
  • Raspberry Pi als Server im Dauerbetrieb (24/7, headless)
Weitere verwandte Themen:
  • IPv6 auf dem Raspberry Pi einschalten und konfigurieren
  • Feste IPv6-Adresse für den Raspberry Pi einrichten
  • IPv6-Tunnel für SixXS mit aiccu einrichten (Raspberry Pi)
  • IPv6-Firewall für einen IPv6-Tunnel einrichten (Raspberry Pi)

Hinweis: Dieses Tutorial ist Teil einer Aufgaben und Übungen mit dem Raspberry Pi-Reihe, die für Lern- und Ausbildungszwecke erstellt wurde. Die dargestellte Lösung ist Teil einer konkreten Aufgabenstellung, die Schüler, Auszubildende und Studenten, lösen sollen. Deshalb muss der hier aufgezeigte Weg nicht der Optimalfall sein.