Proxmox mit tunnelbroker.net IPv6 für die VM's

Veröffentlicht: / Letztes Update:

Gerade bei günstigen Servern bekommt man zu einem dedizierten Server teilweise nur eine IPv6 Adresse mit der Netzmaske /128. Dies ist z. B. bei der Kimsufi Reihe von OVH Cloud der Fall.

Wir haben bereits auf diesem Blog zusammen zusätzliche IPv4 Adressen von noez.de über einen GRE Tunnel hinzugefügt, damit wir diese für unsere virtuellen Maschinen nutzen können.

In dieser Anleitung nutzen wir IPv6 Adressen von tunnelbroker.net, da wir dort kostenlos ein /64er Netz zugeteilt bekommen und uns sogar noch ein zusätzliches /48er Netz auf unseren Tunnel routen lassen könnten. Die Einrichtung von reverse DNS ist hier ein wenig aufwendiger, sodass wir dies in einer eigenen Anleitung abarbeiten werden.

Da wir hier einen 6in4 Tunnel aufbauen und diesesn direkt als Netzwerkinterface auf unserem Host einrichten, benötigt Euer Server zwingend eine IPv4 Adresse, die theoretisch auch pingbar ist. Mit einem Server ohne IPv4 Adresse funktioniert diese Anleitung nicht! Auch via IP-Tunnel bezogene IPv4 Adressen können hier nicht für den 6in4 Tunnel als Gateway genutzt werden! Ein weiterer Punkt ist, dass Ihr die IPv6 Adresse Eures Servers nach der Einrichtung nicht mehr nutzen könnt, da der gesamte IPv6 Traffic durch den 6in4 Tunnel geleitet wird.

Tunnel auf tunnelbroker.net erstellen

Jetzt erstellen wir uns einen IP Tunnel auf tunnelbroker.net.

Als erstes müssen wir uns auf https://tunnelbroker.net einloggen.
Wenn Ihr noch nicht registriert seit, könnt Ihr Euch dort kostenlos registrieren.

Nach dem Login klickt Ihr im linken Menü auf "Create Regular Tunnel":

Nun gelangt Ihr zu einer Auswahlseite bei der Ihr in das Feld "IPv4 Endpoint (Your side):" die öffentliche IPv4 Adresse Eures Servers eingeben müsst. Eure IP wird einmal kurz via Ping kontaktiert, ob diese auch erreichbar ist. Wenn alles O.K. ist, erscheint eine grün hinterlegte Info und wir können weiter machen.

Darunter findet Ihr eine Auswahl an verfügbaren Tunnelservern. Für Deutschland wären die Server in Berlin oder Frankfurt am Besten. Jedoch solltet Ihr den Standort anhand des Serverstandortes Eures Servers wählen.


Danach klickt Ihr auf den Button "Create Tunnel".

Nun gelangt Ihr direkt auf die Übersichtsseite Eure 6in4 Tunnels:

Eine fast fertige Konfiguration für Debian gibt es dort auch:

Zurück auf unseren Server

Als erstes öffnen wir wieder die Datei "/etc/network/interfaces:" im Editor:

Wenn Ihr bereits den noez.de GRE Tunnel eingerichtet habt, müsst Ihr nur die blau markierten Einträge hinzufügen.

sudo nano /etc/network/interfaces

Diese Datei passt Ihr dann wie folgt an:
Die farbig markierten Parameter müsst Ihr an Euren Server anpassen!
Die öffentlichen IP-Adressen sind von mir mit x anonymisiert.

auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet static
	address x.x.x.x/xx
	gateway x.x.x.x
	post-up sysctl -w net.ipv4.ip_forward=1
	post-up sysctl -w net.ipv6.conf.all.forwarding=1
	post-up sysctl -w net.ipv6.conf.all.proxy_ndp=1
	post-up iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -o enp3s0 -j MASQUERADE
	post-down iptables -t nat -D POSTROUTING -s '10.0.0.0/24' -o enp3s0 -j MASQUERADE
	post-up iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
	post-down iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

