Der OpenVPN-Betriebsmodus Bridging bietet gegenüber dem Routing einige Vorteile. Allerdings verursacht er einen gewissen Konfigurationsaufwand.

Um von außen, beispielsweise von unterwegs, mit dem Notebook auf sein Heimnetz hinter dem Internet-Router nahezu uneingeschränkt zuzugreifen, bedient man sich vorzugsweise eines VPN-Tunnels. Viele marktübliche DSL-, Kabel- oder LTE-Internet-Router für den SOHO-Anwendungsbereich lassen sich daher auch als VPN-Endpunkt einrichten. Bei den meisten beschränken sich die Konfigurationsmöglichkeiten jedoch aufs Nötigste, worunter die Flexibilität leidet.

Darüber hinaus gibt es zu den Anwendungen meist keinen einsehbaren Quellcode – ein echtes Manko an Transparenz. Deswegen empfiehlt es sich, den VPN-Endpunkt hinter den Router auf einen eigenen Linux-Server zu legen. OpenVPN gewährt zum einen die volle Kontrolle und zum anderen ein weites Feld an Gestaltungsmöglichkeiten.

Vorüberlegungen

Eine der grundlegenden Fragen, denen man sich bei OpenVPN schon eingangs stellen sollte, lautet: Routing oder Bridging? Bei Routing verbindet die Software das Netzwerk auf der OSI-Protokollebene 3, also der IP-Adressen-Ebene – die vorherrschende VPN-Anwendung.

In manchen Fällen führt das aber nicht zum Ziel. Dann gilt es, noch eine Ebene tiefer zu gehen und die Netzwerke schon auf der OSI-Protokollebene 2 zu verbinden, also eine Netzwerkbrücke auf Basis der MAC-Adressen aufzubauen. Diese VPN-Form gilt als weniger leistungsfähig und erfordert einen höheren Konfigurationsaufwand. Wann der Einsatz von Bridging sinnvoll ist und wie Sie es realisieren, klären wir im Folgenden. Im Test kommt serverseitig das Debian-System Raspberry Pi OS zum Einsatz. Auf anderen Linux-Systemen kommt es mitunter zu Abweichungen in Bezug auf einzelne Konfigurationsdateien oder verwendete Programme.

An dieser Stelle sollte schon geklärt sein, warum man einen VPN-Zugang in sein Heimnetz gelegt haben will. Fokussieren wir uns also auf die Frage, in welchen Anwendungsfällen Sie einem VPN-Tunnel mit Netzwerkbrücke gegenüber einem mit einem Netzwerk-Router den Vorzug geben sollten.

Für den Autor waren zwei Gründe ausschlaggebend, ein eigenes VPN aufzusetzen. Zum einen verhinderten die fehlenden Einstellmöglichkeiten des Internet-Routers des Providers, den VPN-Endpunkt im Routing-Modus hinter den Router im Heimnetz einfügen zu können. Dazu hätte sich der Router mit ein paar gesonderten Netzwerkrouten für das VPN ausstatten lassen müssen, was nicht der Fall war.

Zum anderen sollten sich weitere, im Heimnetz im Standby schlummernde Rechner per Wake-on-LAN (WoL) starten lassen, und zwar per WoL-Anwendung am Notebook von unterwegs genauso, wie direkt im Heimnetz. Das sollte aber nicht umständlich und potenziell unsicher erfolgen, etwa per Login auf den Internet-Router oder auf den zentralen Linux-Server im Heimnetz. Das konnte aber nur klappen, wenn nicht ein Router am Ende des VPN-Tunnels auf OSI-Ebene 2 das WoL-Paket des entfernten Senders am Weitertransport zum lokalen Empfänger hindert.

Grundlagen

Für diesen Artikel dient ein Raspberry Pi 3B+ mit einem halbwegs aktuellen Betriebssystem [1] als VPN-Server und damit als Endpunkt im Heimnetz. Er ist per LAN-Kabel direkt mit dem Router verbunden, denn die nachfolgend beschriebene Konfiguration der Netzwerkbrücke lässt sich zwar via Ethernet anwenden, nicht aber via WLAN.

