Home sweet home
Nav
hide
S1
S2
S3
Name: OpenVPN getunnelt
Typ: Konfiguration
benötigt: Server ipv4/v6
Server ipv6

Problem

Möchte man auf einen Server zu Hause zugreifen, dann bietet sich OpenVPN an. Ist der eigene Anschluss jedoch vom Typ ds-lite, so hat man nur eine ipv6-Adresse, auf die man mit reinen ipv4-Anschlüssen (Ende 2016 noch häufig vorhanden) nicht zugreifen kann.


Es gibt Anbieter, die das Problem umgehen, hier wird eine Umsetzung beschrieben, falls man im Internet noch einen weiteren ipv4 und ipv6 fähigen Server "herum stehen" hat.

Die Idee

Statt auf den Server zu Hause (im Folgenden als RaspiFHM bezeichnet) direkt per OpenVPN zu zugreifen, wird per OpenVPN eine verschlüsselte IPv4 Verbindung zu einem Server im Internet hergestellt (im Folgenden als zb42 bezeichnet). Der Server zb42 im Netz greift wiederum auf den Server zu Hause mittels einer verschlüsselten OpenVPN ipv6 Verbindung zu. Innerhalb dieser ipv6 Verbindung werden ipv4 Pakete mit einem Tunnel transportiert. Somit kann man auch mit reinen ipv4-Anschlüssen auf den internen Server zugreifen, obwohl dieser nur ipv6 vollständig beherrscht.

Per ascii-art sieht es wie folgt aus:

         Client im Internet (ipV4)
         z.B. Smartphone
              |
              |                                                     
              |
          OpenVPN Server    OpenVPN Client ------------------------  OpenVPN Server
                                             ipv6 Verbindung, darin
                                                 ipv4in6 Tunnel   
              Server im Internet (zb42)                         Server zu Hause (raspiFHM)
                                                                 (hinter Fritz-Box 6490) 
 

Alternativ könnte man die ipv6 Verbindung von raspiFHM zu zb42 mit einem ssh-Tunnel umsetzen. Dies ist in der ct 2013 Ausgabe 6 beschrieben.

Da mir ipv6 relativ fremd ist (ist ja erst seit 10-20 Jahren in der Diskussion ...) und OpenVPN neu für mich ist (ich habe es bisher nicht gebraucht, früher hätte ich in der FritzBox eine Portweiterleitung gesetzt) ist die Umsetzung wahrscheinlich nicht die eleganteste, eventuell hilft sie dennoch weiter.

In meinem Szenario hat RaspiFHM keine feste IPv6 ‐ das Netz, welches man vom Provider bekommt kann sich ändern. Daher ist ein Dyndns-Anbieter relativ wichtig, avm stellt diesen per MyFritz zur Verfügung (s. unten).

Schritt 1, ipv6 für zb42

zb42 ist ein einfacher vserver, ich habe ihn statt eines webhosting Paketes gemietet. Die Preise sind vergleichbar, bei netcup (nein, ich bekomme keine Provision) kostet er ca 2,5 Euro/Monat. Es gibt auch einen für 19Cent, evtl. reicht der schon.
Auf dem Server habe ich ein vorgefertigtes Image ubuntu 14.04 LTS Server installiert (wurde in der Auswahl der Images angeboten).
Man liest die ip-Adresse und das Gateway irgendwo ab, in meinem Fall waren es als Prefix 2aXX:XXXX:XXXX:XXXX::64 und als Gateway fe80::1. X steht hier und im Folgenden für einen Buchstaben / eine Ziffer.
Für die ipv6 Netzwerk-Konfigurationn unter ubuntu 14.04 LTS ist die Datei /etc/network/interfaces zu ergänzen:

hide
openVPN/interfaceZB42
#Hinzufügen zur Datei /etc/network/interfaces
#static ip v6
#Netz ist 2aXX:XXXX:X:XXX::/64 gateway fe80::1 
iface eth0 inet6 static
address 2aXX:XXXX:X:XXX::1
netmask 64
gateway fe80::1
Parsed using GeSHi 1.0.8.6
Download / View Source / Run it   (depends on file type)

Danach ist ein reboot sinnvoll, jedenfalls wenn man per ssh auf den Server zugegriffen hat.
Test: Ein ping6 2aXX:XXXX:X:XXX::1 sollte eine Antwort liefern.

Schritt 2, ipv6 für raspiFHM

