Unitymedia IPv6 im VPN - wie macht man es richtig?

[GoaSkin]

Hallo,

mit Hilfe zweier RaspberryPI und OpenVPN habe ich einen permanenten VPN-Tunnel zur Verbindung zweier DS_Lite Anschlüsse über IPv6 realisiert. Das funktioniert soweit auch. Die lokalen IPv4-Netze sind für die jeweils andere Seite erreichbar.

Aufgrund der Tatsache, dass zwei HP-Multifunktionsdrucker im Spiel sind, die sich nur über Bonjour-Anfragen (mDNS) vollständig nutzen lassen, habe ich noch einen Proxy für die entsprechenden Multicast-Anfragen aufgesetzt, der im Prinzip nun auch funktioniert.

Der Haken dabei: Die Geräte, die ihre Dienste über Bonjour oder Zeroconf propagieren, nennen über diese Multicasts nicht nur ihre IPv4-Adresse, sondern auch ihre IPv6-Adresse. Durch den Proxy bekommen die Geräte in Netz A nun mitgeteilt, dass auf den dynamischen IPv6-Adressen des anderen Unitymedia-Anschlusses irgendwelche Dienste laufen. Datenverkehr, der an diese IPv6-Adressen adressiert ist, wandert natürlich nicht durch den Tunnel, sondern durch das Internet, wo der Gegenrouter mangels Portfreigaben dann eine Verbindung ablehnt.

Weiss jemand, ob man es über OpenVPN irgendwie realisieren kann, dass neben den in der OpenVPN-Konfiguration angegebenen, statischen IPv4-Netzen auch Pakete mit den dynamischen IPv6-Adressen als Ziel durch den Tunnel wandern?

 

[thomasschaefer]

Das geht schon.

Ein Lösungsansatz wäre Unique Local Unicast -Adressen für die Drucker zu verwenden (fd....) die wären relativ statisch.

Man kann natürlich auch die öffentlichen IPv6-Adressen durch den Tunnel jagen, wobei ich zugeben muss das bisher nur für eine Richtung gemacht zu haben. Vielleicht hilft es Dir als Anregung trotzdem weiter:

http://www.thomas--schaefer.de/openvpn-fuer-altlasten.html

Zum Erzeugen der server.ovpn Datei:

http://www.thomas--schaefer.de/server.ovpn.sh

Mit freundlichen Grüßen
Thomas Schäfer

 

[addicted]

Benutzt Du tun oder tap Modus?

Falls Du OpenVPN im tun Modus verwendest, dann musst Du der Config die Direktive tun-ipv6 hinzufügen, damit v6 transportiert werden kann.

<i>
</i>tun-ipv6
ifconfig 192.168.255.1 192.168.255.2 # ifconfig Zeile muss existieren, IPs beliebig
ifconfig-ipv6 <local-address> [<remote-gateway-address>]
route-ipv6 <network>/<mask> [<gateway-address>] [<metric>]

So kannst Du von OpenVPN selbst v6 Adressen und Routen auf das Interface legen lassen. Ich empfehle prinzipiell link local Adressen zu verwenden, aber da tun Interfaces kein Layer2 haben musst Du selbst welche setzen, z.B. fe80::1 und fe80::2.
Hinweis: ifconfig-ipv6 funktioniert momentan nur, wenn man gleichzeitig auch ifconfig verwendet. v6-only mit automatischer Konfiguration des Interfaces kann OpenVPN noch nicht.
Wenn tun-ipv6 gesetzt ist, kann man aber die Config auch extern auf das Interface bringen, oder z.B. über ein up script. Bei dynamischen Adressen vielleicht ganz sinnig, dann muss man nicht ständig die OpenVPN Config anpassen.


Am Einfachsten ist sicherlich mit ULAs zu arbeiten, wie Thomas vorgeschlagen hat. Die kannst Du festlegen und die Ändern sich nicht. Damit die Geräte in dem jeweils entfernten Netz eine ULA Adresse beziehen, kannst Du das Netz auch bequem vom Pi announcen (ohne Gateway). Normalerweise bevorzugen die Geräte allerdings globale Präfixe, da musst Du einfach mal gucken wie sich das auswirkt - ich habe ULA nicht im Einsatz, da ist meine Erfahrung limitiert.