Abbildung 1 zeigt das Heimnetz. Darin dient aus Netzwerksicht der Linux-Server ausschließlich als VPN-Server. Alle anderen netzwerkrelevanten Aufgaben wie das Vergeben der lokalen IP-Adressen durch einen DHCP-Server verbleiben beim Router. Der über das Internet per VPN verbundene mobile VPN-Client erscheint im Heimnetzwerk genauso wie jedes andere lokale Ethernet-Gerät.

Abbildung 1: Das Heimnetz mit dem Router, dem VPN-Server und dem per VPN verbundenen Client.

Auf dem Server installieren Sie zunächst die Pakete speziell für das VPN notwendigen Werkzeuge sowie einige weitere Tools zum Einrichten des Netzwerks (Listing 1). Das Paket easy-rsa benötigen Sie nicht zwingend, es dient zum Erzeugen der für die in OpenVPN erforderlichen TLS/SSL-Schlüssel sowie der Server- und Client-Zertifikate. Diese lassen sich gegebenenfalls auf anderen Rechnern erzeugen – das wäre unter Sicherheitsaspekten sogar die bessere Alternative. Einen Einblick in das Thema bieten der Artikel “Abgedichtet” aus LinuxUser 01/2019 [2] und das OpenVPN-Wiki [3].

$ sudo apt install openvpn openvpn-blacklist iproute2 easy-rsa

Die Netzwerkbrücke

Der eigentliche Aufbau der Netzwerkbrücke am VPN-Server erfolgt mit dem Skript aus Listing 2. Es legt den Namen (hier br0) und die MAC-Adresse der Brücke fest und aktiviert sie. Es aktiviert zudem das physikalische Netzwerkgerät (hier eth0) und bindet es an die Brücke. Dadurch läuft jeglicher Verkehr auf OSI-Ebene 2, der an dieses physikalische Netzwerkgerät geht, auch auf die Brücke, und umgekehrt. Einen guten Überblick über die hier verwendeten Befehle des Werkzeugkastens iproute2 finden Sie im Arch-Linux-Wiki [4].

#!/bin/sh
# /usr/lib/dhcpcd/bridge_setup
# Set up the bridge device br0
ip link add name br0 \
   address 00:11:22:33:44:55 \
   type bridge
ip link set br0 up promisc on
# Tie the ethernet device eth0 to
# it just before the dhcp client
# is started
ip link set eth0 up promisc on
ip link set eth0 master br0

Der Name und die MAC-Adresse lassen sich zwar frei wählen, müssen sich aber von schon existierenden unterscheiden. Der Aufruf ip link show gibt einen Überblick aller bereits verfügbaren Netzwerkgeräte und listet somit auch den Namen des tatsächlich vorhandenen physikalischen Netzwerkgeräts auf, den Sie dann in Listing 2 verwenden. Sie speichern das Skript unter /usr/lib/dhcpcd/ als bridge_setup. Nur Root darf darauf zugreifen, zudem benötigt das Skript Ausführungsrechte (Listing 3).

$ sudo chown root:root /usr/lib/dhcpcd/bridge_setup
$ sudo chmod a+x /usr/lib/dhcpcd/bridge_setup

Im nächsten Schritt geht es darum, den Aufbau der Netzwerkbrücke in den Boot-Prozess des Servers einzubinden, und zwar bevor der DHCP-Client am Linux-VPN-Server seine IP-Adresse vom Router bezieht. Dazu erweitern Sie den Systemd-Daemon für den DHCP-Client um den Aufruf des gerade erstellten Skripts (Listing 4). Sie finden die entsprechende Konfigurationsdatei im Verzeichnis /usr/lib/systemd/system/.

[Unit]
Description=dhcpcd on all interfaces
Wants=network.target
Before=network.target
[Service]
Type=forking
PIDFile=/run/dhcpcd.pid
ExecStartPre=/usr/lib/dhcpcd/bridge_setup
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -b
ExecStop=/sbin/dhcpcd -x
[Install]
WantedBy=multi-user.target
Alias=dhcpcd5.service

Zu guter Letzt schließen Sie am VPN-Server in der Konfigurationsdatei des DHCP-Clients das an die Brücke gebundene physikalische Netzwerkgerät vom Bezug einer eigenen IP-Adresse aus und binden die Netzwerkbrücke sowie andere Netzwerkgeräte explizit ein (Listing 5).

[...]
denyinterfaces eth0
allowinterfaces br0 wlan0
[...]

Möchten Sie diese Konfiguration manuell und direkt auf der Konsole aktivieren, laden und starten Sie den geänderten Systemd-Daemon neu (Listing 6). Alternativ rebooten Sie den Server.

$ sudo systemctl daemon-reload
$ sudo systemctl restart dhcpcd.service

Der OpenVPN-Server

Listing 7 zeigt das Konfigurationsskript des VPNs am Server. Es gehört ins Verzeichnis /etc/openvpn/. Drei Einstellungen spielen darin eine besondere Rolle. Erstens handelt es sich um einen Server im Brückenmodus, zweitens wird für das VPN ein TAP-Netzwerkgerät mit dem Namen tapX erzeugt. Zu guter Letzt soll beim Aufbau des VPNs das Skript /etc/openvpn/up-tap2bridge.sh ausgeführt werden.

# -- openvpn mode, port, protocol
server-bridge
port 1194
proto udp
# -- network device
dev tap
script-security 2
up /etc/openvpn/up-tap2bridge.sh
# -- more configurations
keepalive 10 60
compress lz4
push "compress lz4"
push "route-delay 5"
push "redirect-gateway def1"
persist-key
persist-tun
# -- status and logging
verb 3
status /var/log/bridgeVPN-status.log
log    /var/log/bridgeVPN.log
# -- certificates, keys, etc ...
crl-verify /etc/openvpn/keys/certificate-revocation-list.pem
ca /etc/openvpn/keys/CA-X.509-Zertifikat.crt
cert /etc/openvpn/keys/VPN-Server-X.509-Zertifikat.crt
key /etc/openvpn/keys/VPN-Server-Schlüssel.key
dh /etc/openvpn/keys/VPN-Server-Diffie-Hellman-Parameter.pem

Das Skript aus Listing 8 speichern Sie im Verzeichnis /etc/openvpn/ und übergeben ihm den tatsächlichen Namen tapX des TAP-Geräts als Parameter. Die Kommandos binden das VPN bei Aktivierung an die Netzwerkbrücke. Das schließt die Brücke br0 zwischen dem physikalischen Netz und dem VPN. Dadurch fließt jeglicher Verkehr aus dem VPN über die Brücke ins lokale Ethernet und umgekehrt. Auch dieses Skript müssen Sie wieder ausführbar machen.

#!/bin/sh
ip link set "$1" up promisc on
ip link set "$1" master br0

Sie aktivieren den VPN-Server nun mit dem Aufruf sudo systemctl start openvpn@bridgeVPN-server.service. Damit sich VPN-Clients via Internet mit dem VPN-Server im Heimnetz verbinden können, müssen Sie den von OpenVPN verwendeten Port 1194 noch im Router auf der Internet-Seite zum VPN-Server freigeben und weiterleiten (Abbildung 2).

Abbildung 2: Im Internet-Router gilt es, das Port Forwarding für VPN entsprechend einzurichten.

Der VPN-Client

In unserem Beispiel kam als Client ein Notebook unter Ubuntu zum Einsatz. Wie auf dem VPN-Server müssen Sie auch auf dem Client zunächst das Paket openvpn installieren.

Die Konfigurationsdatei für den Client (Listing 9) legen Sie im Verzeichnis /etc/openvpn/ ab. Sie unterscheidet sich vor allem in vier Punkten vom Server: Als VPN-Modus dient client (Zeile 2). Die Anweisung lladdr (Zeile 5) fixiert die MAC-Adresse des TAP-Netzwerkgeräts, sodass der DHCP-Server des Heimnetzwerks dem Client bei jeder Neuverbindung dieselbe IP-Adresse zuweist. Die letzten zwei Unterschiede betreffen die zwei Skripte zum Auf- und Abbau der VPN-Verbindung (Zeilen 8 und 10).

# -- openvpn mode
client
# -- network device
dev tap
lladdr 12:de:ad:af:fe:34
# -- (de-)activate DHCP Client
script-security 2
up /etc/openvpn/up-dhcp.sh
down-pre
down /etc/openvpn/down-dhcp.sh
# -- contacting the server
remote 1194 udp
resolv-retry infinite
remote-cert-tls server
# -- more configurations
nobind
compress
persist-key
persist-tun
# -- status and logging
verb 3
log /var/log/bridgeVPN.log
# -- certificates, keys, etc ...
auth-nocache
ca /etc/openvpn/keys/CA-X.509-Zertifikat.crt
cert /etc/openvpn/keys/VPN-Client-X.509-Zertifikat.crt
key /etc/openvpn/keys/VPN-Client-Schlüssel.key

