blog.nerdingham.de

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

Manuel

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:

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 😉

Die mobile Version verlassen