Mit globalen IPs dürfte es aber auch mit ein paar Kapriolen klappen:
Da Du aber bei einem IP-Wechsel den Tunnel eh neu aufbauen musst, kannst Du dann auch einfach die Route für das entfernte Netz aktualisieren (in der OpenVPN Config oder via externes Script). Du weißt ja schon, wohin die Verbindung geht, und kannst aus der IP des Tunnelendpunktes vermutlich das zu routende Netz ableiten. Über ein externes Script stelle ich mir das nicht so schwierig vor

Super wichtig für das Routing: Wenn der Tunnelendpunkt und das zu routende Netz sich überlappen (Endpunkt innerhalb des zu routenden Netzes), musst Du für den Tunnelendpunkt eine spezifische Route setzen, die diesen weiterhin über die externe Verbindung leitet. Sonst geht nix mehr


Im tap Modus bekommst Du dann ganz andere Probleme, falls Du z.B. das VPN einfach in beide LANs reingebridged hast. Dann hättest Du überall zwei Netze und zwei Router.
Ich gehe aber mal davon aus, dass Du das nicht so gemacht hast. Sonst wäre das mit Multicast einfacher gewesen

 

[thomasschaefer]

Falls Du OpenVPN im tun Modus verwendest, dann musst Du der Config die Direktive tun-ipv6 hinzufügen, damit v6 transportiert werden kann.

Muss er meiner Ansicht nach nicht mehr, jedenfalls nicht wenn er openvpn 2.4 verwendet.

 

[addicted]

Sieh an, gut zu wissen. Ist auf meinen System noch nicht angekommen, das Release (27.12.2016).

 

[GoaSkin]

Vielen Dank an Thomas Schäfer für die ausführlichen Infos.

Ich verrate einmal, was ich gemacht habe, damit es mit Zeroconf / Bonjour / mDNS zwischen den Netzen klappt:

1.) In der Avahi-Konfiguration auf beiden Seiten des Tunnels sowohl wide-area, als auch den reflector deaktiviert. Avahi kommt weder mit einem TUN, noch mit einem TAP-Device klar und erfüllt daher seinen Zweck nicht.

2.) Auf beiden Seiten des Tunnels mdns-repeater gebaut und installiert: https://bitbucket.org/geekman/mdns-repeater/

3.) Sowohl in der Client-, als auch in der Servcer-Konfiguration der VPN-Verbindung:

<i>
</i>script-security 2
up "/etc/openvpn/up.sh"
down "/etc/openvpn/down.sh"

Mit den Parametern up und down werden zwei Skripte angegeben, die immer dann ausgeführt werden, wenn das tun/tap-Device entsteht bzw. dekonfiguriert wird.
in der up.sh steht dann:

<i>
</i>#!/bin/sh
/usr/bin/mdns-repeater eth0 tap0

und in der down.sh

<i>
</i>#!/bin/sh
/usr/bin/killall mdns-repeater

Das Ganze muss jeweils in ein Skript verpackt werden, weil openvpn den up und down-Skripten weitere Parameter hintendran packt, die mdns-repeater missverstehen würde. Wie man sieht, ich nutze das TAP-Device, aber ohne Bridging und behandle es wie ein TUN-Device. Dies ist in diesem Falle notwendig, weil das TUN-Device diese Multicasts verwerfen würde.

 

[addicted]

Ich ignoriere mal, dass Du mir nicht dankst und mische trotzdem weiter mit. Du musst mir einfach deutlich sagen, wenn ich mich raus halten soll. :zunge:

1.) In der Avahi-Konfiguration auf beiden Seiten des Tunnels sowohl wide-area, als auch den reflector deaktiviert. Avahi kommt weder mit einem TUN, noch mit einem TAP-Device klar und erfüllt daher seinen Zweck nicht.

Dass er tap nicht mag, hätte ich nicht gedacht. Hast Du versucht ne Bridge drüberzulegen?

