Raspberry Pi VPN – Teil 11: Netzwerkdiagramme

Helmut 1. September 2019 0 Kommentare

Nach den bisherigen 10 Artikeln ist das Thema Virtual Private Network (VPN) für das Smartphone an sich umfangreich genug beleuchtet und eigentlich abgeschlossen. Aber nicht jeder beschäftigt sich viel mit Netzwerktechnik und deshalb kann es vielleicht nicht schaden, noch einen Erklär-Beitrag nachzuschieben. Hier kommt jetzt nichts grundlegend neues, ich werde nur einige Netzthemen aus den vorangegangenen Artikeln noch einmal aufgreifen und anhand einiger Netzwerk-Schaubilder vertiefen. Dabei geht es um ein paar grundlegende Prinzipien, wie Dynamisches DNS, Freigabe am Router und die Wirkungsweise eines VPN-Tunnels und von Pi-Hole. Dem Einen oder Anderen ist vielleicht auch noch nicht ganz klar, wie genau man vom Smartphone über ein VPN ins Internet kommt. Also hier etwas Netzwerktechnik in Text und Bild.

Überblick über Netze und Geräte

Verschaffen wir uns zuerst einen Überblick. Schwarz gezeichnet sind die Netze, davon gibt es auf dem Bild zwei, einmal das Internet mitte-links und das private LAN/WAN zuhause. Das Internet habe ich noch einmal unterteilt in die jeweiligen Zugangsnetze, also die Netze der Provider, die uns den Zugang ins Internet ermöglichen. Das ist rechts auf der Seite des Heimnetzwerks meistens ein DSL-Provider oder Kabelnetzanbieter, der oft auch den Router zur Verfügung stellt. Auf Seiten des Smartphones gibt es (zumindest) zwei Möglichkeiten: Wir können über das Mobilfunknetz ins Internet (oft auf Basis eines bezahlten Monatskontingents), oder über einen WLAN-Hotspot (häufig kostenlos und oft auch nicht verschlüsselt).

Blau sind dann die Geräte, die ich hier nur als Rahmen gezeichnet habe, damit darin die Software platziert werden kann. Das sind von links nach rechts, das Smartphone, der Internet Router, der das interne Heimnetz mit dem Internet-Provider verbindet und der Raspberry Pi, der zu einem VPN-Server ausgebaut werden soll. Daneben gibt es in diesem Heimnetz natürlich auch noch weitere leitungsgebundene oder drahtlose Geräte. Zumindest einen PC brauchen wir, um per SSH den Raspberry Pi steuern zu können.

Dynamisches DNS

Sinn und Zweck eines virtuellen privaten Netzwerks ist es, vom Smartphone einen verschlüsselten Tunnel durch das Internet ins heimische Netz aufzubauen. Erst von dort aus surfen wir dann im Internet und können Pi-Hole verwenden, um wirkungsvoll gegen Tracking vorzugehen. Aber wie kommen wir vom Smartphone ins Heimnetz? Wir brauchen die öffentliche IP-Adresse unseres VPN-Servers (bei IPv6) beziehungsweise die öffentliche IP-Adresse unseres Internet Routers (bei IPv4). Beides mit der kleinen Schikane, dass sich diese Adressen (in der Regel) täglich ändern. Öffentliche Adresse meint hier eine IP-Adresse, die im Internet geroutet wird, global einmalig ist und von überall aus dem Internet erreicht werden kann. (Im Unterschied zu einer privaten IP-Adresse, die nur in einem abgeschlossenen Netz gültig ist und in anderen Netzen auch vorkommen kann.)

Abhilfe für das Problem wechselnder IP-Adressen bietet dynamisches DNS (Domain Name System) und das funktioniert so:

Bei IPv4 gibt es nach außen hin zum Internet immer nur die IP-Adresse des Internet Routers. Adressen von Geräten im internen Netz werden auf diese Adresse übersetzt (Network Address Translation NAT). Naturgemäß kennt der Router seine öffentliche Adresse als erster, sobald er vom Provider eine neue zugeordnet bekommt und kann diese Information weitergeben. Dazu brauchen wir eine Stelle im Internet, wo die Adresse periodisch hinterlegt werden kann. Das ist ein DDNS-Server und so etwas bieten diverse Dienstleister (oft kostenlos) an. Man muss dort ein Konto eröffnen und einen Domänennamen anlegen. Der DDNS-Client im Internet Router liefert also die eigene IP-Adresse – so bald sich diese ändert – an den DDNS-Server aus. Das ist der magentafarbene Pfeil.

Der VPN Client – das ist eine App auf dem Smartphone – kann sich unter dem (mit dem Dienstleister vereinbarten) Domänennamen dann jederzeit, die gerade aktuelle IP-Adresse vom DDNS-Server abrufen (orangefarbener Pfeil).

Bei IPv6 gibt es kein NAT – alle Geräte haben auch eine global gültige Internet Adresse, bei der ändert sich periodisch nur der Präfix, das ist die erste Hälfte der Adresse. Die Meldung an den DDNS-Server kann wie bei IPv4 durch den Internet Router geschehen, wenn dieser das beherrscht. Eine Fritz!Box kann das zum Beispiel über MyFRITZ!. Die gebräuchlichere Methode ist es allerdings, dass das Gerät, also in diesem Fall der Raspberry Pi seine IP-Adresse selbst an den DDNS-Server meldet.