Ich gehe dabei davon aus, dass sich der raspiFHM zu Hause hinter einer Fritz Box befindet, getestet ist es mit der 6490.
Außerdem verwende ich ein Raspbian vom Dezember 2016, ein cat /etc/os-release zeigt bei mir u.a. PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)".

Schritt 3: Aufbau der OpenVPN Verbindung zwischen zb42 und raspiFHM

Bei Schritt 3 und 4 habe ich intensiv
https://blog.nerdingham.de/2013/02/27/verbinden-von-privaten-ipv4-netzen-uber-reine-ipv6-internet-anschlusse/
von Manuel Bernhardt zu Rate gezogen.

Folgende Schritte sollten durchgeführt werden.

Test: Startet man mit diesen Einstellungen den openvpn server auf raspiFHM und den Client auf zb42, so sollte eine Verbindung über die lokalen ipv6-Adressen fd22::1 (tun0 auf raspiFHM) und fd22::2 (tun0 auf zb42) möglich sein. Also ein ping6 fd22::1 und ping fd22::2 müsste auf beiden Rechnern funktionieren.

Schritt 4 - der IPv4 Tunnel.

Die OpenVPN Verbindung soll nun auch einen IPv4 Tunnel ermöglichen. Dazu sind die Schritte 4 in den Konfigurationsdateien hinzu zu fügen. Damit wird auf beiden Rechner ein Tunnel erzeugt und ein device ip4ip6tunnel angelegt.
Ein ifconfig zeigt auf raspiFHM
 
   ip4ip6tunnel Link encap:UNSPEC  Hardware Adresse FD-22-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
   inet Adresse:192.168.254.1  P-z-P:192.168.254.1  Maske:255.255.255.255
   ...
   
und auf zb42 erhält man
   ip4ip6tunnel Link encap:UNSPEC  Hardware Adresse FD-22-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
   inet Adresse:192.168.254.2  P-z-P:192.168.254.2  Maske:255.255.255.255
   ...
   
Außerdem zeigt route -n die entsprechenden Routen. Es ist damit ein lokales Netz 192.168.254.0/24 entstanden, in welchem sich raspiFHM und zb42 befinden. Das Netz wird über den Tunnel realisiert. Sollte man dieses schon verwenden, so muss oben in den Konfigurationsdateien ein anderes eingetragen werden.
Test: ping 192.168.254.1 und ping 192.168.254.2 sollte auf beiden Rechnern eine Antwort liefern.

Schritt 5 - erzeugen der Zertifikate für den Server zb42 und die Clients

Für den openvpn-Server auf zb42 sollen Zertifikate verwendet werden, da ich mehreren Rechnern den Zugang ermöglichen möchte. Außerdem wird wieder der Zugang über ein tun-Device + Routing gewählt. Prinzipiell sollte auch eine Bridge in das oben erstellte 192.168.254.0/24 möglich sein, dies habe ich nicht ausprobiert. (In der openvpn Dokumentation wird Routing auch als die schnellere Variante beschrieben.)

Das Erstellen der Zertifikate ist unter http://wiki.openvpn.eu/index.php/Erzeugen_einer_PKI_mit_EasyRSA beschrieben, daher hier nur die Kurzform, ich habe durchgehend als root gearbeitet.
Installieren von easy-rsa, sudo apt-get install easy-rsa, dann Anpassen der Datei /usr/share/easy-rsa/vars
     export CA_EXPIRE=36500
     export KEY_EXPIRE=20000

     export KEY_COUNTRY="DE"
     export KEY_PROVINCE="NRW"
     export KEY_CITY="eigene Stadt"
     export KEY_ORG="zb42"
     export KEY_EMAIL="eigene email Adresse"
     export KEY_OU="privat"              

     export OPENVPN=openvpn
     
Dabei wird die Gültigkeit der ca auf ca 100 Jahre gesetzt, jeder zertifizierte Schlüssel soll 20000 Tage gültig sei, das reicht sicher erstmal.
Danach wird die ca (certificate authority) erstellt, im Verzeichnis /usr/share/easy-rsa
     . ./vars 
     ./clean-all
     ./build-ca
     ./build-dh
     
(Variablen in der aktuellen shell definieren, alle Schlüssel löschen, ca erstellen, diffie-hellman Datei erstellen)
Hinweis: Die CA sollte nicht auf dem Rechner im Netz steht erzeugt werden, sondern auf einem Rechner ohne Netz-Zugang - Sicherheitsgründe. Wenn jemand an meine CA heran kommt, kann er Zertifikate für weitere Clients meines VPNs erzeugen und signieren.
Dann das Paar aus private key und public key / Zertifikat des Servers:
     ./build-key-server serverZB42
     
Beim Challenge-Passwort gibt man nur Enter ein. Das ist nicht das Passwort für den Schlüssel. Ein Server sollte kein Passwort haben, da dies sonst beim Starten des openvpn Servers abgefragt werden müsste.
Die Dateien ca.crt, serverZB42.crt, serverZB42.key und dh2048.pem müssen in das Verzeichnis /etc/openvpn auf zb42. Die Rechte von serverZB42.key müssen 600 sein - sie waren es bei mir.

Für jeden Client, also jedes Gerät, dass sich mit dem openvpn Server verbinden soll, muss ein private key und ein signiertes Zertifikat erstellt werden, z.B. für ein smartphone und ein Notebook
     ./build-key-pass vpnclientSmartKaro
     ./build-key-pass vpnclientKspace42
     
Hier gebe ich ein Passwort ein, dass muss auf dem Client für die Verbindung eingetippt werden, man kann es dort natürlich speichern. Das Challenge-Passwort ist wieder leer / nur Enter.

Schritt 6 - openVPN Server auf zb42

Evtl. muss IPv4-Routing eingeschaltet werden: echo "1" > /proc/sys/net/ipv4/ip_forward (temporär) und in /etc/sysctl.conf die Zeile net.ipv4.ip_forward=1 eintragen / Auskommentierung # entfernen (auch nach dem nächsten Neustart).
Für den IPv4 OpenVPN Server auf zb42 ist wieder eine server.conf notwendig. Der Inhalt stammt von http://wiki.openvpn.eu/index.php/Config_ServerNET_Routing und ist leicht angepasst:

hide
openVPN/ZB42Server.conf
#Datei /etc/openvpn/server.conf auf zb42 
server 192.168.253.0 255.255.255.0 # Das virtuelle VPN-Netzwerk (+ tls-server)
#hier muesste doch auch eine bridge in das 254er Netz moeglich sein?
#lassen wir es so, ein bisschen routing sollte nicht stoeren
port 1194 # Auf Port 1194 horchen
#proto udp # Protokoll UDP, für TCP: proto tcp-server
proto tcp-server
dev tun1 # tun0 haben wir schon
 
# Hier die Pfade anpassen um auf die erstellten Keys zu verweisen
ca ca.crt
cert serverZB42.crt   
key serverZB42.key    
dh dh2048.pem
 
client-to-client # Daten von VPN-Client zu VPN-Client wird direkt in OpenVPN weitergeleitet
 
#push "route 192.168.1.0 255.255.255.0" # Den Client über das Server-LAN informieren (wichtig!)
push "route 192.168.254.0 255.255.255.0" # Client soll das getunnelte 192.168.254.0 erreichen
 
# float # Nur wenn Clients ihre IPs während der Verbindung wechseln, waehrend?
float
 
ping-timer-rem
keepalive 20 180 # Alle 20 Sekunden pingen. 3 Minuten Timeout fuer CLientverbindung
 
verb 3 # 3 normal Zum Debugging erhöhen
mute 50 # Zum Debugging auskommentieren
#log-append /etc/openvpn/openvpn.log #war zum test, syslog ist standard
Parsed using GeSHi 1.0.8.6
Download / View Source / Run it   (depends on file type) Die Konfigurationsdatei sorgt für ein neues Netz 192.168.253.0 auf zb42. Daher ist in der raspiFHM in den up und down Scripten die Route auf 192.168.253.0 gesetzt / gelöscht.

Danach kopiert man die Schlüsseldateien von oben (so noch nicht geschehen) nach /etc/openvpn und startet den openvpn neu.

Schritt 7 - Client für Android einrichten

getestet mit dem Client OpenVPN Connect
Alle benötigten Schlüssel-Dateien: ca.crt, vpnclientSmartKaro.crt, vpnclientSmartKaro.csr und vpnclientSmartKaro.key werden in ein Verzeichnis geschoben. In dieses Verzeichnis kommt dann noch die Konfigurations-Datei configSmartphone.ovpn:

hide
openVPN/configSmartphone.ovpn
#configSmartphone.ovpn für OpenVPN Connect
client
dev tun
proto tcp-client
remote zb42.de 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert vpnclientSmartKaro.crt
key vpnclientSmartKaro.key
ns-cert-type server
verb 3
 
Parsed using GeSHi 1.0.8.6
Download / View Source / Run it   (depends on file type) Das ganze Verzeichnis schiebt man auf das SmartPhone (sd-Karte). ( - Wer das hat kann auf das OpenVPN zugreifen, falls mir mein Handy abhanden kommt, werde ich den openvpn Server herunter fahren und erst wieder starten, wenn ich mich darum gekümmert habe, wie man ein Zertifikat wieder entzieht. )

Die Konfigurationsdatei importiert man im Menu unter Import Profile from SD Card. Beim Verbinden muss man dann noch das Passwort von oben (Erstellen des Client-Zertifikates) angeben und danach sollte es funktionieren. Aufgefallen 2019: Die Daten dürfen nicht auf der externen sd-karte liegen, vielleicht ein Rechteproblem?
In meinem Beispiel habe ich mit dem Browser des Smartphones unter Angabe der URL http://192.168.254.1:8083 Zugriff auf einen fhem Server auf dem raspberry pi. Prinzipiell gewährt das OpenVPN ipv4 Zugriff auf die Netzwerke 192.168.253.0 (nur zb42 und andere VPN-Clients sind darin) nd 192.168.254.0 (nur zb42 und raspiFHM befinden sich darin).

... und ein Problem

Der openVPN Client auf zb42.de zeigt relativ häufig den status not running (service openvpn status). Die Ursache ist mir nicht klar, es scheint am Server auf dem pi zu liegen jedoch nicht mit der Zwangstrennung zusammen zu hängen.

Daher ein Skript, welches den Zustand auf zb42.de prüft und falls notwendig den Server auf dem pi neu startet und auf dem Server ebenfalls neu startet. Dazu muss ein login auf pi über einen key möglich sein. Außerdem muss der user pi sudoer sein. Damit hat man die Situation: zb42 übernommen führt zu pi übernommen, unschön, aber mir fällt keine andere Lösung ein.

2019: Das Script muss nochmal überarbeitet werden? - startet man zb42 neu, wird die Verbindung nicht neu aufgebaut. Das "not running" wird nicht angezeigt.
Vielleicht sollte man den ping auf die 192.168.254.2 prüfen

Dieses Script sollte per cron dann z.B. alle 5 Minuten auf zb42 laufen:

hide
openVPN/watchVPN.sh
#!/bin/bash
#openvpn client haelt die Verbindung nicht dauerhauft, 
#scheint nichts mit dem erneuern der Verbindung durch
#unitiy media zu tun zu haben
export PATH=$PATH:/sbin
#pfad da sonst der service befehl nicht funktioniert, er ruft
#das init script, dieses braucht /sbin im Pfad
function check
{
  service openvpn status | grep -i dead
  running=$?  
  if [ $running -eq 0 ]
  then
    ssh pi@IhrServer.myfritz.net sudo service openvpn restart
    sleep 5 
    #zeitverzoegerung    
    service openvpn start
    datum=$(date)
    echo "$datum - openvpn problem, restart" >> /var/log/watchOpenVPN.log
  else
    datum=$(date)
    echo "$datum - openvpn ok" >> /var/log/watchOpenVPN.log
  fi
}
 
check
 
 
Parsed using GeSHi 1.0.8.6
Download / View Source / Run it   (depends on file type) Hinweis: der Cron-Eintrag für minütlichen Check
    */1  *     * * *     root   /usr/local/sbin/watchVPN.sh > /dev/null 2>&1
   
Ausgabeumleitung um die Mail von cron an root zu verhindern

Erweiterung - erreiche andere Rechner im Heimnetz

Ob das so sinnvoll ist ...
zb42 stellt bisher nur eine Verbindung in das Netz 192.168.254.0 her. Dort befindet sich nur der raspiFHM. Über den Eintrag

push "route 192.168.0.0 255.255.255.0" # Client soll das getunnelte 192.168.0.0 erreichen 

in /etc/openvpn/server.conf auf zb42 erreicht man, dass auch eine Anfrage an das Netz 192.168.0.0/24 über den VPN Server laufen soll. Damit dies funktioniert

Tja, das ist doch länger geworden als ich dachte. Ich hoffe der Text beinhaltet nicht zu viele Fehler. Immerhin ein wenig über IPv6 und OpenVPN gelernt, wobei mehr Lücken als Wissen vorhanden sind. Vielleicht nutzt es ja sonst noch jemandem.

Karsten Römke (k Ponkt roemke at gmx in de), Rechtliches, Datenschutz, etc.
Rein private Seite, lediglich eine Spielerei
Last modified: 2017-01-03
Created: 2016-12-30
Reason: Tunnel um dslite zu umgehen
Home sweet home