Wie man sieht, ich nutze das TAP-Device, aber ohne Bridging und behandle es wie ein TUN-Device. Dies ist in diesem Falle notwendig, weil das TUN-Device diese Multicasts verwerfen würde.

Ich hab das nicht wirklich gesehen, hast Du vielleicht den zentralen Teil der Config vergessen?
Das tolle an Multicast ist ja, dass es ohne Router auskommt. Das ist dann auch der Nachteil. Wenn Du Multicast über BD Grenzen werfen willst, musst Du das routen - was der mdns-repeater macht ist ansich nicht anders, er siedelt es nur eine Ebene höher an (was vermutlich auch recht sinnig ist bei so einem Protokoll).

Poste doch mal den Rest Deiner Configs, das up Script war ja nun nicht wirklich interessant.

 

[GoaSkin]

Ich möchte ja garkein Bridging, sondern ein geroutetes Netzwerk, damit nicht jeder Müll durch das VPN wandert.

Ein Bridging findet nicht alleine deshalb statt, weil man in der OpenVPN-Konfiguration ein TAP-Device konfiguriert. Unterschied ist mehr, dass sich ein TAP-Device fast wie ein Ethernet-Interface verhält und eine (Pseudo-)Mac-Adresse besitzt. Möchte man dann aber die lokalen Netzwerke wirklich durch das VPN-Bridgen, müsste man im Linux-System noch eine Netzwerk-Bridge aufsetzen (genauso wie eine Bridge zwischen mehreren Ethernet-Interfaces, nur dass ein Device dabei dann das TAP-Device ist). Kurz gesagt: TAP verhält sich wie eine virtuelle Netzwerkkarte, TUN wie eine PPP-Verbindung.

Über das virtuelle Netzwerksegment zwischen TAP-Devices an unterschiedlichen Standorten lassen sich Broadcasts und Multicasts transportieren. Avahi weigert sich aber, diese Interfaces dabei zu berücksichtigen. Darum behelfe ich mir in diesem Falle mit mdns-Repeator, der nichts anderes macht, als die Reflector-Funktion von Avahi, nur dass es diesem Dienst egal ist, ob ein Interface dabei kein Ethernet ist.

Vom Prinzip her habe ich mit meinem Setup ein geroutetes VPN, bei dem die Multicasts zur Namensauflösung jeweils auf einem Interface abgehört werden und auf dem anderen wiederholt (und umgekehrt). Jeder OpenVPN-Verbindungspartner spielt Proxy für diese Multicasts.

Client:

<i>
</i>client
dev tap
proto tcp6
remote ......
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
comp-lzo
verb 3
script-security 2
up "/etc/openvpn/up.sh"
down "/etc/openvpn/down.sh"

Server

<i>
</i>port 1194
proto tcp6-server
dev tap
ca ./easy-rsa/2.0/keys/ca.crt
cert ./easy-rsa/2.0/keys/server.crt
dh ./easy-rsa/2.0/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.2.0 255.255.255.0"
client-config-dir ccd
route 192.168.3.0 255.255.255.0
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
script-security 2
up "/etc/openvpn/up.sh"
down "/etc/openvpn/down.sh"

 

[addicted]

Ich möchte ja garkein Bridging, sondern ein geroutetes Netzwerk, damit nicht jeder Müll durch das VPN wandert.

Ich meinte ja auch bloß, dass Du eine Bridge alleine mit dem tap Device von OpenVPN anlegen kannst. Wenn Du nichts anderes da rein hängst, wandert der Traffic einfach nur von der Bridge aufs tap und umgekehrt. Dann kannst Du Avahi sagen, er soll das Bridge Interface verwenden.
Könnte natürlich sein, dass Avahi bei einer Bridge auch nicht mag. Wäre imho einen Versuch wert, aber wenn Du jetzt ein laufendes Setup hast, ist das ja auch nicht mehr so wichtig.

Aber eigentlich gings ja um v6: Bist Du damit schon weitergekommen?
Hast Du von meinen Hinweise zu v6 schon irgendwas ausprobiert?

Nebenbei, ich würde persönlich immer von pool und ccd Konfigurationen absehen, wenn ich eh nur eine site2site Verbindung baue. Dann sind die Configs einfacher.