In Rahmen dieser Artikelserie habe ich mich ausgiebig mit der Entscheidungsfindung beschäftigt, ob ein VPN-Tunnel auf IPv4 oder IPv6 aufgebaut werden soll. Für beide Alternativen habe ich auch die Vorarbeiten (Dynamisches DNS und Routerfreigabe) und die Installation von PiVPN erklärt. Offen bleibt die Frage – wenn man denn am heimischen Router sowohl IPv4 als auch IPv6 zur Verfügung hat – ob man nicht auch den VPN-Tunnel dual stack – also auf beiden Protokollen – aufsetzen kann und sollte. Darum soll es in diesem Artikel gehen, ein VPN-Tunnel, der je nach Gegebenheiten die eine oder die andere IP-Version nutzen kann. All diejenigen, die keinen Dual Stack Internet Anschluss haben, können diesen Artikel getrost überblättern.
VPN über IPv4 und IPv6 – geht das überhaupt?
Diese Frage hatte ich mir auch gestellt, nachdem darüber im Internet nicht allzu viele Informationen zu finden sind. Aber es geht und sogar sehr gut. Natürlich nicht gleichzeitig, wenn beide Protokolle zur Verfügung stehen, dann entscheidet sich der Client für eins von beiden, wenn es client-seitig nur IPv4 gibt dann gibt es eh keine Alternative. Aber bei vollem Dual Stack auf beiden Seiten kann es durchaus sein, dass im Moment IPv4 aktiv ist und nach einer Trennung und anschließendem Reconnect dann IPv6.
Wohlgemerkt, wenn ich hier über IPv4 und IPv6 spreche, dann ist immer das IP-Protokoll gemeint, auf dem der VPN-Tunnel aufsetzt. Durch den Tunnel selbst wird immer nur IPv4 übertragen. Da darf man sich nicht durcheinander bringen lassen.
Braucht man das?
Klare Antwort: Nein!
Alle WLANs und alle Mobilfunknetze bieten heute IPv4 und das wird auch noch viele Jahre so bleiben. Wer also in der glücklichen Lage ist, an seinem heimischen Internetzugang richtiges IPv4 zur Verfügung zu haben (und kein DS-Lite), der kann sein VPN immer mit IPv4 betreiben. Den Tunnel auf beide Protokoll-Stacks zu setzen ist also eher eine akademische Übung, die keinen wirklichen Mehrwert bringt.
Dual Stack VPN konfigurieren
Ausgangspunkt für einen Dual Stack VPN Tunnel ist eine vollständige und funktionierende IPv6 Konfiguration. Darauf werden wir aufsetzen und so lange die nicht funktioniert, braucht man mit den folgenden Schritten gar nicht erst zu beginnen.
Änderungen am Server
Keine.
Das mag überraschen, aber der Server akzeptiert auch Tunnelanfragen auf IPv4, selbst wenn er nur für IPv6 konfiguriert ist.
Änderungen am Client
Eine.
Bei OpenVPN für Android ist nichts zu tun, selbst wenn in der Konfigurationsdatei UDP6 steht, wird es der Client eigenständig auch per UDP also IPv4 probieren.
Bei OpenVPN Connect und beim VPN Client Pro von colucci.web.it gibt es jeweils eine Einstellmöglichkeit, ob UDP4, UDP6 oder beides verwendet werden soll.
Änderungen an der Routerfreigabe
Nachdem die Grundlage unserer Änderungen eine IPv6 Konfiguration ist, besitzen wir am Internet Router bereits eine IPv6 Freigabe. Ergänzen müssen wir nur noch eine Port-Weiterleitung für IPv4, per NAT (Network Address Translation). Bei einer Fritz!Box findet man die Einstellung unter Internet – Freigaben – Portfreigaben.
Änderungen am dynamischen DNS
Das ist der aufwändigste Punkt, den ich mir bis zum Schluss aufgehoben habe.
Die Herausforderung besteht darin, dem DDNS-Server nicht nur eine, sondern zwei IP-Adressen zu übermitteln. Meine erste Idee war die, IPv6 weiterhin über ddclient laufen zu lassen und zusätzlich an der Fritz!Box einen DDNS-Eintrag für IPv4 zu machen. Das funktioniert zumindest bei meinem DDNS-Anbieter deSEC leider nicht. Ein Update überschreibt dabei den vorhergehenden, so dass immer nur einer vorhanden ist.
Aber hier zwei Lösungen, mit denen es funktioniert:
Ddclient mit deSEC
Ddclient beherrscht zwar sowohl IPv4 als auch IPv6, ist aber nicht in der Lage beide Adressen gleichzeitig an einen DDNS-Server hochzuladen. Aber man kann sich behelfen. In folgender Konfigurationsdatei wird die externe IPv4 Adresse per Web über einen checkipv4 Dienst von deSEC ermittelt und diese dann an einen speziellen IPv6-Server übermittelt, der sich die IPv6 Adresse merkt und als DNS-Eintrag hinterlegt. Somit hat der DDNS-Server beide Adressen.
protocol=dyndns2
use=web
web=https://checkipv4.dedyn.io/
ssl=yes
server=update6.dedyn.io
login=jsonp.dedyn.io
password='ykie2S7rLUF8nRYWXP8uUh3n5l6'
jsonp.dedyn.io
MyFRITZ!
MyFRITZ! steht nur Nutzern einer Fritz!Box zur Verfügung, ist für die aber kostenlos. Es muss ein MyFRITZ! Konto angelegt werden, dann kann MyFRITZ! als DDNS-Dienst für unseren Raspberry Pi verwendet werden, in dem wir wie im Bild unten eine MyFRITZ!-Freigabe einrichten. Die meldet sowohl die IPv4 als auch die IPv6 Adresse an den MyFRITZ! DDNS-Server und richtet auch gleich die beiden nötigen Freigaben ein. Bei der Anlage wird die Eingabe eines Schemas verlangt, dort kann man zum Beispiel wie im Bild FTP auswählen. Bei der erzeugten Domäne lassen wir das Schema und den Port aber dann wieder weg, so dass sie im Beispiel raspi167.p0wrksbfopi2gppr.myfritz.net
lautet.
Noch ein Hinweis: Die Freigaben werden automatisch mit Protokoll TCP angelegt, wir müssen später an der Fritz!Box noch zusätzliche Freigaben für UDP von Hand ergänzen.
Fazit
Dual Stack für den VPN-Tunnel braucht man eigentlich nicht. Wer einen Dual Stack Internet Anschluss hat, der ist mit einem Tunnel gut bedient, der auf IPv4 aufsetzt. Und wer am heimischen Router nur IPv6 zur Verfügung hat, für den ist Dual Stack VPN eh nicht möglich. Wer aber im ersten Fall gerne ein bisschen experimentiert, der kann sich mit dieser Anleitung leicht einen VPN-Tunnel auf Basis von IPv4 und IPv6 aufbauen. Vielleicht werden wir sowas in vielen Jahren einmal brauchen können, wenn auf der Clientseite nicht mehr in jedem Fall IPv4 zur Verfügung stehen wird.
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 5: Vorarbeiten für ein VPN unter IPv6
- Raspberry Pi VPN – Teil 6: VPN-Server unter IPv6
- Raspberry Pi VPN – Teil 7: VPN Client fürs Smartphone
- 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
Hallo Herr Karger,
ich möchte hier mal ein ganz großes Lob aussprechen für Ihre wirklich hervorragende Dokumentation bezüglich VPN und DSLite:
Meine Glückwunsch.
Mit freundlichen Grüßen.
Stefan Möller
Vielen Dank.
Hallo,
danke für die tolle Anleitung und die guten Hintergrundinformationen.
Ich bin darauf gestoßen, weil mein Raspi auch VPN machen soll. Und PiVPN macht die Sache wesentlich leichter.
Ziel ist zusammengefasst:
-wireguard
-dual stack vpn
Manche Clients haben mal ipv4 only, dann wieder dualstack. Und ipv6-Leakage möchte ich vermeiden.
Leider wird hier auf open vpn gesetzt. Die mit wireguard erzeugte Konfiguration ist ja deutlich anders.
Hast Du auch für wireguard einen Tip, wie man das automatisch erzeugte ipv4-VPN zum Dualstack aufbohrt? Ansonsten muss ich wohl aus der ct 19.15 nativ aufbauen – das ist ja ein ganz anderer Aufwand.
Danke!
Ich selber kenne Wireguard nicht, aber mein Gastautor Stefan setzt in seinem Artikel auf Wireguard. Vielleicht hilft Dir das weiter.
Hallo Helmut,
zunächst vielen dank an die tolle Beitragsserie! Der Punkt „Ddclient mit deSEC“ ist mir noch etwas unklar.
Füge ich diesen Part
protocol=dyndns2
use=web
web=https://checkipv4.dedyn.io/
ssl=yes
server=update6.dedyn.io
login=jsonp.dedyn.io
password=’ykie2S7rLUF8nRYWXP8uUh3n5l6′
jsonp.dedyn.io
in die bereits vorhandene Konfigurationsdatei mit hinzu oder überschreibe ich den vorhandenen Part mit IPv6 (aus Teil 5)?
Danke!
In Teil 5 ist die ddclient.conf Datei für IPv6 zu sehen, hier in Teil 8 die für dualstack. Überschreiben ist also richtig.