OpenVPN ohne Altlasten



Vorwort


Mit den Auswirkungen der IPv4-Adressknappheit haben immer mehr Internetnutzer zu kämpfen.
Dies äußert u.a. in der größer werdenden Verbreitung von CGNAT, das sich auch hinter wohlklingenden Bezeichnungen wie Dualstack-lite (DS-lite) versteckt. Adressüberlappungen und der Verlust der direkten Adressierbarkeit sind die Folgen.

Glücklicherweise bieten fast alle InternetServiceProvider, die ihren Kunden keine eigene IPv4-Adresse mehr bieten können, vollständige IPv6-Konnektivität.

Damit kann man etwas anfangen.

IPv4 tunneln kann ja jeder, selbst AVM (FRITZ!OS >=7.50) nach langer langer Wartezeit.

OpenVPN erlaubt seit Version 2.5.0 den kompletten Verzicht auf IPv4, außer bei Verwendung von Data Channel Offload (DCO).


Wozu also der Aufwand?

Es gibt ja schließlich direkte Konnektivität via IPv6. Myfritz als DNS-Service von AVM bietet hier hervorragende Dienste.

Das Problem

Manchmal möchte man seine IP-Adresse von daheim haben, z.B. um die Telefoniefunktion der Fritzbox von unterwegs aus nutzen zu können.
Das geht zwar derzeit nicht mit der Fon-App von AVM (da ist noch eine Abhängigkeit von IPv4 drin). Aber Linphone beispielsweise spricht IPv6 mit der Fritzbox.


Die Idee zur Lösung


OpenVPN: Transportnetz via IPv6, Payload IPv6


Umsetzung


Hardware: Raspberry PI (im Grunde geht auch jeder andere Rechner) der Raspberry Pi bietet sich an, weil er leise, stromsparend und relativ günstig ist.

Software: Linux (hier openSUSE leap, debian sollte ebenso den Zweck erfüllen)

openvpn ist sehr komplexe Software. Ein meiner Meinung nach sehr aufwendiger Teil ist die Erstellung entsprechender Verschlüsselungszertifikate. Dazu verweise ich nur auf die mitgelieferte Dokumentation.
Die einfache Variante mit dem "static.key" ist zwar sehr verlockend, hat aber letztendlich zu viele Einschränkungen.


Der VPN-Service läuft also auf dem Raspberry Pi, ganz normal via LAN-Kabel angeschlossen.
Der Raspberry Pi hat eine IPv6-Adresse, die auf der Fritzbox freigegeben(Firewall) ist und außerdem via dynv6 oder myfritz einen stabilen Servernamen hat. (andere Router und DDNS-Dienste sind hier auch denkbar)

Um statische Routeneinträge auf dem Router und den anderen Geräten zu vermeiden, setze ich auf  NDP-Proxy.

sysctl net.ipv6.conf.eth0.proxy_ndp=1



Da der Raspberry Pi ja nun Pakete zwischen tun0 und eth0 routen soll, ist noch folgende Einstellung notwendig:

sysctl net.ipv6.conf.all.forwarding=1


ip neigh add proxy 2001:db8:41a:7901::1:3 dev eth0
ip neigh add proxy 2001:db8:41a:7901::1:4 dev eth0
ip neigh add proxy 2001:db8:41a:7901::1:5 dev eth0

leider für jede IPv6-Adresse einzeln,
oder via diesem Shellaufruf einfach mal für alle setzen:

for i in $(seq 3 10) ; do ip neigh add proxy 2001:db8:41a:7901::1:$(printf %x $i) dev eth0; done


Für IPv6 kann man auch auf ein richtiges geroutetes Netz setzen (die Fritzbox unterstützt dhcpv6-pd). Das hätte den Vorteil, dass man auf die NDP-Proxies verzichten kann.

Im hier hinterlegten Skript habe ich mich für die Verwendung von NDP-Proxy entschieden. Wegen der dynamischen Präfixe muss das Skript nach jedem Wechsel neu aufgerufen werden.



Somit sieht die Serverkonfiguration (server.ovpn) so aus:

proto udp6
dev tun
tun-mtu 1500
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server-ipv6 2001:db8:41a:7901:0:0:1:1/112
push "redirect-gateway !ipv4 ipv6"
push "dhcp-option DNS fd00::dea6:32ff:feb7:f781"
keepalive 10 120
replay-window 4096
verb 3

Auf dem Client (client.ovpn) sieht das so aus:

client
dev tun
proto udp6
tun-mtu 1500
remote servername-hier-nicht-abschreiben 1194
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
verb 3


Mit diesen Einstellungen kann man nun die Konfigurationsoberfläche der Fritzbox unter http://fritz.box (oder http://[fd00::3631:c4ff:fef8:83a4] ) aufrufen, auch andere IPV6-Geräte im "Heimnetz" sind somit aus der Ferne trotz fehlender individueller Freigaben wieder erreichbar.
Auf dem Client sieht das dann so aus OpenVPN auf Android.

Für die MTU1500 ist es unter Umständen notwendig in der Fritzbox die Option "PPPoE MTU/MRU 1500 RFC4638-Support" zu aktivieren. Anderenfalls sollte man runter auf 1492 gehen.


Dieses veröffentlichte Selbstgespräch erhebt keinen Anspruch auf Fehlerfreiheit.

Thomas Schäfer

Letzte Überarbeitung Juni 2024

PS: damit das VPN auch geschmeidig nutzbar ist, sollte daheim dns64/nat64 aktiv sein: NAT64 mit dem_Raspberry_Pi