iface enp3s0 inet6 static
	address 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/xx
	gateway 2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

auto vmbr0
iface vmbr0 inet static
	address 10.0.0.0/24
	bridge-ports none
	bridge-stp off
	bridge-fd 0
	mtu 1476
	post-up /root/noez_gre_up.sh
	pre-down /root/noez_gre_down.sh

auto vmbr1
iface vmbr1 inet6 static
	address 2001:xxxx:xxxx::ffff/64
	address 10.0.0.0/24
	bridge-ports none
	bridge-stp off
	bridge-fd 0
	mtu 1456
	pre-up brctl addbr vmbr0
	post-down brctl delbr vmbr0

iface he-ipv6 inet6 v4tunnel
    address 2001:470:xxxx.xxxx::2
    netmask 64
	mode sit
    endpoint xx.xx.xx.xx
    local xx.xx.xx.xx
    ttl 255
    gateway 2001:470:xxxx.xxxx::1
	post-up ip -6 neigh add proxy 2001:470:xxxx:xxxx::1 dev he-ipv6
	post-down ip -6 neigh del proxy 2001:470:xxxx:xxxx::1 dev he-ipv6
	post-up ip -6 neigh add proxy 2001:470:xxxx:xxxx::2 dev he-ipv6
	post-down ip -6 neigh del proxy 2001:470:xxxx:xxxx::2 dev he-ipv6
	post-up ip -6 neigh add proxy 2001:470:xxxx:xxxx::3 dev he-ipv6
	post-down ip -6 neigh del proxy 2001:470:xxxx:xxxx::3 dev he-ipv6

Wenn Ihr keinen GRE Tunnel von noez.de nutzt, lasst in der Config bitte die "mtu 1476", ";post-up /root/noez_gre_up.sh"- und "pre-down /root/noez_gre_down.sh"-Anweisungen weg.

Erklärung:

Der Befehl sysctl -w net.ipv6.conf.all.forwarding=1 bewirkt, dass der Linux Kernel IPv6 Pakete zwischen den Interfaces weiterleitet.
Der Befehl sysctl -w net.ipv6.conf.all.proxy_ndp=1 bewirkt, dass der Linux Kernel auch ndp Pakete für das IPv6 Routing weiterleitet, da wir ja IPv6 Adressen routen möchten. und unser Server als IPv6 Proxy dienen soll.

Der vmbr1 geben wir zusätzlich nun eine IPv6 Adresse aus dem im Control Panel genannten "Routed /64".

Den Tunnel haben wir dieses mal direkt in die Netzwerkconfig geschrieben. Wichtig ist jedoch, dass Ihr den Code, welchen Ihr aus dem Control Panel von tunnelbroker.net kopiert, um die Zeile "mode sit" erweitern solltet. Ich habe die Erfahrung gemacht, dass es stabiler läuft, wenn man es noch explizit festlegt, obwohl Debian das selbst erkennt.

Mit dem Befehl "ip -6 neigh add proxy" sagen wir, dass unser Server als Neighbor Discovery Proxy agieren soll. So kommen wir dann auch ohne größere Konfiguration durch die Bridge. Der Nachteil ist jedoch wie auch bei IPv4, dass wir diese Anweisung für jede IPv6 Adresse einzeln angeben müssen.

Fast vergessen: Da wir mit verschiedenen IP Protokollen arbeiten, sind unterschiedliche MTU's bei den Bridges anzugeben, wenn wir die Daten daraus durch einen Tunnel schieben!

Die Verwendung der IPv6 in den VM's und LXC's:

Die Verwendung an den Interfaces der virtuellen Maschinen und Linux Containern ist dabei genauso einfach, wie bei IPv4.
Auch gebt Ihr die IPv6 Adresse als Gateway an, welche Ihr der vmbr1 zugewiesen habt.

Ein kurzer Test auf der Konsole des virtuellen Servers zeigt, dass nun alles funktioniert: