Verbinden von privaten IPv4 Netzen über reine IPv6 Internet-Anschlüsse

Bis dato gehört ich zu den Leuten, die sich vor dem Einsatz von IPv6 gedrückt haben. Der Grund war einfach und für jeden IT’ler nachvollziehbar: „Never touch a running system!“. Das änderte sich aber vor kurzem schlagartig. Aus verschiedenen Gründen habe ich 2 Standorte via VPN (bis dato via der in der Fritz!Box integrierten VPN-Lösung) verbunden.

Nun bot es sich bei dem einen Standort an, den Anschluss von derzeit DSL auf einen Internet-Kabel-Anschluss der Firma UnityMedia umzustellen. Gesagt, getan – der Anschluss wurde geschaltet, ich wollte die VPN-Verbindung wieder einrichten und wurde überrascht:

  • Problem 1:
    UM vergibt nur noch IPv6 Adressen und die IPv4 Adresse die man erhält, ist nur eine interne im UM Netz und entsprechend von außen nicht erreichbar.
  • Problem 2:
    Mein DDNS-Anbieter unterstützt derzeit noch kein IPv6 so dass die Fritz!Box auf UM Seite Ihre IPv6 nicht kommunizieren konnte. Leider gab es aber auf der Fritz!Box nur eine wenig aussagekräftige Meldung Account temporär deaktiviert was mich zuerst verwirrte.
  • Problem 3:
    Die in der Fritz!Box integrierte VPN-Lösung unterstützt derzeit keine IPv6-Verbindungen (hierzu hatte ich einen sehr freundlichen, kompetenten und bemühten Mailkontakt mit AVM).

Mögliche Lösungsansätze

Ansatz 1

Mein erster Gedanke, um Problem 1 bis 3 auf einen Schlag zu lösen war, bei UM anzurufen und eine IPv4 anzufragen: Kann man vergessen! Bei allen aktuellen Tarifen wird nur noch IPv6 geschaltet – gibt es viel zu lesen dazu und auch das viele ziemlich unzufrieden damit sind. Gerade wenn man z.B. einen WebServer betreiben möchte, kann man dies momentan nicht ohne weiteres tun wenn man auf IPv4 angewiesen ist. Damit beschäftigt sich auch die c’t Ausgabe 6/2013 ab Seite 178.

Problem ist meiner Meinung nach, dass durch die notwendige Umstellung auf IPv6 es früher oder später unweigerlich knirschen wird, von daher kann man hier niemanden irgendwelche Vorwürfe machen. Was man so hört, ist UM auch derzeit bemüht, eine Lösung zu schaffen, mit der man wieder von außen via IPv4 erreichbar sein kann ohne das UM wieder öffentliche IPv4 verteilen muss, bis wann das aber mal realisiert sein wird und auch durch die Router unterstützt wird, ist derzeit aber aus meiner Sicht nicht zu sagen.

Ansatz 2

Da ich auf der Seite mit dem UM Anschluss keinen Webserver oder ähnliches betreiben muss, ist es für mich momentan kein größerer Beinbruch, dass der DDNS-Service nicht funktioniert. Entsprechend ist es für mich auch kein Problem, von dieser Seite eine Verbindung nach außen aufzubauen zu einer Gegenstelle, die immer bekannt ist.

An diesem Punkt kommen wir dann zu dem Thema Sixx: Der Anbieter Sixx bietet kostenlos ein eigenes IPv6 Subnetz an, dass man sich auf einfache Art und Weise auf der Fritz!Box einrichten kann (Anleitungen zur Registrierung bei Sixx wie auch Einrichtung auf der Fritz!Box findet man im Netz zu genüge, ist auch nicht wirklich schwer). Entsprechend schnell kann man auf der Seite des DSL-Anschlusses, wo man i.d.R. nur eine IPv4 hat, eine zusätzliche IPv6 Adresse nachrüsten und sich so auf „Augenhöhe“ mit dem IPv6 Anschluss von UM bringen. Des Weiteren hat man eine feste IPv6, die sich auch nicht nach einer Neueinwahl ändert womit man dann auch das Kriterium erfüllt hat, eine feste „bekannte“ Gegenstelle zu haben, auch ohne funktionierendes IPv6.

Der nächste noch zu klärende Punkt wäre das Thema VPN: Da lässt sich nix dran rütteln, das IPv6 derzeit nicht unterstützt wird. Also muss man vorerst auf eine Alternative setzen, die in beiden Netzen auf einem eigenen Rechner läuft (vielleicht schaffte es ja auch jemand, es auf eine Fritz!Box zu „modden“).

In der Vergangenheit habe ich recht gute Erfahrungen mit OpenVPN gesammelt, da es sich recht einfach einrichten lies und entsprechend schnell zum Erfolg führte. Da ich auch alles verfolge was so in der IT-Welt aktuell ist, hatte ich auch entsprechend im Hinterkopf, dass OpenVPN bereits einen vollen IPv6 Support integriert hat. Entsprechend fiel meine Wahl auf OpenVPN als VPN-Lösung.

Und zuletzt dann noch: Auf beiden Seiten der Netze befinden sich Geräte, die noch nicht oder nur unvollständig IPv6 tauglich sind. Entsprechend sollten beide privaten IPv4 Netze sich erreichen können. Es gibt eine Lösung, die ich im folgenden dann auch erläutern werde.

Im nachfolgenden werde ich erklären, wie mein Lösungsansatz war.

Schritt 1: Anschluss auf DSL-Seite mit IPv6 nachrüsten

Um eine IPv6 zu erhalten, kann man sich wie bereits erwähnt beim Anbieter Sixx anmelden. Der Anbieter vergibt kostenlos kleine IPv6 Netze und außer etwas Geduld bis man den ganzen Anmeldeprozess durchlaufen hat, braucht man nicht mehr.

Anschließend trägt man seine Zugangsdaten auf der Fritz!Box auf der DSL-Seite ein und im besten Fall sieht man wenige Augenblicke später wenn man auf die Übersichtsseite geht, dass die Box sich mit der IPv6 registriert hat. Im einfachsten Fall kann man jetzt mit einem halbwegs aktuellen Betriebssystem was schon eine aktivierte IPv6 Unterstützung hat, z.B. www.hostblogger.de aufrufen und sollte dann auf der rechten Bildschirmseite sehen, das man die Seite via IPv6 aufruft. Ist dass der Fall, wäre dieses Kapitel schon erledigt!

Schritt 2: OpenVPN einrichten

Prinzipiell müssen zuerst auf beiden Seiten folgende Bedingungen erfüllt werden:

  1. Auf beiden Seiten muss OpenVPN in Version 2.3 oder neuer installiert sein, da nur diese IPv6 vollständig unterstützt
  2. Auf der DSL-Seite, auf welcher der VPN-Server laufen soll, muss eine IPv6 eingerichtet sein, die aus dem Sixx Netz stammt. Hierbei keine Angst: Es handelt sich zwar um eine öffentliche IP-Adresse, die Fritz!Box unterbindet aber generell alle Zugriffe aus dem Internet.

Die Grundinstallation von OpenVPN ist Betriebssystem bzw. Distributionsabhängig, sollte aber z.B. über ein zypper in openvpn, yum in openvpn oder apt-get install openvpn möglich sein. Zu beachten ist, dass ggf. die OpenVPN Version zu alt ist um man ein zusätzliches Repository für eine aktuellere Version hinzufügen muss.

Bzgl. IPv6 für den OpenVPN-Server: Man teilt diesem einfach eine Adresse aus dem Subnetz zu, die noch frei ist und ruft anschließend die Konfigurationsoberfläche auf. Dort geht man dann auf Internet -> Freigaben -> IPv6 und richtet dort ein neues Gerät ein.

Im einfachsten Fall, wenn man z.B. dem Server die :0:0:0:1234 am Ende zugewiesen hat, reicht es bei Interface-ID im letzten Feld die 1234 einzutragen. Anschließend sollte man auf jeden Fall die Option Firewall nur für bestimmte Protokolle öffnen auswählen und zumindest zu Testzwecken kann man auch mal den Ping aktivieren, um zu schauen ob die Gegenstellen überhaupt zueinander durchkommen.

Anschließend sollte man noch durch anklicken von Neue Freigabe noch einen Port 1194 mit dem TCP-Protokoll hinzufügen. Wenn das soweit alles eingerichtet ist, kann nun mit der Konfiguration von OpenVPN selbst begonnen werden. Vorab zu sagen wäre noch: Ich habe mich für eine sehr einfache OpenVPN-Konfiguration entschieden, da ich nur eine Punkt-zu-Punkt Verbindung benötige. Prinzipiell sollte man aber auch andere Konfigurationen verwenden können, sofern man den Syntax entsprechend an die IPv6 Direktiven anpasst.

OpenVPN Server

Folgende Konfiguration legt man in der Regel im Verzeichnis /etc/openvpn ab:

server.conf

dev tun
proto tcp6-server
ifconfig-ipv6 fd22::1 fd22::2
secret static.key
script-security 2
up /etc/openvpn/server.up
down /etc/openvpn/server.down
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
user nobody
group nogroup
daemon
verb 2

Beachten: Je nach System kann die Gruppe nogroup auch z.B. nobody heißen!

Anschließend müssen noch folgende Dateien in /etc/openvpn mit der Berechtigung 755 angelegt werden:

server.up

#!/bin/bash

# Set routing
sysctl -w net/ipv4/conf/eth0/proxy_arp=1
sysctl -w net/ipv4/ip_forward=1

# Set up interface
ip -6 link set $dev up
ip -6 addr add $ifconfig_ipv6_local dev $dev
ip -6 route add  $ifconfig_ipv6_remote/$ifconfig_ipv6_netbits dev $dev

exit 0

server.down

#!/bin/bash

# Remove interface
ip -6 addr del $ifconfig_ipv6_local/$ifconfig_ipv6_netbits dev $dev
ip -6 link set $dev down
ip -6 route del $ifconfig_ipv6_remote dev $dev

exit 0

Die beiden sysctl dienen dazu, dass der Rechner auf dem der OpenVPN-Server läuft, auch zwischen den Netzen routen kann. Werden die Zeilen nicht gesetzt. können sich nur die Gegenstellen selbst direkt erreichen später.

Wichtig ist dann noch, dass ein geheimer Static-Key generiert wird, der dann sowohl auf der Seite des OpenVPN-Servers als auch Client jeweils in /etc/openvpn befindet. Erstellt wird der Key mit:

openvpn --genkey --secret /etc/openvpn/static.key

Achtet darauf, dass die Leseberechtigungen für den Key nur soweit wie notwendig gesetzt sind. Wer im Besitz dieses Keys ist, kann eine Verbindung zu eurem OpenVPN-Server aufbauen!

OpenVPN Client

Folgende Konfiguration legt man in der Regel im Verzeichnis /etc/openvpn ab:

client.conf

remote xxxx:xxxx:xxxx:xxxx:0:0:0:1234 1194
dev tun
proto tcp6-client
ifconfig-ipv6 fd22::2 fd22::1
secret static.key
script-security 2
up /etc/openvpn/client.up
down /etc/openvpn/client.down
comp-lzo
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
user nobody
group nogroup
verb 2

Beachten: Je nach System kann die Gruppe nogroup auch z.B. nobody heißen! Zudem muss die Adresse xxxx:xxxx:xxxx:xxxx:0:0:0:1234 angepasst werden. Hier muss die Sixx IPv6-Adresse eingetragen werden, auf welcher der OpenVPN-Server läuft und die ihr in der Fritz!Box freigegeben habt.

Anschließend müssen noch folgende Dateien in /etc/openvpn mit der Berechtigung 755 angelegt werden:

client.up

#!/bin/bash

# Set routing
sysctl -w net/ipv4/conf/eth0/proxy_arp=1
sysctl -w net/ipv4/ip_forward=1

# Set up interface
ip -6 link set $dev up
ip -6 addr add $ifconfig_ipv6_local dev $dev
ip -6 route add  $ifconfig_ipv6_remote/$ifconfig_ipv6_netbits dev $dev

exit 0

client.down

#!/bin/bash

# Remove interface
ip -6 addr del $ifconfig_ipv6_local/$ifconfig_ipv6_netbits dev $dev
ip -6 link set $dev down
ip -6 route del $ifconfig_ipv6_remote dev $dev

Die beiden sysctl dienen dazu, dass der Rechner auf dem der OpenVPN-Client läuft, auch zwischen den Netzen routen kann. Werden die Zeilen nicht gesetzt. können sich nur die Gegenstellen selbst direkt erreichen später.

Soweit sollten nun die Grundlagen gelegt sein, eine gegenseitige OpenVPN-Verbindung herstellen zu können. Im einfachsten Fall kann man auf beiden Seiten durch ein /etc/init.d/openvpn start die Verbindung starten. In /var/log/syslog bzw. /var/log/messages sollte man dann beobachten können, ob eine Verbindung zustande kommt. Wenn Ja, gibt es auf der Server-Seite folgendes Interface:

tun0      Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet6-Adresse: fd22::1/128 Gültigkeitsbereich:Global
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metrik:1
          RX packets:30158 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25038 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX-Bytes:4187965 (4.1 MB)  TX-Bytes:2754439 (2.7 MB)

Und auf der Client-Seite folgendes:

tun0      Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet6-Adresse: fd22::2/128 Gültigkeitsbereich:Global
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metrik:1
          RX packets:57193 errors:0 dropped:0 overruns:0 frame:0
          TX packets:67250 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX bytes:6186053 (5.8 MiB)  TX bytes:8217266 (7.8 MiB)

Man kann hier sehen, dass der Server die IPv6 fd22::1 bekommen hat, der Client fd22::2. Zuerst sollte man mit einem

ping6 fd22::1

checken, ob lokal überhaupt alles korrekt funktioniert. Ist dass der Fall, testst man ein

ping6 fd22::2

Funktioniert beides, hat man prinzipiell einen fertigen funktionierenden VPN-Tunnel!

Schritt 3: IPv4 über IPv6 tunneln

Jetzt haben wir soweit eine funktionierende IPv6 VPN-Verbindung über die wir prinzipiell auch andere IPv6 Adressen routen können, mit IPv4 kommen wir aber an der Stelle aber nicht wirklich weit.

Damit wir nun IPv4 über IPv6 tunneln können, behelfen wir uns einer Kernel-Erweiterung, die leider nicht so wirklich üppig dokumentiert ist, aber an sich recht einfach einzusetzen ist, wenn man mal verstanden hat wie sie funktioniert.

Prinzipiell ist der Ansatz folgender: Man richte zwischen Zwei IPv6 Endpunkten einen Tunnel ein und packe IPv4 Pakete in IPv6 und packe die auf der Gegenseite wieder aus. Unsere Endpunkte sind fd22::1 und fd22::2. Entsprechend würde es dann auf der OpenVPN-Server Seite so aussehen:

ip -6 tunnel add ip4ip6tunnel mode ip4ip6 remote fd22::2/128 local fd22::1/128
ip link set ip4ip6tunnel up
ip addr add 192.168.254.1 dev ip4ip6tunnel

Befehl 1 legt einen Tunnel über ein virtuelles Interface namens ip4ip6tunnel an, Befehl 2 fährt das Interface hoch und Befehl 3 fügt dem Interface eine IPv4 hinzu, irgendwie muss man ja den Traffic routen können.

Auf der Gegenseite muss natürlich passendes Gegenstück angelegt werden, sonst landet alles im Nirvana:

ip -6 tunnel add ip4ip6tunnel mode ip4ip6 remote fd22::1/128 local fd22::2/128
ip link set ip4ip6tunnel up
ip addr add 192.168.254.2 dev ip4ip6tunnel

„Sitzt“ man jetzt auf der OpenVPN-Server Seite und pingt die 192.168.254.2, wird das „eingepackt“, von fd22::1 nach fd22::2 geschickt, dort wieder ausgepackt und die dortige 192.168.254.2 rewiedert den Ping.

Das ganze können wir jetzt soweit in die up- und down-Skripte packen so das bei Herstellung der VPN-Verbindung auch automatisch die IPv4 Verbindung aufgebaut wird.

OpenVPN-Server – server.up

#!/bin/bash

# Set routing
sysctl -w net/ipv4/conf/eth0/proxy_arp=1
sysctl -w net/ipv4/ip_forward=1

# Remove old IPv4-to-IPv6 tunnel
ip link set ip4ip6tunnel down
ip -6 tunnel del ip4ip6tunnel

# Set up interface
ip -6 link set $dev up
ip -6 addr add $ifconfig_ipv6_local dev $dev
ip -6 route add  $ifconfig_ipv6_remote/$ifconfig_ipv6_netbits dev $dev

# Set up IPv4-to-IPv6 tunnel
ip -6 tunnel add ip4ip6tunnel mode ip4ip6 remote fd22::2/128 local fd22::1/128
ip link set ip4ip6tunnel up
ip addr add 192.168.254.1 dev ip4ip6tunnel

OpenVPN-Server – server.down

#!/bin/bash

# Remove IPv4-to-IPv6 tunnel
ip link set ip4ip6tunnel down
ip -6 tunnel del ip4ip6tunnel

# Remove interface
ip -6 addr del $ifconfig_ipv6_local/$ifconfig_ipv6_netbits dev $dev
ip -6 link set $dev down
ip -6 route del $ifconfig_ipv6_remote dev $dev

exit 0

OpenVPN-Client – client.up

#!/bin/bash

# Set routing
sysctl -w net/ipv4/conf/eth0/proxy_arp=1
sysctl -w net/ipv4/ip_forward=1

# Remove old IPv4-to-IPv6 tunnel
ip link set ip4ip6tunnel down
ip -6 tunnel del ip4ip6tunnel

# Set up interface
ip -6 link set $dev up
ip -6 addr add $ifconfig_ipv6_local dev $dev
ip -6 route add  $ifconfig_ipv6_remote/$ifconfig_ipv6_netbits dev $dev

# Set up IPv4-to-IPv6 tunnel
ip -6 tunnel add ip4ip6tunnel mode ip4ip6 remote fd22::1/128 local fd22::2/128
ip link set ip4ip6tunnel up
ip addr add 192.168.254.2 dev ip4ip6tunnel

exit 0

OpenVPN-Client – client.down

#!/bin/bash

# Remove IPv4-to-IPv6 tunnel
ip link set ip4ip6tunnel down
ip -6 tunnel del ip4ip6tunnel

# Remove interface
ip -6 addr del $ifconfig_ipv6_local/$ifconfig_ipv6_netbits dev $dev
ip -6 link set $dev down
ip -6 route del $ifconfig_ipv6_remote dev $dev

exit 0

Soweit wird dann automatisch auch alles notwendige gehandled, dass z.B. das IPv4-zu-IPv6 Interface heruntergefahren wird, wenn der VPN-Tunnel geschlossen wird.

So, jetzt kann OpenVPN-Server den Client erreichen und umgekehrt, damit es aber aus den kompletten IPv4 Zielnetzen funktioniert, ist noch etwas Routing notwendig und vielleicht auch drehen an IPTables.

Schritt 4: Routing von/zu Zielnetzen, anpassen Firewall (IPTables)

Gehen wir mal von folgendem Szenario aus: Das Netz hinter dem OpenVPN-Server ist ein 192.168.100.0 Netz, hinter dem OpenVPN-Client ein 192.168.101.100 Netz.

Der OpenVPN-Server hat die .200 ebenso wie der Client in ihrem jeweiligen Netz, ebenso hat die Fritz!Box jeweils die .254.

Die Ausgangslage ist so, dass die Clients auf beiden Seiten die Fritz!Box als Gateway nutzen. Jetzt gibt es 2 Varianten, wie man von einem Client das Netz auf der Gegenseite erreichen kann:

Variante 1: Ich konfiguriere auf jedem Client in den Netzen „Wenn du in das Netz auf der anderen Seite willst, nehme die .200 in deinem Netz“ oder

Variante 2: Ich teile der Fritz!Box mit, dass alle Anfragen ins andere Netz über die .200 zu gehen haben.

Letztere Variante ist dann doch wesentlich komfortabler. Was nun zu tun ist, ist einfach:

  1. Fritz!Box Konfigurationsoberfläche aufrufen, anmelden
  2. Punkt Heimnetz aufrufen
  3. Unter Netzwerk auf Netzwerkeinstellungen gehen
  4. Dort IPv4-Routen aufrufen
  5. Dort Neue IPv4-Route anlicken

Soweit, sogleich auf beiden Seiten. Jetzt kommt der Unterschied:

Da wir aus Netz A (192.168.100.0) das Netz B (192.168.101.0) erreichen wollen, müssen wir bei IPv4-Netzwerk 192.168.101.0, Subnetzmaske 255.255.255.0 und bei Gateway 192.168.100.200 eintragen. Damit sagt man, dass die 192.168.100.200 zuständig ist, wenn Anfragen für das Netz 192.168.101.0 kommen.

Genauso wie man es hier auf der OpenVPN-Server Seite im Netz A konfiguriert hat, muss man es nun umgekehrt auch auf der OpenVPN-CLient Seite im Netz B machen. D.h. man muss mitteilen, dass für alle Anfragen in das Netz 192.168.100.0 die 192.168.101.200 zuständig ist.

Ist das erledigt, muss noch etwas getan werden: Man muss in Netz A auf der Fritz!Box mitteilen, das Anfrage für das Netz 192.168.254.0 auf die 192.168.100.200 gehen, in Netz B auf der Fritz!Box für 192.168.254.0 über die 192.168.101.200. Warum das? Die Brücken IPs sind die 192.168.254.1 und .2 – entsprechend wird der Verkehr über die Adressen geschickt. Führen wir mal ein traceroute aus und gucken es uns an:

leonard:~ # traceroute -n 192.168.101.254
traceroute to 192.168.101.254 (192.168.101.254), 30 hops max, 40 byte packets using UDP
 1  192.168.100.200 (192.168.100.200)  0.238 ms   0.103 ms   0.103 ms
 2  192.168.254.2 (192.168.254.2)  101.001 ms   101.213 ms   100.284 ms
 3  192.168.101.254 (192.168.101.254)  99.443 ms   98.594 ms   97.748 ms

Man sieht, dass vom Ausgangsrechner die Daten über die 192.168.100.200 zur 192.168.254.2 und dann zur 192.168.101.254 gehen.

Jetzt ist es noch notwendig, das Routing direkt auch in den up- und down-Skripten zu setzen:

OpenVPN-Server – server.up

#!/bin/bash

# Set routing
sysctl -w net/ipv4/conf/eth0/proxy_arp=1
sysctl -w net/ipv4/ip_forward=1

# Remove old IPv4-to-IPv6 tunnel
route del -net 192.168.254.0/24 dev ip4ip6tunnel
route del -net 192.168.101.0/24 dev ip4ip6tunnel
ip link set ip4ip6tunnel down
ip -6 tunnel del ip4ip6tunnel

# Set up interface
ip -6 link set $dev up
ip -6 addr add $ifconfig_ipv6_local dev $dev
ip -6 route add  $ifconfig_ipv6_remote/$ifconfig_ipv6_netbits dev $dev

# Set up IPv4-to-IPv6 tunnel
ip -6 tunnel add ip4ip6tunnel mode ip4ip6 remote fd22::2/128 local fd22::1/128
ip link set ip4ip6tunnel up
ip addr add 192.168.254.1 dev ip4ip6tunnel
route add -net 192.168.254.0/24 dev ip4ip6tunnel
route add -net 192.168.101.0/24 dev ip4ip6tunnel

OpenVPN-Server – server.down

#!/bin/bash

# Remove IPv4-to-IPv6 tunnel
route del -net 192.168.254.0/24 dev ip4ip6tunnel
route del -net 192.168.101.0/24 dev ip4ip6tunnel
ip link set ip4ip6tunnel down
ip -6 tunnel del ip4ip6tunnel

# Remove interface
ip -6 addr del $ifconfig_ipv6_local/$ifconfig_ipv6_netbits dev $dev
ip -6 link set $dev down
ip -6 route del $ifconfig_ipv6_remote dev $dev

exit 0

OpenVPN-Client – client.up

#!/bin/bash

# Set routing
sysctl -w net/ipv4/conf/eth0/proxy_arp=1
sysctl -w net/ipv4/ip_forward=1

# Remove old IPv4-to-IPv6 tunnel
route del -net 192.168.254.0/24 dev ip4ip6tunnel
route del -net 192.168.100.0/24 dev ip4ip6tunnel
ip link set ip4ip6tunnel down
ip -6 tunnel del ip4ip6tunnel

# Set up interface
ip -6 link set $dev up
ip -6 addr add $ifconfig_ipv6_local dev $dev
ip -6 route add  $ifconfig_ipv6_remote/$ifconfig_ipv6_netbits dev $dev

# Set up IPv4-to-IPv6 tunnel
ip -6 tunnel add ip4ip6tunnel mode ip4ip6 remote fd22::1/128 local fd22::2/128
ip link set ip4ip6tunnel up
ip addr add 192.168.254.2 dev ip4ip6tunnel
route add -net 192.168.254.0/24 dev ip4ip6tunnel
route add -net 192.168.100.0/24 dev ip4ip6tunnel

exit 0

OpenVPN-Client – client.down

#!/bin/bash

# Remove IPv4-to-IPv6 tunnel
route del -net 192.168.254.0/24 dev ip4ip6tunnel
route del -net 192.168.100.0/24 dev ip4ip6tunnel
ip link set ip4ip6tunnel down
ip -6 tunnel del ip4ip6tunnel

# Remove interface
ip -6 addr del $ifconfig_ipv6_local/$ifconfig_ipv6_netbits dev $dev
ip -6 link set $dev down
ip -6 route del $ifconfig_ipv6_remote dev $dev

exit 0

Es ist absolut notwendig, das auf beiden Seiten die Routen gesetzt werden. Der Grund hierfür ist sehr einfach: Ist z.B. nur auf der einen Seite die Route korrekt gesetzt, wird ein Datenpaket ins andere Netz geschickt und entgegen genommen. Anschließend will die Gegenstelle etwas zurückschicken, findet aber keine passende Route die den Weg zurück zeigt – entsprechende landen die Daten nirgendwo und es kommt keine Verbindung zustande.

Eine Spezialität gibt es noch, wenn man iptables einsetzt und das Forwarding generell erst mal verbietet:

Möchte man dass der Verkehr ungehindet zwischen den getunnelten IPv4 Netzen laufen soll, kann folgendes weiterhelfen

iptables -A FORWARD -i eth0 -o ip4ip6tunnel -j ACCEPT
iptables -A FORWARD -o eth0 -i ip4ip6tunnel -j ACCEPT

Damit wird alles erlaubt, was in den Tunnel rein geht oder raus kommt. Natürlich kann man da auch viel restriktiver rangehen, wenn man möchte.

Soweit sogut – das war aus meiner Sicht alles wichtige dazu. Sollte ich etwas vergessen haben, meckern! Ansonsten werde ich mich noch bemühen, Screenshots in nächster Zeit hinzu zu fügen und ggf. auch die eine oder andere erklärende Grafik.

Und Ja: Es gibt erkannten Optimierungsbedarf bei den Schriftformatierungen hier im Blog – ich arbeite dran 😉

Das könnte Dich auch interessieren...

25 Antworten

  1. mcgreg sagt:

    Hallo!
    Ich habe ebenso dieses „kann über ipv4 nicht auf meinen Rechner zugreifen“ Problem weil ich jetzt bei Unitymedia über ipv6 online bin. Würde eben gerne wieder einen webserver/ftp server laufen lassen, aber scheitere kläglich. Ich habe die CT 6/2013 und habe es so verstanden, dass man einen zusätzlichen Rechner/Server braucht, der schon über ipv4 verbunden ist und man mit diesem eben eine ssh Tunnel macht.
    Geht es garnicht anders? Leider bin ich technisch nicht soo fit um alles zu verstehen.

    Freundliche Grüße
    mcgreg

    • Manuel sagt:

      Hallo mcgreg,

      in deiner Konstellation wird dir mein Aufbau nicht wirklich behilflich sein. Ich kann dir auch nur empfehlen, dich an den Artikel aus der C’t zu halten. In dem Artikel wird glaube ich auch geschrieben, das UnityMedia derzeit an einer Lösung arbeitet, auch mit IPv6 Anschlüssen für die Außenwelt erreichbar zu sein. Evtl. hörst du einfach mal bei denen nach, wie weit die sind.

      Gruß
      Manuel

  2. Bachsau sagt:

    “Never touch a running system!” ist was für laien, nicht für ITler. Als Admin wird man dich mit dieser Einstellung aus jedem Haus jagen, wenn du nicht bereit bist, die Systeme ständig auf dem aktuellen Stand zu halten. 😉

    • Manuel sagt:

      Jein 😉 Versionsupdates stehen außer Frage (Thema Security), ebenso der Wechsel auf andere Software wenn vorhandene nicht mehr unterstützt wird. Es muss halt nur nicht immer Featurehascherei sein … wobei es auch außer Frage steht, das man immer über den Tellerrand blicken sollte auch gerade um Pro- und Contra abwägen zu können. Wer nicht alle Seiten kennt, kann auch nicht wirklich seriös die beste Lösung für etwas finden.
      Gerade beim Thema IPv6 war es so, als ich mich vor langer Zeit mal mit beschäftigen wollte, das noch SEHR viel zu dem Thema halbgar war. Das hat sich merklich mittlerweile geändert.

  3. PdXY sagt:

    Wenn beide Anschlüsse bei UM sind hat man leider keine feste IPv6. Liesse sich das dann mit v6-fähigem dyndns Anbieter und Client auf dem server machen ? Dann bleibt das Problem der Portfreigabe auf der fbox. Ideen zur Lösung?

    • Manuel sagt:

      So schwierig sollte es in deinem Fall gar nicht sein. Du hast zwar eine wechselnde IPv6 auf beiden Seiten, wenn du aber über einen DynDNS-Anbieter die jeweils andere Box ansprichst, sollte das problemlos klappen. Worauf du nur achten musst, ist, dass es ein DynDNS-Anbieter ist der IPv6 unterstützt. Im einfachsten Fall nutzt du den MyFritz-Box Dienst von AVM. Dann erhältst du automatisch auch einen DynDNS-Hostname, der IPv6 auflöst. Ansonsten sollte der Rest aus meinem How-To 1:1 passen.

  4. PdXY sagt:

    Versuche gerade, das ganze unter Windows zu realisieren. Server und Client können sich über IPv4 erreichen. Soweit hat alles geklappt, vielen dank für die Anleitung und Deine Tipps! Habe mit dem Routing allerdings noch Probleme, die fbox will sie nicht annehmen. Dazu evtl noch weitere infos? Evtl Email Kontakt möglich? 🙂

  5. PdXY sagt:

    Hm, mir fällt gerade ein, dass ich auf den Windows-Rechnern keine Route eingerichtet habe, und genau das zeigt mir ein traceroute auch an: Das Paket geht vom Start zur fbox und von dort zur eingetragenen route (Server IP). Da der Server keine Route hat, gibt er das Paket zurück an seinen Gateway (fbox) und das Paket geht zwischen den beiden unendlich hin und her. Eine Route auf dem Server (route -p ADD ) sollte das Problem schon lösen, sehe ich das richtig? Wenn es funktioniert kann ich ja meine Schritte nochmal per E-Mail schreiben zur evtl. Erweiterung des Blogposts.. Manchmal hat man einfach einen Elefant auf der Leitung sitzen! 😀

  6. PdXY sagt:

    Die Route willl er wegen Sonderzeichen wohl nicht in meinen Kommentar übernehmen.. Also „route -p ADD (Zielnetz) (Subnetzmaske) (IPv4 des VPN)“?! Sorry fürs spammen deiner Kommentare aber das VPN unter Windows einrichten ist sicherlich für einige ebenfalls interessant (hoffe ich).

  7. Manuel sagt:

    Ist viel einfacher … die Sache ist ja: Die jeweilige FB ist ja immer die, die als Gateway auf deinen Clients eingetragen ist. Du musst nun auf deiner FB einfach nur manuell die Route hinzufügen, dass alles was zum Netz X geht, über die Adresse Y geht. Natürlich musst du dann noch dafür sorgen, dass der Rechner mit Adresse Y auch ein aktives Routing hat. Meines wissens nach ist das Routing per default deaktiviert.

  8. PdXY sagt:

    IPv4 des VPN ist nicht im Subnetz der FB, dementsprechend nimmt die FB Addresse Y nicht, es sei denn Addresse Y ist die des physischen NIC auf dem Server. Dementsprechend muss der Server ja wissen, was er mit ankommenden Paketen für Netz X tun soll..

  9. PdXY sagt:

    Routing ist natürlich aktiviert per IPEnableRouter in der Registry..

  10. Manuel sagt:

    Nehmen wir an, Netz A ist 192.168.0.x und Netz B 192.168.1.x. Der Rechner, auf dem jeweils das VPN läuft, ist 192.168.0.123 bzw. 192.168.1.123. Du musst nun dafür sorge tragen, dass auf beiden Rechner das Routing aktiv ist. Dann solltest du zumindest zu Anfang erst mal die Firewall komplett ausschalten.
    Danach solltest du auf der FB der jeweiligen Netzseite folgende Route eintragen:

    Netz A: Netzwerk 192.168.1.0, SN 255.255.255.0, Gateway 192.168.0.123
    Netz B: Netzwerk 192.168.0.0, SN 255.255.255.0, Gateway 192.168.1.123

    Wenn man es dann z.B. von Netz A Seite sieht: Der Router bekommt etwas für 192.168.1.x und weiß, das er es an 192.168.0.123 schicken muss. Der Rechner 192.168.0.123 „kennt“ dann 192.168.1.x weil ihm via Routingregel gesagt wird, dass das Netz auf die andere Seite geroutet wird.

    Wichtig ist halt, dass das Routing auf der FB funktioniert und auf dem Rechner wo das VPN läuft. Das VPN Netz hat ja in der Regel nochmal ein komplett eigenes Netz, so dass du ihm entsprechend bekannt machen musst, dass auf der Gegenseite sich ein anderes Netz noch befindet. D.h. du musst in der ganzen Kette von Anfang bis Ende überall schauen, dass die Routen entsprechend gesetzt sind – und das auf beiden Seiten, sonst geht nichts!

  11. Manuel sagt:

    Schau erst mal, dass du von der einen zur anderen VPN Seite pingen kannst und du auch das auf der anderen Seite liegende Netz erreichen kannst. Funktioniert das soweit, würde ich mir Gedanken machen, wie andere Clients über den VPN-Server kommen.

  12. PdXY sagt:

    „Der Rechner 192.168.0.123 “kennt” dann 192.168.1.x weil ihm via Routingregel gesagt wird, dass das Netz auf die andere Seite geroutet wird.“ – Da liegt das Problem, wie Du schreibst, ist die VPN IP ein anderes Netz. Der Rechner mit 192.168.0.123 kennt Netz B nicht und schickt die Pakete an seinen Gateway, nicht an die VPN IP (siehe Comment #8). Dementsprechend braucht er wohl die Route zu Netz B mit der VPN IP in seiner Tabelle, oder habe ich da jetzt einen schweren Denkfehler?

  13. PdXY sagt:

    Kommentare haben sich überschnitten, sorry.. Genau das ist es, noch kann ich vom Server nur zur anderen VPN Seite pingen, aber nicht das auf der anderen Seite liegende Netz erreichen 🙂 Alles vollkommen logisch, wie gesagt, der Elefant saß auf der Leitung – ohne Route kein anderes Netz..

  14. PdXY sagt:

    Hat leider nicht funktioniert, versuche jetzt nur, das auf der anderen Seite liegende Netz zu erreichen, die route habe ich versucht in Windows zu setzen oder in OpenVPN nach der HowTo auf OpenVPN.net (http://openvpn.net/index.php/open-source/documentation/howto.html#scope).

    Serverseitiges Netz=192.168.178.0
    Clientseitiges Netz=192.168.177.0
    VPN IP Server=10.0.0.1
    VPN IP Client=10.0.0.2
    ping 10.0.0.2 – geht
    ping 192.168.177.1 – „10.0.0.1 – Zielhost nicht erreichbar“

  15. Manuel sagt:

    Kontaktiere mich doch mal via E-Mail …. macht es auf Dauer vielleicht doch einfacher. Meine hast du ja, hab dich die Tage schonmal angeschrieben gehabt 😉

  16. Jurgen sagt:

    Danke für das super Tutorial. Am Ende schreibst du, wie man iptables anpassen soll, wenn man aus dem Tunnel alles rein und rauslassen möchte. Wie muss man dafür vorgehen, wenn man ufw nutzt?

  17. Gabriel sagt:

    Ich habe bisher ein Setup, das zwei IPV4 Anschlüsse miteinander per FritzBox verbindet. Wenn ich mich per iPhone/VPN auf das eine Netz verbinde kann ich auch auf das zweite Netz zugreifen, ohne dass ich mich explizit dort hin VPNe. Bei Deinem Setting würde das doch auch gehen, so wie ich das verstanden habe, oder?

  18. Flo sagt:

    Wahnsinn! Super geile Arbeit, vielen Dank!

    Ich erstelle demnächst mal einen Blog Eintrag mit Verweis zu dieser Seite, ich hab deinen Artikel recht spät gefunden.

    Das einzige was noch fehlt wäre ein Road-Warrior Szenario mit beliebigen Netzen am Client.
    Eine Idee wäre alle privaten Netze außer das eigene über den ip4ip6tunnel zu schicken.
    Was meinst du?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.