Raspberry Pi VPN – Teil 12: Tipps & Tricks

Raspberry Pi VPN

In dieser Artikelserie haben wir ein Virtual Private Network (VPN) aufgebaut, über das sich das Smartphone unterwegs mit den Heimnetzwerk verbinden kann. Das bietet einen erhöhten Schutz durch Verschlüsselung in fremden und offenen WLANs. Dazu kommt die Software Pi-Hole auf dem VPN-Server, die Trackingdienste wirkungsvoll blockiert. Das Thema ist durchaus komplex weil mehrere Komponenten involviert sind und die Probleme, die auftreten können, sind zahlreich. Aus diesem Grund will ich in diesem Beitrag zumindest die Problemlösungen vorstellen, die mir bei den Recherchen und VPN Tests zu dieser Serie über den Weg gelaufen sind.

Alternative Ports, falls 1194 in einem WLAN geblockt wird

Versetzen wir uns kurz in die Lage eines WLAN-Anbieters, der einen frei zugänglichen öffentlichen WiFi-Hotspot einrichten möchte – für das eigene Lokal zum Beispiel. Wir könnten das sicherheitsmäßig so machen, wie im eigenen WLAN daheim: Aus dem Internet darf niemand ins WLAN, aber aus dem WLAN darf jeder und alles ins Internet. Oder wir wählen alternativ einen restriktiven Weg, machen auch ausgehend erst mal alles dicht und geben nur explizit einige wenige Dienste (in Form von IP-Ports) frei, die zum Surfen im Internet gebraucht werden. So könnten wir probieren, Filesharing oder andere ungewollte Dienste zu verhindern.

Jetzt sind wir wieder wir selber, die einen VPN-Tunnel aus einem fremden WLAN in unser heimisches Netz aufbauen wollen. Das einleitende Szenario solte nur dazu dienen, uns klar zu machen, dass unser OpenVPN Port 1194 nicht in jedem freien WLAN auch wirklich freigegeben ist. Wenn sich der Betreiber für eine restriktive Vorgehensweise entschieden hat, dann können wir in seinem WLAN zwar problemlos im Internet surfen (TCP-Ports 80 und 443), ein VPN-Tunnel über Port 1194 wird aber trotzdem fehlschlagen.

Nun ist zwar 1194 die registrierte Portnummer für den Dienst OpenVPN, das heißt aber nicht, dass wir auch tatsächlich 1194 verwenden müssen. Bei der Installation von PiVPN können wir auch einen anderen Port angeben und wir können die Portnummer auch im Nachhinein in den Konfigurationsdateien ändern.

Aber welchen Port sollten wir anstelle von 1194 dann nehmen? Natürlich einen, der im betreffenden WLAN auch freigegeben ist – dummerweise kennen wir die Konfiguration fremder Netze nicht und müssen ein wenig ausprobieren. Man könnte auf den Gedanken kommen, Port 80 oder 443 zu verwenden. Das kann funktionieren, muss aber nicht. Denn die Ports 80 (http) und 443 (https) sind für TCP festgelegt, aber unser Tunnel arbeitet über UDP. Zielführend kann es also sein, zu schauen, welche wellknown ports typischerweise für UDP ins Internet geöffnet sein könnten. Ich habe hier ein paar Vorschläge:

  • 53 DNS (Namensauflösung); Das geht aber nicht, wenn wir am VPN-Server Pi-Hole installiert haben, denn Pi-Pole beansprucht Port 53 für sich selbst.
  • 123 NTP (Network Time Protocol); Das ist einen Versuch wert.
  • 194 IRC (ein Chatprotokoll)
  • 220 IMAP (also Mail)
  • 853 DNS over TLS (verschlüsselte Namensauflösung)
  • 995 Pop3S (verschlüsseltes Mail)

Was wirklich funktioniert muss in der Tat ausprobiert werden – und das macht man natürlich nur, wenn man ein spezielles Netz häufiger benutzen will und sich der Aufwand auch lohnt. Ich würde Tests mit den Ports 123 oder 220 beginnen – ohne Garantie auf Erfolg. Hier die Befehle um die Server und Clientkonfiguration nachträglich zu ändern:

Server: sudo nano /etc/openvpn/server.conf
Client: nano ovpns/MeinName.ovpn, wobei MeinName natürlich zu ersetzen ist.

In beiden Dateien ersetzen wir die Portnummer 1194 einfach durch den gewünschten Wert. Die Client-Datei muss dann natürlich am Smartphone in der VPN-App neu importiert werden und der Raspberry Pi neu gestartet.

Hab ich IPv4 oder IPv6 oder beides?

Dieser generellen Frage habe ich schon einen eigenen Artikel gewidmet. Was habe ich? IPv4, IPv6, oder beides? Wie kann man das konkret in Erfahrung bringen?

Unter Windows

Unter Windows holen wir uns eine DOS-Box (Eingabeaufforderung) mit Ausführen – cmd und Enter und dort geben wir folgendes Kommando ein:

ipconfig

Windows-IP-Konfiguration

Ethernet-Adapter LAN-Verbindung:

   Verbindungsspezifisches DNS-Suffix: fritz.box
   IPv6-Adresse. . . . . . . . . . . : 2001:a61:359d:5e01:759b:36fa:1d2f:6e3
   IPv6-Adresse. . . . . . . . . . . : fd00::759b:36fa:1d2f:6e3
   Temporäre IPv6-Adresse. . . . . . : 2001:a61:359d:5e01:d5e8:f0bd:47ef:edae
   Temporäre IPv6-Adresse. . . . . . : fd00::d5e8:f0bd:47ef:edae
   Verbindungslokale IPv6-Adresse  . : fe80::759b:36fa:1d2f:6e3%10
   IPv4-Adresse  . . . . . . . . . . : 192.168.0.202
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : fe80::2665:11ff:fea5:45f6%10
                                       192.168.0.1

Wie man sieht, hat dieser Windowsrechner sowohl IPv4 als auch IPv6.

Unter Linux

Bei Linux geht es vergleichbar, nur dass der Befehl nicht ipconfig heißt, sondern ifconfig:

ifconfig
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.167  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::ba27:ebff:feaa:f771  prefixlen 64  scopeid 0x20<link>
        inet6 2001:a61:35f4:d701:ba27:ebff:feaa:f771  prefixlen 64  scopeid 0x0<global>
        inet6 fd00::ba27:ebff:feaa:f771  prefixlen 64  scopeid 0x0<global>
        ether b8:27:eb:aa:f7:71  txqueuelen 1000  (Ethernet)
        RX packets 588928  bytes 387092545 (369.1 MiB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 503870  bytes 385487260 (367.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Die Ausgabe hab ich auf das relevante wlan0 Interface gekürzt. Dieser Raspberry Pi hat ebenfalls IPv4 und IPv6.

In diesem und im vorhergegangenen Fall ist damit schon mal klar, dass das interne Heimnetz auch IPv6-fähig ist. Schauen wir als nächstes auf die Außenseite des Routers.

Am Router

Das ist der Screenshot von einer Fritz!Box, bei anderen Routern oder Kabelboxen sieht das sicher ähnlich aus. Im Beispiel ein Dual Stack Anschluss mit vom Provider zugeteilter IPv4 und IPv6 Adresse.

IP Adressen am Smartphone

Am Smartphone

Auch unterwegs können wir am Smartphone feststellen, welche IP-Adressen anliegen. Wobei es hier ähnlich ist, wie bei Personal Computern. Moderne Geräte können immer IPv4 und IPv6. Beim Smartphone ist eher interessant, ob über das Zugangsnetz, also WLAN oder mobile Daten, auch IPv6 angeboten wird. Im Beispiel ist das der Fall – es gibt eine IPv4 und drei IPv6 Adressen. Bei Android (v8) findet man diese Informationen unter Einstellungen – Telefoninfo – Status und dann bei IP-Adresse.

Übers Web

Es gibt auch die Möglichkeit, über den Browser an die Information zu kommen, welche IP-Adressen man hat. Zum Beispiel über http://www.wieistmeineip.de/ipv6-test. Bei der Ausgabe ist allerdings zu beachten, dass die IPv4 Adresse die des vorgeschalteten Internet Routers ist und die IPv6 Adresse dem Endgerät gehört.

wieistmeineip.de

Kein IPv4 am Router – was nun?

Kunden, die von ihrem Internet Provider nur mit DS-Lite versorgt werden, haben in der Tat ein Problem mit einem VPN ins Heimnetz. DS-Lite bedeutet, dass der Internet Router vom Provider lediglich mit IPv6 versorgt wird und er keine öffentliche IPv4 Adresse bekommt.

In diesem Fall ist ein Tunnelaufbau nur möglich, wenn das Smartphone ebenfalls über IPv6 verfügt. Das ist im Sommer 2019 lediglich im Mobilfunknetz der Telekom (D1) der Fall. Vodafone (D2) und Telefonica (o2/e-plus) bieten noch kein IPv6. Frei zugängliche WLAN-Hotspots bieten in der Regel auch nur IPv4 und sehr selten zusätzlich IPv6.

Als Abhilfe liest man im Internet häufig den Vorschlag, einen Portmapper von IPv4 auf IPv6 zu verwenden. Das ist für Leute interessant, die selbst einen (virtuellen) Rootserver im Internet betreiben und sich dort eine entsprechende Software aufspielen können. Da sich dieser Portmapper im Internet befinden muss, bleibt andernfalls nur die Möglichkeit einen kommerziellen Dienst zu verwenden. Die sind dünn gesät, kosten Geld und stellen ihre Dienstleistung oft nur für TCP zur Verfügung und nicht für UDP. OpenVPN Server und Client müssten also zusätzlich auf TCP umgestellt werden (von mir nicht getestet).

Eine zweite Möglichkeit besteht darin, den eigenen Internet Provider zu beauftragen, neben der IPv6 zusätzlich auch eine IPv4 Adresse zur Verfügung zu stellen, also volles Dual Stack. Das war in der Vergangenheit oft kostenfrei, wenn man mit dem Provider gut verhandelt hat, heute verkaufen die Anbieter die IPv4-Option zunehmend als Extra für mehrere Euro pro Monat Aufpreis. Für denjenigen, der den VPN Tunnel nicht nur aus Sicherheitserwägungen für sein Smartphone braucht, sondern vielleicht beruflich unterwegs auf sein Heimnetz zugreifen muss, könnte das durchaus eine lohnenswerte Investition sein.

IPv6 WLAN um mal einen Dual Stack Tunnel auszuprobieren

Wer technisch interessiert ist und einen Dual Stack Tunnel (IPv4 und IPv6) ausprobieren möchte, aber kein Telekom Mobilfunk Kunde ist, dem empfehle ich, sich nach einem Freifunk WLAN Zugang für sein Smartphone umzusehen. Freifunk München bietet Dual Stack IP in seinen WLAN Hotspots und andere Freifunk Gruppen sicher auch. Die Zugänge sind – wie der Name schon sagt – frei und unverschlüsselt.

Interner Domänenname (bei einer Fritz!Box)

Innerhalb des eigenen Heimnetzwerks sind wir es gewohnt, ein anderes Gerät einfach per Namen ansprechen zu können. Zum Beispiel einen Raspberry Pi mit seinem Standardnamen raspberrypi. Das kann auch durch den VPN-Tunnel gut funktionieren – gerade, wenn wir ein richtig konfiguriertes Pi-Hole am VPN-Server installiert haben. Es kann aber auch schief gehen, wenn der Client, also das Smartphone, nicht in der Lage ist den Domänennamen des Heimnetzes zu erkennen.

Wie – werden einige sagen – mein Heimnetz hat einen eigenen Domänennamen? Ich hab doch nie einen vergeben oder konfiguriert? Machen wir einen Versuch, in dem wir an einem PC im Heimnetz (Linux, auch Raspberry Pi, oder Windows) eine umgekehrte Namensauflösung starten:

nslookup 192.168.0.166
Server:		127.0.0.1
Address:	127.0.0.1#53

166.0.168.192.in-addr.arpa	name = raspberrypi.fritz.box.

Wir geben nslookup also eine gültige, existierende IP-Adresse als Parameter, in der Hoffnung den Namen des zugehörigen Rechners zu erhalten. Und in der Tat, der lautet in dem Beispiel raspberrypi.fritz.box. Wobei fritz.box der Domänennamen ist, der auch gleich den Hinweis auf seine Herkunft gibt. Die Fritz!Box vergibt diesen Domänennamen und andere Internet Router werden das ähnlich machen.

Wenn also jetzt eine Namensauflösung vom Smartphone durch den VPN-Tunnel ins Heimnetz mit dem Rechnernamen raspberrypi misslingt, dann lautet mein Tipp, es einfach mit raspberrypi.fritz.box zu probieren. Oder mit dem entsprechenden Domänennamen, bei einem anderen Router.

IPv6 Tunnel funktioniert nicht im eigenen WLAN

Wir haben einen VPN-Tunnel basierend auf IPv6 erfolgreich konfiguriert und der funktioniert auch einwandfrei aus fremden Netzen heraus. Also zum Beispiel, wenn sich das Smartphone in einem Freifunk-WLAN befindet oder IPv6 über den Mobilfunkprovider bekommt. Nur wenn sich der VPN-Client im eigenen Heimnetz befindet, also in dem selben Netz, in dem auch der VPN-Server beheimatet ist, dann kann der Tunnel nicht aufgebaut werden. Diesen Fehlerfall können wir etwas näher untersuchen, in dem wir auf einem Linuxrechner im Heimnetz (aber nicht am VPN-Server) den öffentlichen Domänenamen unseres VPN-Servers abfragen. Der lautet im Beispiel jsonp.dedyn.io.

host jsonp.dedyn.io
;; connection timed out; no servers could be reached

Da scheint tatsächlich etwas nicht zu stimmen, denn der Name wird nicht aufgelöst. Versuchen wir folgendes:

host dedyn.io
dedyn.io has address 88.99.64.5
dedyn.io has IPv6 address 2a01:4f8:10a:1044:deec:642:ac10:80
dedyn.io mail is handled by 10 mail.a4a.de.

Das funktioniert seltsamerweise, obwohl ich hier nur die Hauptdomäne des DDNS-Anbieters abgefragt habe und nicht wie zuerst die individuelle Subdomäne für meinen VPN-Server.

Um das Rätsel aufzulösen, die Ursache dieses Verhaltens heißt DNS-Rebind-Schutz. Um DNS-Rebinding-Attacken zu verhindern, also aus Sicherheitserwägungen, blockt die Fritz!Box alle Namensauflösungen, deren Ziele im internen Netz liegen. Und genau das ist bei der dynamischen IPv6 Adresse des VPN-Servers der Fall. (Nicht aber bei IPv4 – dort verweist der DDNS-Eintrag ja auf die Fritz!Box selbst.)
Dieses Verhalten der Fritz!Box kann aber umgangen werden, indem wir dort eine Ausnahme für den DNS-Rebind-Schutz einrichten, unter Heimnetz – Netzwerk – Netzwerkeinstellungen und dann die Domäne (hier jsonp.dedyn.io) ganz unten bei Domainnamen-Ausnahmen eintragen.

DNS-Rebind-Schutz

Dann sieht die Namensauflösung folgendermaßen aus:

host jsonp.dedyn.io
jsonp.dedyn.io has IPv6 address 2001:a61:35e9:5701:ba27:ebff:feaa:f771

Und jetzt funktioniert auch der VPN-Client im eigenen Heimnetzwerk.

Fehler bei Pi-Hole Installation

Folgender Fehler könnte bei der Pi-Hole Installation auftreten – zumindest ist mir das passiert:

[✗] DNS resolution is currently unavailable

Danach geht keine Namensauflösung mehr am Raspberry Pi. Scheinbar hängt sich die Pi-Hole Installation in diesem Fall selbst vom Internet ab, was sehr ärgerlich ist. Zwei mögliche Workarounds kann ich anbieten:

  1. Die Installationsreihenfolge ändern, also zuerst Pi-Hole auf dem Raspberry Pi installieren und erst danach PiVPN. Interface tun0 danach von Hand hinzufügen.
  2. Bei der Installation von Pi-Hole darauf achten, dass als Interface auf keinen Fall tun0 gewählt wird, sondern das Interface, über das der RasPi am Netz hängt, also eth0 oder wlan0. Interface tun0 erst nach der Installation von Pi-Hole von Hand hinzufügen. Das ist meine empfohlene Vorgehensweise und so habe ich die Installation auch im Artikel über Pi-Hole beschrieben, damit der Fehler möglichst gar nicht erst auftritt.

Weitere Artikel in dieser Kategorie:

Schreiben Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.