Dazu installiert man am Raspberry Pi eine DDNS-Forwarder Software, die das übernimmt. Der magentafarbene Pfeil geht also nicht vom Router aus, sondern vom Raspberry Pi. Die Abfrage des DDNS-Servers durch den VPN Client am Smartphone (orangefarbener Pfeil) funktioniert aber auf die gleiche Weise, nur dass das Ergebnis eine IPv6 Adresse ist.

Aufbau des VPN-Tunnels

Der VPN-Client am Smartphone kennt nun die IP-Adresse des Internet Routers oder des VPN-Servers im Home Netz oder beides. Aber welche IP-Adresse wird er für einen Verbindungsaufbau verwenden – IPv4 oder IPv6? Da müssen wir ein paar Fälle unterscheiden:

Fall 1) Der Internet Router kann nur IPv6: In diesem Fall muss der VPN-Client auch IPv6 verwenden. Wenn das Zugangsnetz, in dem sich das Smartphone befindet (also WLAN oder mobiles Internet), keine IPv6 Adresse zur Verfügung stellt, dann ist kein Tunnelaufbau möglich. Dieser Fall ist im Sommer 2019 gar nicht mal unwahrscheinlich.
Fall 2) Der Internet Router kann nur IPv4: Dann muss der VPN-Client auch IPv4 verwenden. Aber dieser Fall kommt in der Praxis eigentlich nicht vor.
Fall 3) Der Internet Router kann Dual-Stack, also IPv4 und IPv6: Jetzt kommt es auf den Client an, bzw. darauf, welche IP-Stacks er vom aktuellen Zugangs-Provider angeboten bekommt:
- Fall 3a) Das Smartphone hat nur IPv6 zur Verfügung: Dann wird der Tunnel gezwungenermaßen über IPv6 laufen. Auch dieser Fall ist eher unwahrscheinlich.
- Fall 3b) Das Smartphone hat nur IPv4 zur Verfügung: Dann wird der VPN-Client die Verbindung auch über IPv4 aufbauen.
- Fall 3c) Das Smartphone hat sowohl IPv4 als auch IPv6 zur Verfügung: Damit haben wir Dual Stack auf beiden Seiten und nur in diesen Fall hat der Client die Wahl, ob er IPv4 oder IPv6 nimmt. Erfahrungsgemäß wird bei einer kurzen Unterbrechung mit dem selben IP-Protokoll weiter gemacht, das vorher schon in Verwendung war. Nach einer kompletten Trennung wechselt der Client aber gerne das Protokoll. Das Verhalten ist aber immer von der jeweiligen Client App abhängig.

Aber wie funktioniert nun der Verbindungsaufbau für den VPN-Tunnel?

Die Initiative geht immer vom VPN-Client, also dem Smartphone aus. Der Client hat im vorhergehenden Schritt die IP-Adresse(n) des VPN-Servers ermittelt und ggf. entschieden, welchen IP-Stack er verwenden will. Der VPN-Client schickt nun eine Verbindungsanfrage an die ermittelte IP-Adresse (magentafarbener Pfeil). Und er wird niemals eine Antwort erhalten. Warum ist das so? Weil alle Internet Router als Firewall das interne Netz vor einem Eindringen aus dem Internet schützen. So lange wir den Internet Router nicht explizit dazu beauftragen, jemand von außen ins Heimnetz zu lassen wird er das auch nicht machen. Das Schlagwort heißt Freigabe oder auch Portfreigabe, weil sinnvollerweise nur ein spezieller Port (1194 bei VPN) freigeschaltet wird.

Der Freigabemechanismus unterscheidet sich ein wenig zwischen den beiden IP-Protokollstacks. Bei IPv6 weisen wir den Router einfach an, dass er Anfragen für die globale IP-Adresse des VPN-Servers für den Port 1194 passieren lassen soll. Bei IPv4 sind alle internen Adressen privat, hier kommt die Anfrage an die Adresse des Routers selbst und wenn die den besagten Port 1194 betrifft, dann soll der Router eine Adressübersetzung (NAT) auf die interne IP-Adresse des VPN-Servers vornehmen. Bei Dual Stack richtet man sinnvollerweise beide Freigaben parallel ein.

Ist am Internet Router also eine entsprechende Freigabe konfiguriert, dann wird der Router die Anfrage nicht blockieren, sondern an den VPN-Server weiterleiten (orangefarbener Pfeil).

Was folgt ist ein umfangreicher Datenaustausch zwischen VPN-Server und Client. Dabei authentifiziert sich der Client gegenüber dem Server, der Server prüft, ob er den Client kennt und beide richten eine verschlüsselte Tunnelverbindung ein. Der Client bekommt dabei vom Server eine eigene Tunnel-IP-Adresse vergeben (immer IPv4: 10.8.0.2 oder eine folgende Adresse, wobei der Server selbst im Tunnel immer die Adresse 10.8.0.1 nutzt). Und schließlich kann der Server dem Client noch ein paar Konfigurationsparameter schicken, wie zum Beispiel die Adresse des zu verwendenden DNS-Servers. Damit steht die Tunnelverbindung (im Schaubild grün) und der VPN-Client leitet in Folge jeglichen Netzwerkverkehr in den Tunnel und nicht mehr direkt ins Internet.