Dabei wird beim Verbindungsaufbau dem Skript /etc/openvpn/up-dhcp.sh (Listing 10) der Name des TAP-Netzwerkgeräts übergeben, für das dann ein eigener DHCP-Client-Daemon startet. Er kontaktiert mit der MAC-Adresse des TAP-Geräts durch den VPN-Tunnel den DHCP-Server des Heimnetzes und bekommt als Antwort eine IP-Adresse und andere Netzwerkinformationen zugewiesen.

#!/bin/sh
dhclient -nw "$1"

Beim Abbau der VPN-Verbindung durch das Skript aus Listing 11 – es gehört ebenfalls ins Verzeichnis /etc/openvpn/ – wird nur der DHCP-Client-Daemon für das TAP-Gerät des VPN-Clients gestoppt. DHCP-Client-Daemons anderer Netzwerkgeräte, etwa für das WLAN, müssen davon unberührt bleiben.

#!/bin/sh
dhclient -x "$1"

Üblicherweise bieten Linux-Desktops im Systemabschnitt der Kontrollleiste die Möglichkeit, Netzwerk- und VPN-Verbindungen komfortabel per Mausklick zu aktivieren. Allerdings gibt es für den verbreiteten NetworkManager keine Standardkonfiguration für diese Art von VPNs. Deswegen müssen Sie auf die Kommandozeile zurückgreifen, um auf dem Client die VPN-Verbindung anzustoßen (Listing 12, erste Zeile) und später wieder abzubauen (letzte Zeile).

$ sudo systemctl start openvpn@bridgeVPN-client.service
[...]
$ sudo systemctl stop openvpn@bridgeVPN-client.service

Die drei Phasen des VPN-Starts am Server sowie den Auf- und Abbau der Verbindung durch den Client können Sie dann über den Befehl sudo tail -f /var/log/bridgeVPN.log in der Log-Datei des VPN-Servers verfolgen (Listing 13). Läuft alles korrekt, sollte sich nun via VPN beispielsweise die Webseite des Routers im Heimnetz ansteuern lassen (Abbildung 3).

Abbildung 3: Nach dem erfolgreichen Etablieren der VPN-Verbindung lässt sich vom Client aus die Webseite des Internet-Routers im Heimnetz aufrufen.

Sun Nov 20 10:32:13 2022 Diffie-Hellman initialized with 2048 bit key
Sun Nov 20 10:32:13 2022 TUN/TAP device tap0 opened
Sun Nov 20 10:32:13 2022 TUN/TAP TX queue length set to 100
Sun Nov 20 10:32:13 2022 /etc/openvpn/up-tap2bridge.sh tap0 1500 1654   init
Sun Nov 20 10:32:13 2022 Could not determine IPv4/IPv6 protocol. Using AF_INET
Sun Nov 20 10:32:13 2022 Socket Buffers: R=[180224->180224] S=[180224->180224]
Sun Nov 20 10:32:13 2022 UDPv4 link local (bound): [AF_INET][undef]:1194
Sun Nov 20 10:32:13 2022 UDPv4 link remote: [AF_UNSPEC]
Sun Nov 20 10:32:13 2022 MULTI: multi_init called, r=256 v=256
Sun Nov 20 10:32:13 2022 Initialization Sequence Completed
[...]
Sun Nov 20 10:34:34 2022 xxx.xxx.xxx.xxx:36984 TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx:36984, sid=xxxxxxxx xxxxxxxx
Sun Nov 20 10:34:35 2022 xxx.xxx.xxx.xxx:36984 VERIFY OK: depth=1, C=XX, ST=XX, L=xxx, O=xxx, OU=xxx, CN=xxx, name=xxx, emailAddress=xxx@xxx.xx
Sun Nov 20 10:34:35 2022 xxx.xxx.xxx.xxx:36984 VERIFY OK: depth=0, C=XX, ST=XX, L=xxx, O=xxx, OU=xxx, CN=vpn-client, name=xxx, emailAddress=xxx@xxx.xx
Sun Nov 20 10:34:35 2022 xxx.xxx.xxx.xxx:36984 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
Sun Nov 20 10:34:35 2022 xxx.xxx.xxx.xxx:36984 [vpn-client] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:36984
Sun Nov 20 10:34:35 2022 vpn-client/xxx.xxx.xxx.xxx:36984 MULTI: no dynamic or static remote --ifconfig address is available for vpn-client/xxx.xxx.xxx.xxx:36984
Sun Nov 20 10:34:36 2022 vpn-client/xxx.xxx.xxx.xxx:36984 PUSH: Received control message: 'PUSH_REQUEST'
Sun Nov 20 10:34:36 2022 vpn-client/xxx.xxx.xxx.xxx:36984 SENT CONTROL [vpn-client]: 'PUSH_REPLY,compress lz4,route-delay 5,redirect-gateway def1,route-gateway dhcp,ping 10,ping-restart 60,peer-id 0,cipher AES-256-GCM' (status=1)
Sun Nov 20 10:34:36 2022 vpn-client/xxx.xxx.xxx.xxx:36984 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun Nov 20 10:34:36 2022 vpn-client/xxx.xxx.xxx.xxx:36984 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Nov 20 10:34:36 2022 vpn-client/xxx.xxx.xxx.xxx:36984 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Nov 20 10:34:36 2022 vpn-client/xxx.xxx.xxx.xxx:36984 MULTI: Learn: 12:de:ad:af:fe:34 -> vpn-client/xxx.xxx.xxx.xxx:36984
[...]
Sun Nov 20 10:49:09 2022 vpn-client/xxx.xxx.xxx.xxx:36984 [vpn-client] Inactivity timeout (--ping-restart), restarting
Sun Nov 20 10:49:09 2022 vpn-client/xxx.xxx.xxx.xxx:36984 SIGUSR1[soft,ping-restart] received, client-instance restarting

Weitere VPN-Clients

Auch für iOS und Android gibt es OpenVPN als App. Allerdings stellt keines der beiden Systeme das für unsere Art von VPN notwendige TAP-Netzwerkgerät zur Verfügung [5]. Warum das so ist, erklären die OpenVPN-FAQ [6].

Für Android-Systeme gibt es die App VPN Client Pro [7], die in der kostenpflichtigen Version ein TAP-Netzwerkgerät bereitstellt, sodass sich das Mobilgerät mit dem Heimnetz verbinden lässt. Dabei handelt es sich aber nur um eine Emulation, wie Paolo Colucci, der Autor dieser App, bestätigt. Damit können andere Apps im Gerät immer noch keine Netzwerkpakete auf OSI-Ebene 2 über das VPN schicken, sondern nur IP-Pakete auf Ebene 3.

Im Gegensatz zu Linux-Systemen, sei es nun auf der Seite des VPN-Servers oder des Clients, befindet sich die VPN-Konfiguration dabei vollständig in einer einzigen Datei (Listing 14). Sie umfasst auch die Zertifikate und Keys zur Verschlüsselung in Textform. Diese Datei transferieren Sie auf das Mobilgerät und importieren sie dort in die VPN-App.

# -- openvpn mode
client
# -- network device
dev tap
# -- contacting the server
remote 1194 udp
# -- more configurations
resolv-retry infinite
remote-cert-tls server
nobind
persist-key
persist-tun
comp-lzo
verb 3
# -- certificates, keys, etc ...
<ca>
-----BEGIN CERTIFICATE-----
CA-X.509-Zertifikat als Plaintext
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
VPN-Client-X.509-Zertifikat als Plaintext
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
VPN-Client-Schlüssel als Plaintext
-----END ENCRYPTED PRIVATE KEY-----
</key>

Fazit

Das Bridge-VPN zum Heimnetzwerk funktioniert bestens. Die notwendige Konfigurationsarbeit am Internet-Router reduziert sich auf ein Minimum, auch die simpelsten Exemplare der Gattung gestatten das notwendige Setup. Der VPN-Client bezieht seine IP-Adresse und Netzwerkkonfiguration direkt vom DHCP-Server des Zielnetzes, in das er sich nahtlos einfügt, als wäre er vor Ort.

Auch Wake-on-LAN und andere OSI-Ebene-2-Dienste funktionieren, allerdings nur vom Linux-Rechner aus. VPN-Apps auf iOS- und Android-Mobilgeräten scheitern derzeit noch an der fehlenden Verfügbarkeit echter TAP-Netzwerkgeräte. Hier gibt es Nachholbedarf. (tle)