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:
#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
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)".
- Eventuell Einschalten von ipv6, prüfe mit ifconfig, tauchen Einträge der Form inet6-Adresse:... auf, so ist es ok. Ansonsten findet man zum Beispiel unter https://www.elektronik-kompendium.de/sites/raspberry-pi/1912161.htm Hilfe zu dem Thema.
- Ausschalten der privacy exensions für ipv6.
Bei mir waren sie eingeschaltet. Hat die inet6-Adresse mit dem Gültigkeitsbereich Verbindung nichts mit der Mac-Adresse zu tun, dann sind die privacy extensions eingeschaltet. Diese sorgen dafür, dass die IP-Adresse beim Verbinden mit einem anderen Netz (also evtl. nach Zwangstrennung) erneuert wird. Ich weiss nicht, ob dies durch den DynDNS von AVM ausgeglichen wird. Da ich mit der Ip des RaspBerry nicht im Netz unterwegs bin sondern ihn als Server benutze, möchte ich eine eindeutige Interface ID (letzte 64 Bit der IP-Adresse haben). Diese kann auch aus der Mac-Adresse hervorgehen.
Dazu ist in der Datei /etc/dhcpcd.conf der Eintrag slaac private durch slaac hwaddr zu ersetzen.
Nach einem reboot sollte man zwei ip-Adressen haben, eine mit der Gültigkeit Verbindung, beginnend mit fe80:: eine beginnend mit dem Netzanteil den man vom Anbieter bekommen hat. Beide haben als interface id (letzten 64 Bit) eine Angabe, die der Mac-Adresse ähnlich ist (fffe ist eingefügt). - Portfreigaben auf der Fritzbox einrichten. Das sind keine Portfreigaben im alten Stil (NAT), sondern ein Ausschalten der Firewall für
bestimmte Ports eines Gerätes im eigenen Netz.
FritzBox -> Internet -> Freigaben -> Reiter IPv6 -> neues Gerät
Dort wählt man den Namen raspiFHM und öffnet die Firewall für Port 1194 (OpenVPN), ggf. 22 (ssh) und gestattet ping6 (zumindest zum Testen). Die Interface-ID ist wahrscheinlich schon richtig einetragen, es müssen die letzten 64 Bit der inet6 Adresse sein (beachte: 0en sind nicht nötig).
Den DHCPV6 Server der Fritzbox hatte ich bei meinen ersten Tests eingeschaltet, inzwischen ist er ausgeschaltet, da sich der pi seine IP über slaac selbst erstellt. Ich habe keine Ahnung, ob das auch klappt, wenn ich ein neues Netz bekommen sollte.
Test: im lokalen Netz ein ping6 auf die vollständige IPv6 (Netz und interface id), wenn eine Antwort kommt läuft IPv6. Danach vom Server zb42 ein ping6 / ssh auf die vollständige IPv6. Beides sollte funktionieren. - DNS-Eintrag für die IPv6 des raspiFHM.
Dazu nutze ich den Dienst MyFritz von AVM. Jede Freigabe in MyFritz erzeugt auch einen DNS Eintrag (mindestens für IPv6, denn dort existiert kein NAT, der Zugriff erfolgt über die IPv6, diese muss also zu ermitteln sein).
Also: FritzBox -> Internet -> Freigaben -> Reiter MyFRITZ!-Freigaben -> Button Neue MyFRITZ!-Freigabe.
Aus dem Menu wählt man raspiFHM, Andere Anwendung, Bezeichung ssh, Schema manuelle Eingabe, und dort ssh://, Port 22.
Als Ergebis erhalte ich in der Liste der Freigaben
raspiFHM ssh://raspifhm.XXXXXXXXXXXXXXXX.myfritz.net:22/ ssh
Die Einträge dürften ziemlich egal sein, es muss nur ein DNS-Eintrag für die IPv6 des Gerätes bei AVM erzeugt werden, wahrscheinlich hätte man auch ohne Konsequenzen http wählen können, da die Firewall der fritzbox nicht offen ist kann auch bei laufendem Webserver auf dem raspiFHM kein Zugriff über Port 80 erfolgen. Das habe ich nicht getestet.
Danach sollte raspiFHM von zb42 aus mit einem
ping6 raspifhm.XXXXXXXXXXXXXXXX.myfritz.net
oder auch
ssh raspifhm.XXXXXXXXXXXXXXXX.myfritz.net
erreichbar sein.
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.
- Auf dem raspiFHM wird der openvpn Server installiert, auf zb42 der Client. Auf der Kommandozeile bei beiden Rechnern:
sudo apt-get update sudo apt-get upgrade sudo apt-get install openvpn openssl
Das sollte openvpn 2.3 oder höher sein. Bei raspian ist die Version ok. Bei mir zeigt openvpn --version die Version 2.3.4 aus dem Januar 2016 an, bei ubuntu14.04 ist es ebenfalls ok. - Zum Erstellen der Verbindung kann die einfachste Variante, ein fester Schlüssel verwendet werden. Es sollen nur
zwei Rechner verbunden werden, daher wird auf Zertifikate verzichtet.
Erstellen des Schlüssels (auf raspiFHM):sudo openvpn --genkey --secret /etc/openvpn/static.key sudo chmod 600 /etc/openvpn/static.key
der letzte Schritt sollte nicht nötig sein, die Rechte standen bei mir schon auf -rw---- - Auf dem raspiFHM wird die .conf Datei nicht automatisch beim Start des Servers eingelesen. Daher in der Datei /etc/default/openvpn die Zeile AUTOSTART="server" einfügen.
- Auf raspiFHM sind drei Dateien in /etc/openvpn zu erzeugen (server.conf, server.up, server.down). Ich gebe hier die kompletten Dateien an,
die Zeilen, die mit Schritt 4 ... beschrieben sind müssen erst beim Ausführen/Testen der Schritte ergänzt werden.
Die Datei server.conf:hideDownload / View Source / Run it (depends on file type)openVPN/raspiServer.conf#Datei /etc/openvpn/server.conf auf raspiFHM dev tun proto tcp6-server ifconfig-ipv6 fd22::1 fd22::2 #ifconfig duerfte die ips der verbundenen devices angeben #So for this IPv6 VPN, we shall use so-called Unique Local Addresses 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-tun: starte tun nicht neu - evtl. problem bei dynamischer adresse #ist mir noch nicht klar persist-key user nobody #user openvpn, optional, siehe erklaerung group nogroup daemon verb 3
Parsed using GeSHi 1.0.8.6OpenVPN läuft als user nobody. Das Start-Script server.up wird dennoch als root ausgeführt. Das Stop-Script servver.down nicht. Daher kann dass Stop-Script in der angegebenen Variante nur laufen, wenn sudo Anweisungen eingebaut sind. Dazu muss mit Hilfe der Datei /etc/sudoers.conf dem User nobody oder openvpn das Recht gegeben werden die entsprechenden Befehle auszuführen. Ich habe den User openvpn angelegt und
openvpn ALL=(ALL:ALL) NOPASSWD: /sbin/ip,/sbin/route
in die sudoers.conf eingetragen. Tut man es nicht, wird man im systel-log Fehlermeldungen erhalten, die openvpn Verbindung funktioniert, nur der Abbau klappt nicht ganz.Die Datei server.up
hideDownload / View Source / Run it (depends on file type)openVPN/raspiServer.up#!/bin/bash # Set routing, ist mir nicht klar - routing ipv6? # ipv4 haben wir am Anfang doch nicht, ipv4/ip_forward schaltet routing ipv4 ein # vermute: auch die nächsten beiden Zeilen gehören zu Schritt 4 sysctl -w net/ipv4/conf/eth0/proxy_arp=1 sysctl -w net/ipv4/ip_forward=1 #Schritt 4 # Remove old IPv4-to-IPv6 tunnel route del -net 192.168.254.0/24 dev ip4ip6tunnel sudo /sbin/route del -net 192.168.253.0/24 #route del 192.168.253.0 ist die Route in das zweite ipv4 Netz auf #der zb42 Seite, siehe Schritt 6 ip link set ip4ip6tunnel down ip -6 tunnel del ip4ip6tunnel #Ende Schritt 4 # 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 #Schritt 4 # 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 für das IPv4 Vpn des zb42 route add -net 192.168.253.0/24 gw 192.168.254.2 #Ende Schritt 4 exit 0
Parsed using GeSHi 1.0.8.6Die Datei server.down
hideDownload / View Source / Run it (depends on file type)openVPN/raspiServer.down#!/bin/bash #Datei /etc/openvpn/server.down auf raspiFHM # Schritt 4 --- Remove IPv4-to-IPv6 tunnel sudo /sbin/route del -net 192.168.254.0/24 dev ip4ip6tunnel sudo /sbin/route del -net 192.168.253.0/24 sudo /sbin/ip link set ip4ip6tunnel down sudo /sbin/ip -6 tunnel del ip4ip6tunnel # Ende Schritt 4 # Remove interface sudo /sbin/ip -6 addr del $ifconfig_ipv6_local/$ifconfig_ipv6_netbits dev $dev sudo /sbin/ip -6 link set $dev down sudo /sbin/ip -6 route del $ifconfig_ipv6_remote dev $dev exit 0
Parsed using GeSHi 1.0.8.6 - Auf zb42 sind ebenfalls drei Konfigurationsdateien (client.conf, client.up, client.down) notwendig.
Auch hier gilt: Schritt 4 kann schon dazu genommen werden,
ist aber erst für den ipv4 Tunnel notwendig.
Die Datei client.conf
hideDownload / View Source / Run it (depends on file type) ie remote Angabe muss dem DNS IPv6 Eintrag aus MyFritz entsprechen. Hier habe ich user nobody auskommentiert, da ich noch keinen user openvpn (wie oben) installiert habe, das würde analog zur Variante beim raspiFHM funktionieren.openVPN/ZB42Client.conf#client.conf auf zb42 remote raspifhm.XXXXXXXXXXXXXXXX.myfritz.net 1194 dev tun proto tcp6-client ifconfig-ipv6 fd22::2 fd22::1 secret zb42.key script-security 2 up /etc/openvpn/client.up down /etc/openvpn/client.down comp-lzo keepalive 10 60 ping-timer-rem #persist-tun: starte tun nicht neu - evtl. problem bei dynamischer adresse #ist mir noch nicht klar persist-key #user nobody #group nogroup #wenn es läuft anpassen, down-script laueft mit rechten dieses users #also eigener user openvpn noetig mit ein paar Rechten in sudo verb 3
Parsed using GeSHi 1.0.8.6Die Datei client.up
hideDownload / View Source / Run it (depends on file type)openVPN/ZB42Client.up#!/bin/bash #Datei /etc/openvpn/client.up auf zb42 # Set routing - wahrscheinlich Schritt 4 sysctl -w net/ipv4/conf/eth0/proxy_arp=1 sysctl -w net/ipv4/ip_forward=1 #Schritt 4 # Remove old IPv4-to-IPv6 tunnel route del -net 192.168.254.0/24 dev ip4ip6tunnel ip link set ip4ip6tunnel down ip -6 tunnel del ip4ip6tunnel #ende Schritt 4 # 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 #Schritt 4 # 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 #ende Schritt 4 exit 0
Parsed using GeSHi 1.0.8.6Die Datei client.down
hideDownload / View Source / Run it (depends on file type)openVPN/ZB42Client.down#!/bin/bash #Datei /etc/openvpn/client.down auf zb42 #touch /tmp/rechte #obiges zeigt die Rechte unter dem das script laeuft #Schritt 4 #route hinweg route del -net 192.168.254.0/24 dev ip4ip6tunnel # Remove IPv4-to-IPv6 tunnel ip link set ip4ip6tunnel down ip -6 tunnel del ip4ip6tunnel #Ende Schritt 4 # 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
Parsed using GeSHi 1.0.8.6
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=openvpnDabei 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 serverZB42Beim 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 vpnclientKspace42Hier 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:
#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
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:
#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
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:
#!/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
*/1 * * * * root /usr/local/sbin/watchVPN.sh > /dev/null 2>&1Ausgabeumleitung 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
- braucht zb42 eine Route in das entsprechende Netz, daher auf zb42 in /etc/openvpn/client.up die Zeile
route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.254.1
ergänzen. - muss das Heimnetz wissen, wie man zurück in das Netz auf zb42.de kommt. Über ein NAT auf raspiFHM habe ich es nicht hinbekommen, daher setzte ich die enstprechenden Routen auf dem Default Gateway im Heimnetz, also auf der FritzBox. Dort unter Heimnetz, Heimnetzübersicht, Netzwerkeinstellungen zwei statische Routen dazu. die 192.168.254.0/24 und 192.168.253.0/24 sende ich an raspiFHM.