Raspberry Pi VPN – Teil 5: Vorarbeiten für ein VPN unter IPv6

Helmut 21. Juli 2019 26 Kommentare

Der vorhergegangene Artikel hat sich mit dem Aufbau eines VPN-Servers unter IPv4 beschäftigt. Nun kommt das gleiche für IPv6. Da dieses Thema etwas umfangreicher ist, teile ich es auf zwei Beiträge auf. In diesem ersten erledigen wir die Vorarbeiten. Der Raspberry Pi wird grundkonfiguriert und im Heimnetzwerk angeschlossen. Dann werden wir überprüfen, ob er auch eine IPv6 Adresse hat. Wenn das der Fall ist können wir dynamisches DNS und eine Freigabe am Router einrichten – alles mit IPv6 versteht sich. Wem die Funktion eines Virtual Private Network noch nicht vertraut ist, oder wer sich unklar ist, ob er IPv4 oder IPv6 verwenden soll, dem empfehle ich die ersten drei Artikel dieser Serie.

Was wird benötigt

Diese Liste unterscheidet sich auf den ersten Blick nur wenig von der im vorangegangenen Artikel – die Feinheiten liegen bei den letzten drei Punkten. Also was brauchen wir für ein VPN unter IPv6:

• Einen Raspberry Pi 3 oder neuer. Es geht sicher auch mit einem Raspi 2, aber der hat kein WLAN on board.
• Einen LAN oder WLAN Anschluss für den Raspberry Pi im eigenen Heimnetzwerk.
• Eine global routbare IPv6 Adresse für unseren Raspberry PI, deren Präfix aber periodisch wechseln darf.
• Einen DDNS-Provider, der IPv6 unterstützt (das wird in diesem Artikel weiter unten erklärt)
• Ein Android Smartphone als äußeren Tunnelendpunkt. Die Konfiguration erfolgt in einem späteren Artikel. Das Smartphone muss beim Tunnelbetrieb ebenfalls mit einem IPv6-Netzwerk verbunden sein.

Vorarbeiten

Raspberry Pi Grundkonfiguration

Kümmern wir uns zuerst um den Raspberry Pi. Wie man dessen Betriebssystem Raspbian aufspielt und grundsätzlich einrichtet, habe ich bereits öfter in meinem Blog beschrieben, so dass ich hier auf einen früheren Artikel verweise und nur kurz die Schritte dazu aufzähle.

• Raspbian downloaden, und zwar die aktuelle Lite-Version. Wir werden den RasPi per SSH administrieren und brauchen keinen grafischen Desktop. Ich verwende Raspbian Stretch Lite in der Version vom 13.11.2018, aber jede neuere Version dürfte ebenso gut funktionieren.
• Raspbian entpacken und auf die SD-Karte schreiben
• SSH aktivieren
• WLAN konfigurieren (nur falls WLAN verwendet werden soll, wer den RasPi per Kabel ans LAN anschließt, kann diesen Schritt überspringen.)
• SD-Karte in den Raspberry Pi stecken und Raspi hochfahren.
• Per SSH am RasPi anmelden (Rechnername: raspberrypi, Username: pi, Passwort: raspberry)
• In raspi-config das Passwort ändern, einen anderen Hostnamen vergeben und die Localisation Options an deutsche Verhältnisse anpassen
• Raspberry Pi neu booten.

Software richten wir jetzt noch nicht ein – zuerst braucht es ein paar weitere Vorarbeiten.

IPv6 für den Raspberry PI

Die gute Nachricht gleich zuerst: Unser Raspberry Pi hat bereits IPv6 aktiviert und eine (oder mehrere) IPv6 Adressen erhalten, obwohl wir weder am RasPi noch am DHCP-Server (Router) etwas dafür eingerichtet hatten. Wir sind noch per SSH mit dem Raspberry Pi verbunden und können das gleich mal mit ifconfig überprüfen:

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.167  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::7755:bf46:529:6c60  prefixlen 64  scopeid 0x20<link>
        inet6 2001:a61:3555:d001:caf0:a067:58b1:4753  prefixlen 64  scopeid 0x0<global>
        inet6 fd00::443c:43c5:6e21:e64e  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:aa:f7:71  txqueuelen 1000  (Ethernet)
        RX packets 1530  bytes 144740 (141.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 700  bytes 132086 (128.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Ich habe hier nur das wlan0 Interface heraus kopiert, da mein Raspberry Pi keinen LAN Anschluss hat. Andernfalls wäre es Interface eth0. Wir sehen neben einer IPv4 Adresse hat der RasPi drei IPv6 Adressen. Ich kann im Rahmen dieses Artikels natürlich nicht IPv6 komplett erklären, aber ein paar Dinge können wir hier bereits erkennen:

• Unter IPv6 kann ein Interface mehrere IP-Adressen haben und im Normalfall hat es das auch.
• Die IPv6 Adressen konfigurieren sich quasi automatisch, ohne dass wir irgendwas per DHCP einrichten müssen, wie bei IPv4.
• Ein Interface kann gleichzeitig IPv4 und IPv6 Adressen haben.

Lenken wir unser Augenmerk auf die zweite IPv6 Adresse, also die, die in meinem Beispiel mit 2001 beginnt. Das ist eine global routbare IPv6-Adresse, sie ist also im gesamten Internet nur einmal vorhanden und würde unser Router das zulassen, könnte sie auch aus dem Internet angesprochen werden. Woher weiß ich das? Man sieht es zum einen am Beginn des Präfix, wenn die ersten drei Bits binär = 001 sind, dann befinden wir uns in einem bereits zugewiesenen Bereich der globalen Unicast-Adressen. (Das kann man googeln oder ein schlaues Buch lesen.) Und diese drei Bits, durch eine 0 ergänzt, geben die hexadezimale 2 aus besagtem Adressbeginn 2001. Zum anderen entspricht der komplette Präfix also 2001:a61:3555:d001 genau dem Präfix, den meine Fritz!Box vom Provider erhalten hat.

Der Präfix ist die vordere Hälfte einer IPv6 Adresse (Präfix incl.Subnetzanteil). Die hintere Hälfte (64 Bit) nennt sich Interface ID und steht für das Endgerät.

Und damit kommen wir zum ersten Problem. Ich mache die selbe Abfrage wie eben einen Tag später und erhalte:

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.167  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::7755:bf46:529:6c60  prefixlen 64  scopeid 0x20<link>
        inet6 2001:a61:357f:2801:9e3b:68db:5992:3e4a  prefixlen 64  scopeid 0x0<global>
        inet6 fd00::443c:43c5:6e21:e64e  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:aa:f7:71  txqueuelen 1000  (Ethernet)
        RX packets 15136  bytes 1499650 (1.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3332  bytes 488108 (476.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Man sieht es deutlicher, wenn ich die beiden global unicast Adressen direkt untereinander schreibe:

inet6 2001:a61:3555:d001:caf0:a067:58b1:4753  prefixlen 64  scopeid 0x0<global>
inet6 2001:a61:357f:2801:9e3b:68db:5992:3e4a  prefixlen 64  scopeid 0x0<global>

Während die erste und dritte IPv6 Adresse gleich geblieben sind, hat sich die 2. also die globale Unicast-Adresse verändert und zwar nicht nur im Präfix (erste Hälfte der Adresse) sondern ebenfalls in der Interface ID. Was ist passiert?

Bei IPv4 wissen wir, dass der Router täglich vom Provider eine neue IP-Adresse zugeordnet bekommt, während die internen Adressen unverändert bleiben. Zwischen interner und externer IPv4-Welt passiert NAT, die Network Address Translation. Die gibt es bei IPv6 aber nicht, weil auch interne Adressen global sein können. Trotzdem bekommt der Router täglich einen neuen IPv6 Präfix, den er an alle internen Geräte weitergibt. Aus Präfix

2001:a61:3555:d001

wird

2001:a61:357f:2801

Man sieht, dass der Anfang gleich bleibt und sich nur die hinteren Stellen verändern, was durchaus zu erwarten ist, da alle Adressen aus dem Pool des selben Providers stammen. Aber warum ändert sich auch die Interface ID, also die zweite Hälfte der IPv6 Adresse, die für das Gerät steht? Die Antwort lautet:

Privacy Extensions

Diese Datenschutz-Erweiterungen wurden eingeführt, um einem Problem zu begegnen, das es bei IPv4 so deutlich nicht gibt. Wenn die Internet-Adresse meines Computers in meinem internen Netz (bis auf den wechselnden Präfix) immer global gleich bleibt, dann ist mein Rechner auch im Internet identifizierbar und anhand der IPv6-Adrresse trackbar. Das ist im Sinne des Datenschutzes natürlich nicht erwünscht, deshalb sorgen die Privacy Extensions dafür, dass die Interface ID nicht mehr von der MAC-Adresse des Interfaces abgeleitet wird und dass sie sich darüber hinaus regelmäßig ändert. Damit ist im Internet kein Zusammenhang meiner IP-Adresse von gestern mit der von heute ableitbar.

Was für einen Client einen Zugewinn an Sicherheit darstellt, ist für einen Server allerdings kontraproduktiv. Der soll ja immer unter der selben Adresse erreichbar sein. Das gilt auch für unseren VPN-Server, die Freigabe am Router, damit er aus dem Internet erreichbar ist, bezieht sich immer auf die selbe Interface ID. Deshalb können wir die Privacy Extension an unserem Raspberry Pi in diesem Fall nicht gebrauchen und werden dieses Feature abschalten.

Privacy Extensions abschalten

Dazu bearbeiten wir am Raspberry Pi eine Konfigurationsdatei mit:

sudo nano /etc/dhcpcd.conf

und kommentieren dort die Zeile slaac private aus. (ein # davor schreiben!) Danach ist ein Reboot des Raspberry Pi fällig. Bei der erneuten Kontaktaufnahme mit dem Raspberry Pi per SSH werden wir dann eine Warnung erhalten, weil die IP-Adresse nicht mehr zum gespeicherten Schlüssel passt:

ssh pi@raspi167
Warning: the ECDSA host key for 'raspi167' differs from the key for the IP address 'fd00::ba27:ebff:feaa:f771'
Offending key for IP in /home/helmut/.ssh/known_hosts:22
Matching host key in /home/helmut/.ssh/known_hosts:291
Are you sure you want to continue connecting (yes/no)? yes

Die Warnung bestätigen wir mit yes und schauen uns danach die IP-Adressen mit ifconfig an:

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.167  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fd00::ba27:ebff:feaa:f771  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::ba27:ebff:feaa:f771  prefixlen 64  scopeid 0x20<link>
        inet6 2001:a61:357f:2801:ba27:ebff:feaa:f771  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:aa:f7:71  txqueuelen 1000  (Ethernet)
        RX packets 107  bytes 12566 (12.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 100  bytes 18343 (17.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Die IPv6 Adressen leiten sich nun von der MAC-Adresse (ether) ab und die Interface ID wird immer gleich bleiben.

Dynamisches DNS für IPv6 einrichten

Dynamischem DNS habe ich mich ausführlich in einem der vorhergegangenen Artikel gewidmet. Deshalb hier nur kurz:
Privatkunden erhalten von Ihren Internet Service Providern in der Regel keinen festen IPv6-Präfix, sondern einen, der sich regelmäßig (täglich) ändert. Wenn wir nun vom Smartphone aus einen VPN-Tunnel ins heimische Netz aufbauen wollen, müssen wir am Smartphone Kenntnis über die gerade aktuelle IPv6 Adresse des VPN-Servers haben. Deshalb bedienen wir uns der Hilfe eines DDNS-Dienstleisters im Internet, der uns jederzeit Auskunft über die aktuell gültige IPv6 Adresse geben kann.

Account bei einem DDNS-Dienstleister einrichten

Wichtig ist, dass der DDNS-Anbieter auch mit IPv6 umgehen kann, was nicht selbstverständlich ist. DDNS-Services können beispielsweise sein:

• MyFRITZ! für alle Nutzer einer Fritz!Box. Wer über eine Fritz!Box mit dem Internet verbunden ist, der hat einen DDNS-Dienst quasi schon mit dabei und der kann auch IPv6. In der Konfigurationsoberfläche der Fritz!Box kann ein My!FRITZ-Konto eingerichtet werden mit Mailadresse, Nutzernamen und Passwort um damit die Fritz!Box aus dem Internet administrieren zu können. Danach können wir an der Fritz!Box unter Internet – Freigaben – MyFRITZ!-Freigaben eine neue Freigabe für unseren Raspberry Pi und Port 1194 anlegen. Als Schema können wir http:// auswählen, auch wenn das nicht stimmt – bei dem ermittelten DNS-Namen, lassen wir das führende http:// dann gedanklich einfach wieder weg. Die Fritz!Box richtet gleichzeitig auch eine IPv6-Freigabe ein, an der wir eine Korrektur vornehmen müssen. Unter Internet – Freigaben – IPv6 ergänzen wir für unseren VPN-Server die vorhandene TCP-Freigabe um einen zusätzlichen Eintrag für UDP und den Port 1194. (Nach Rückmeldung eines Lesers dieses Blogs im Januar 2021, legt MyFRITZ! immer auch einen IPv4 DDNS Eintrag an, der sich nicht separat löschen lässt. Damit ist MyFRITZ zwar sehr gut für Dual-Stack geeignet, für reines IPv6 aber eher weniger.)
• Wer eigene Webseiten bei einem entsprechenden Provider hosten lässt, der kann dort mal nachsehen, ob nicht etwa ein DDNS-Dienst mit zum Dienstleistungsumfang gehört. Wenn ja und wenn der Dienst auch IPv6 beherrscht, dann hat diese Variante die Vorteile, dass es nichts zusätzlich kostet, dass wir eine Subdomäne unserer eigenen Domäne nutzen können und dass keine regelmäßigen Aktivierungen nötig sind. All-Inkl kann das zum Beispiel.
• Für diejenigen, die keinen der beiden vorgenannten Varianten nutzen können oder wollen, finden sich zahlreiche Anbieter im Internet. Einfach mal googeln nach „DDNS IPv6 Anbieter„. Im Internet gibt es auch entsprechende Vergleichslisten. Die einzelnen Anbieter unterscheiden sich in folgenden Punkten: Manche sind kostenpflichtig, andere fordern statt dessen, dass man sich in regelmäßigen Abständen online in seinem DDNS Account einloggen muss. In jedem Fall muss der Anbieter IPv6 verstehen.

Allen dynamischen DNS Services ist gemein, dass man als Nutzer dort eine Subdomäne registriert – manchmal kann man dabei sogar zwischen verschiedenen Hauptdomänen wählen. Der eigene Internet Router oder der VPN-Server selbst meldet dann bei jedem Wechsel die aktuelle IP-Adresse an den Dienst und wir können diese jederzeit unter dem Namen der Subdomäne abfragen.

Ich verwende nachfolgend die dritte der oben aufgeführten Varianten und nehme deSEC beispielhaft als DDNS-Dienst. deSEC beherrscht IPv6, ist kostenlos und hat mir persönlich gut gefallen. Die Anmeldung erfolgt auf https://desec.io/#!/de/product/dyndns, dort geben wir eine Email-Adresse ein und unseren Wunschnamen für eine Subdomäne. Darauf hin bekommen wir ein Bestätigungs-Mail mit folgenden Informationen, die wir gleich noch brauchen werden:

url:      https://update.dedyn.io/
username: jsonp.dedyn.io
password: ykie2S7rLUF8nRYWXP34hhu9

Die Url bezeichnet den Internetnamen des DDNS-Servers und dazu erhalten wir einen Nutzernamen, der gleichzeitig auch der neue Domänenname unseres VPN-Servers ist, und ein Passwort. Der DDNS-Dienst ist nun bereit um Updates der IP-Adresse zu empfangen. Wenn das später einmal funktioniert, können wir jederzeit einen Status abrufen (die Adresse dazu wird ebenfalls im Bestätigungsmail mitgeteilt). Das sieht dann aus wie im Bild rechts.

IPv6 Adresse bei Änderungen an DDNS melden

Jetzt müssen wir nur noch die IPv6 Adresse des VPN-Servers an den DDNS-Dienst bei deSEC melden und zwar immer dann, wenn sie sich ändert. Bei IPv4 haben wir gesehen, dass der Internetrouter (Fritz!Box) den DDNS-Dienst beschickt, aber da ist es um die IP-Adresse des Routers selbst gegangen. Bei IPv6 müssen wir die Adresse des VPN-Servers melden – der Internetrouter scheidet hier also aus (es sei denn, wir wählen die Variante mit MyFRITZ!). Wenn der Internetrouter das nicht kann, dann liegt es nahe, den Raspberry Pi selbst dazu zu bewegen, seine IPv6 Adresse dem DDNS mitzuteilen. Und ein Raspberry Pi kann das natürlich. Das Tool der Wahl heißt ddclient und das müssen wir erst einmal installieren mit:

sudo apt install ddclient

Die Installation startet auch gleich einige Installationsabfragen. Ich verzichte hier auf einzelne Screenshots und beschreibe nur die jeweils nötigen Eingaben.

• Anbieter des dynamischen DNS-Dienstes: anderer
• Dynamischer DNS-Server: update.dedyn.io
• Protokoll für die dynamische DNS-Aktualisierung: dyndns2
• Benutzername für den dynamischen DNS-Dienst: <eigene Subdomäne>.dedyn.io (im Beispiel oben wäre das jsonp.dedyn.io)
• Passwort für den dynamischen DNS-Dienst: <PW aus der Bestätigungsmail>
• Passwortwiederholung: <dito>
• Netzwerk-Schnittstelle für den dynamischen DNS-Dienst: wlan0 (bzw eth0, falls der RasPi am Kabel hängt)
• Vollqualifizierte DynDNS-Domainnamen: <eigene Subdomäne>.dedyn.io (im Beispiel oben wäre das jsonp.dedyn.io)

Nach der Installation überprüfen wir zwei Konfigurationsdateien:

sudo cat /etc/ddclient.conf
# Configuration file for ddclient generated by debconf
#
# /etc/ddclient.conf

protocol=dyndns2
usev6=if, if=wlan0
if-skip=Scope:Link
ssl=yes
server=update6.dedyn.io
login=jsonp.dedyn.io
password='ykie2S7rLUF8nRYWXP34hhu9'
jsonp.dedyn.io

Wichtig für IPv6 sind die Einträge usev6=if, if-skip=Scope:Link und server=update6.dedyn.io. Falls die nicht vorhanden sind, dann bitte ergänzen mit sudo nano /etc/ddclient.conf!

sudo cat /etc/default/ddclient
# Configuration for ddclient scripts 
# generated from debconf on Sa 16. Mär 19:34:10 CET 2019
#
# /etc/default/ddclient

# Set to "true" if ddclient should be run every time DHCP client ('dhclient'
# from package isc-dhcp-client) updates the systems IP address.
run_dhclient="false"

# Set to "true" if ddclient should be run every time a new ppp connection is 
# established. This might be useful, if you are using dial-on-demand.
run_ipup="false"

# Set to "true" if ddclient should run in daemon mode
# If this is changed to true, run_ipup and run_dhclient must be set to false.
run_daemon="true"

# Set the time interval between the updates of the dynamic DNS name in seconds.
# This option only takes effect if the ddclient runs in daemon mode.
daemon_interval="300"

In dieser Datei sollte alles stimmen, beim letzten Eintrag könnte man das Intervall zur Prüfung der eigenen IPv6 Adresse ändern. Gegen 300 Sekunden ist aber nichts einzuwenden. Als nächstes probieren wir ddclient von Hand aus mit:

sudo ddclient -force
SUCCESS:  updating jsonp.dedyn.io: good: IP address set to 2001:a61:359e:c01:ba27:ebff:feaa:f771

Im Falle von SUCCESS hat ddclient erfolgreich mit dem DDNS-Server kommunizieren können, dann sollte eine Check-Abfrage bei deSEC ein ähnliches Bid ergeben, wie weiter oben bereits dargestellt. Wenn kein SUCCESS kommt, dann stimmt die Konfiguration von ddclient nicht, oder der Raspberry Pi hat keinen Internetzugang. Als letztes prüfen wir, ob ddclient am Raspberry Pi als Daemon (Serverdienst) läuft mit ps ax. Irgendwo in der Prozessliste muss ddclient - sleeping for x seconds auftauchen, falls nicht, würde ich zuerst einen Reboot probieren.

Freigabe am Router einrichten

Wenn wir mit dem Smartphone aus dem Internet auf den VPN-Server im internen Heimnetz zugreifen wollen, dann genügt es nicht, den Namen unseres Raspberry Pi zu kennen oder abgeleitet davon dessen IPv6 Adresse. Damit das möglich wird, müssen wir am Internetrouter eine Freigabe einrichten. Die kann bei einer Fritz!Box wie folgt aussehen:

Die Eingabemaske erreichen wir auf einer Fritz!Box unter Internet – Freigaben – IPv6- Neues Gerät. Dort wählen wir den Raspberry Pi aus, verwenden UDP und Port 1194. Der Router wird dann künftig aus dem Internet ankommende Pakete für den Raspberry Pi auf Port 1194 zu unserem VPN-Server durchlassen.

Vorarbeiten abgeschlossen

Dieser Artikel war recht umfangreich. Wir haben den Raspberry Pi grundinstalliert, die Privacy Extensions abgeschaltet, dynamisches DNS für IPv6 eingerichtet und dafür einen Uploader installiert und schließlich am Router eine Freigabe für den VPN-Server eingerichtet. Damit sind alle Vorarbeiten erledigt und wir können im nächsten Artikel die VPN Server Software auf dem Raspberry Pi installieren.

Zu kompliziert? Zu trockene Materie? Zu viel schwierige Netzwerk-Technik? Dann hier vielleicht mal kurz unterbrechen und vorab einen Blick in Artikel 11 werfen! Dort gibts zur Wiederholung und Vertiefung ein paar übersichtliche Netzwerkdiagramme.

Weitere Artikel in dieser Kategorie:

• Raspberry Pi VPN – Teil 1: Smartphone Sicherheit
• Raspberry Pi VPN – Teil 2: Konzept eines Virtual Private Network
• Raspberry Pi VPN – Teil 3: IPv4 versus IPv6
• Raspberry Pi VPN – Teil 4: VPN-Server unter IPv4
• Raspberry Pi VPN – Teil 6: VPN-Server unter IPv6
• Raspberry Pi VPN – Teil 7: VPN Client fürs Smartphone
• Raspberry Pi VPN – Teil 8: Dual Stack VPN Tunnel
• Raspberry Pi VPN – Teil 9: Installation Pi-Hole
• Raspberry Pi VPN – Teil 10: Datenanalyse mit Wireshark
• Raspberry Pi VPN – Teil 11: Netzwerkdiagramme
• Raspberry Pi VPN – Teil 12: Tipps & Tricks
• Raspberry Pi VPN – Teil 13: IPv4 VPN mit (trotz) DS-Lite