Der Raspberry Pi als portables VPN-Gateway (Seite 3)

Geübte Netzwerker wie ich nehmen an dieser Stelle an, dass im nächsten Augenblick ein WLAN namens martin_unterwegs auf der WLAN-Liste der eigenen Geräte auftaucht, mit dem man sich unter Nutzung des vergebenen Passworts verbinden kann. Das WLAN tauchte tatsächlich auf, nur mit der Verbindung wollte es so recht nicht klappen. Damit begann eine fast anderthalbstündige Debugging-Session.

Des Rätsels Lösung war so offensichtlich wie kurios: NordVPN spendiert seinem Client wie beschrieben einen Killswitch, den es allerdings per Iptables implementiert. Ab Werk stellt NordVPN das System so ein, dass der Rechner für eingehenden Traffic weitgehend zugenagelt ist. Das lässt sich zwar mittels eines separaten Befehls auf der Kommandozeile zum Teil korrigieren, der die lokale Netzwerkerkennung aktiviert und freischaltet. Das setzt allerdings voraus, dass man einen administrativen Zugang zum RasPi hat, weil man ansonsten wieder den ungeliebten Fernseher für lokale Arbeiten nutzen muss. Obendrein funktioniert die lokale Freischaltung erst auf der Netzwerkebene, sodass sie für DHCP und BOOTP nicht funktioniert.

An dem beschriebenen administrativen Zugang scheiterte es obendrein. WLAN-Clients konnten sich mit dem Access-Point zwar verbinden, erhielten allerdings per DHCP keine IP-Adresse. Das lag daran, dass NordVPN eingehenden Traffic auf sämtlichen Interfaces abgestellt hatte. Das Aktivieren der Erkennung lokaler Netze löste das Problem, und das WLAN war funktionstüchtig. Eine dauerhafte Lösung bot das aber noch nicht, denn nach jedem Reboot nagelte NordVPN bis zum erneuten Aufruf des Kommandos für lokale Clients das mühsam in den Paketfilter gerissene Loch wieder zu.

Nützlicher Dispatcher

Intuitiv hätte ich an dieser Stelle zur post-up-Anweisung aus früheren Debian-Versionen gegriffen. Die würde, sobald sich der Status einer Netzwerkschnittstelle ändert – etwa, weil das WLAN gestartet wird – die nötigen NordVPN-Befehle ausführen und die Kommunikation so freigeben. Eine ähnliche Einstellung bietet NetworkManager auch, und zwar in Form eines Dispatcher-Shell-Skripts unter /etc/NetworkManager/dispatcher.d/.

Aber Vorsicht: Bei einem Ereignis im Netzwerk ruft NetworkManager jedes Mal sämtliche Skripte auf. Es obliegt mithin dem Autor eines Dispatcher-Skripts, sicherzustellen, dass die enthaltenen Befehle nur dann greifen, wenn das Ereignis auf der richtigen Netzwerkschnittstelle (in unserem Fall wlan0) stattfindet. Das Beispiel aus Listing 2 vermittelt einen ersten Eindruck davon, wie so etwas aussehen kann.

#!/usr/bin/env bash
interface=$1
event=$2
if [[ $interface != "wlan0" ]] || [[ $event != "up" ]]; then
  return 0
fi
# place your commands below this line
nordvpn set killswitch off
nordvpn set firewall off
nordvpn set lan-discovery enable
nordvpn set killswitch on
nordvpn set firewall on
sudo iptables -t nat -A POSTROUTING -o nordlynx -j MASQUERADE
sudo iptables -A FORWARD -i nordlynx -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o nordlynx -j ACCEPT

Das gezeigte Dispatcher-Skript leistet noch eine weitere wichtige Aufgabe: Es aktiviert Masquerading für das NordVPN-Interface, damit Clients aus dem WLAN heraus durch NordVPN hindurch auf das Internet zugreifen können. Damit das auch wirklich klappt, muss zudem die Systemcontrol-Variable für die Weiterleitung von IPv4-Paketen aktiv sein. Das Kommando aus Listing 3 erledigt das Reboot-sicher.

$ echo -e 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf && sysctl -a

Die Arbeit auf dem Raspberry Pi ist damit abgeschlossen, das Gerät arbeitet nun als portables VPN-Gateway. Sicherheitshalber und während die Ethernet-Verbindung mit meinem Windows-Notebook noch hergestellt war, führte ich mittels reboot einen Neustart herbei. Im Anschluss stellte ich sicher, dass der RasPi automatisch hochfährt, NordVPN eine Verbindung herstellen kann und DHCP und BOOTP im WLAN weiterhin funktionieren. Selbst bei einer im Augenblick scheinbar perfekt funktionierenden Konfiguration sollten Sie diesen Test sicherheitshalber vornehmen.

Der Rest war Schema F: Das gebaute Konstrukt verhält sich etwa einem Google Chromecast gegenüber exakt so wie jeder andere Access Point auch – wenn man davon absieht, dass der RasPi im Augenblick nur das unsichere WPA-PSK-Protokoll mit AES-Verschlüsselung unterstützt. Hier hege ich die Hoffnung, dass ein RasPi 5 besser performt, sollte er denn irgendwann einmal realistisch zu bekommen sein.

So oder so war es problemlos möglich, den vor Ort ebenfalls beschafften Google Chromecast an den Fernseher anzuschließen und mittels Google-Home-Anwendung zu konfigurieren. Haben Sie bereits einen Account für Google Home, sollten Sie darauf achten, darin für den RasPi einen komplett eigenen Standort anzulegen. Solange ich versuchte, den RasPi in das bestehende Netzwerk home zu integrieren, erschienen beim Herstellen der Verbindung etliche eigenartige Fehlermeldungen.

Läuft der Chromecast einmal, lassen sich Anwendungen wie Waipu, Netflix oder Amazon Prime installieren und durch das WLAN hindurch per VPN betreiben. Ein weiterer Vorteil dieser Lösung: Man kann auch andere portable Geräte mit dem RasPi-Access-Point verbinden und so gegebenenfalls einer lausigen WLAN-Verbindung im Hotel entgehen.

Fazit

Geht nicht gibt’s nicht: Das gilt 2024 auch für TV- und Medienkonsum von Streaming-Diensten weitab der Heimat und der Europäischen Union. Die skizzierte Lösung leistete im Urlaub über viele Tage treue Dienste und ermöglichte sogar den Konsum der einschlägigen Streaming-Dienste mit 1080p- und 4k-Auflösung (Abbildung 5). Mehr kann man kaum verlangen, zumal auch die meisten Fernseher in Hotels nicht mehr Leistung bieten.

Abbildung 5: Erfolg: Hier zwar etwas überbelichtet wegen zu wenig Licht im Hotelzimmer, aber dennoch gut erkennbar – deutsches Fernsehen im Hotel in Ägypten in hervorragender Qualität.

Freilich hängt das beschriebene Prozedere stark davon ab, ob der HDMI-Anschluss des Hotelfernsehers zugänglich ist. Manche Hotels sind dazu übergegangen, die Geräte in Wandvorsprüngen zu verbauen, sodass sich die Ports kaum erreichen lassen. Andere Hotels verbieten über die Konfiguration des Fernsehers softwareseitig den Zugriff auf die HDMI-Ports. Im Gros der Hotels, in denen ich bisher zu Gast war, war der Anschluss von Geräten an den Fernseher jedoch kein Problem. Das Gespann aus Mobilfunkmodem, RasPi und Google Chromecast jedenfalls hat sich bewährt: Es ist klein, leicht und mithin gut transportabel, benötigt keine aktiven Lüfter und hat in Sachen Ressourcen trotzdem noch genug Luft zum Atmen.