Der lange Weg ins Internet

Das bedeutet natürlich auch, dass jeglicher Verkehr vom Smartphone ins Internet einen etwas umständlichen Weg über das heimische Netz zurück legt und dabei zweimal über den Internet Router und die DSL-Anbindung läuft. Schauen wir uns das genauer an:

Vor dem eigentlichen Surfen im Internet steht die Namensauflösung. Der VPN-Client hat beim Tunnelaufbau vom Server die IP-Adresse des zuständigen DNS-Servers bekommen. Das ist – so lange wir noch nicht Pi-Hole einsetzen – der eigene Internet Router, der durch den Tunnel angesprochen wird und der sich seinerseits wieder bei DNS-Servern im Internet mit Informationen versorgt (magentafarbene Linie).

Wenn die IP-Adresse des gewünschten Web-Angebots dann bekannt ist, läuft die Verbindung vom Browser des Smartphones über den VPN-Client, durch den VPN-Tunnel zum VPN-Server und der leitet sie erst ins Internet zum gewünschten Web-Server. Und auf dem umgekehrten Weg gelangt die Webseite zum Browser zurück.

Zur Klarheit noch ein kurzes Wort zur Sinnhaftigkeit dieses Unterfangens. Denn erst mal klingt das sehr aufwändig bei keinem sichtbaren Mehrwert. Der Mehrwert beschränkt sich im Moment tatsächlich lediglich darauf, dass der Internetverkehr des Smartphones in einem fremden ungeschützten WLAN verschlüsselt und damit abhörsicher läuft und sich kein Dritter in diese Verbindung einschalten kann – auch nicht der Betreiber dieses WLAN Hotspots. Und im mobilen Internet gilt das analog. Der Weg aus dem heimischen Netz ins Internet ist aber genau so ungeschützt, wie wenn wir mit dem Smartphone im eigenen WLAN beheimatet wären.

Ein kleines Zuckerl gibt es aber zusätzlich: Das Smartphone ist auch unterwegs durch den Tunnel immer Teilnehmer im Heimnetzwerk. Wenn sich dort also ein Fileserver oder ein anderer Raspberry Pi befindet, dann können wir auf diese Geräte aus der Ferne ebenso zugreifen als wären wir daheim.

VPN-Tunnel in Kombination mit Pi-Hole

Das große Plus an Sicherheit kommt aber erst mit dem zusätzlichen Einsatz von Pi-Hole auf dem VPN-Server. Denn Pi-Hole ist in der Lage, Trackingdienste (und auch Werbung) zu blockieren. Und das sowohl beim Surfen im Internet und auch was die (heimliche) Kommunikation von Smartphone-Apps nach draußen angeht.

Im Beispiel will die App 1 am Smartphone mit dem Internet kommunizieren. Jegliche Kommunikation läuft durch den Tunnel – wie wir eben schon gesehen haben – und landet auf dem VPN-Server (magentafarbener Pfeil). Auf dem ist nun auch die Software Pi-Hole installiert und OpenVPN ist so konfiguriert, dass DNS-Anfragen vom Client nicht mehr an den Internet Router weitergegeben werden, sondern an Pi-Hole (orangefarbene Pfeile). Somit kann Pi-Hole jede Anfrage nach Namensauflösung erkennen und entscheiden, ob sie an den Internet Router weitergeleitet oder unterdrückt wird. Mit einer Blacklist ausgestattet ist Pi-Hole ein mächtiges Werkzeug zum Blockieren von Tracking und Werbung. Der Internetverkehr selbst – ohne DNS – läuft unverändert an Pi-Hole vorbei (dunkelgrüner Pfeil). Aber Tracking-Server können nicht kontaktiert werden, da deren Internet-Adresse nicht aufgelöst werden konnte. Pi-Hole selbst wird über eine Weboberfläche gesteuert, auf die zum Beispiel der PC im LAN per Browser zugreifen kann. Darüber lassen sich eigene Black- und Whitelists pflegen.

Wireshark

Das letzte Schaubild zeigt nun, wie wir Wireshark einsetzen können, um den Datenverkehr aufzuzeichnen, der durch den Tunnel läuft.

Die Software Wireshark ist auf einem normalen PC installiert und nutzt zur Datenaufzeichnung am Raspberry Pi ein Remote-Probe Programm namens tcpdump. Das monitort die Schnittstelle tun0, also das Tunnelinterface am VPN-Server. Wireshark und tcpdump kommunizieren über SSH (gelber Pfeil). Wie man sieht, laufen sowohl die dunkelgrüne, als auch die orange Linie zwangsweise über tcpdump, dadurch lässt sich alles mitschneiden, was ins Netz oder zu Pi-Hole geht, bzw. von dort zurück kommt.

Weitere Artikel in dieser Kategorie: