Offene Verschlusssache
Seite 4: Bridge-Modus
Brückenbau
In der Standardkonfiguration arbeitet OpenVPN im Routing-Modus. Das heißt, das VPN nutzt ein eigenes Transfernetz – per Default 10.8.0.0/24. Die Tunnelendpunkte haben dabei Adressen aus diesem Netz und alle VPN-Pakete werden durch diesen Tunnel geroutet. Dazu setzt OpenVPN virtuelle TUN-Interfaces ein, die eine Punkt-zu-Punkt-Verbindung auf IP-Ebene erlauben.
In manchen Situationen ist dieser Umweg jedoch hinderlich, beispielsweise wenn man OpenVPN zur Fernwartung eines kleinen Firmennetzes einsetzt. Dabei steht der OpenVPN-Server oft hinter einem einfachen Router direkt im Firmennetz, der zwar das notwendige Port-Forwarding beherrscht, aber beispielsweise keine statische Route auf das virtuelle 10er-Netz zum OpenVPN-Server setzen kann. Außerdem wäre es für Diagnosezwecke nützlich, sich quasi direkt im lokalen Netz zu befinden, statt wie in der Standard-Konfiguration nur über geroutete Pakete dorthin zu gelangen.
Für solche Zwecke kann OpenVPN auch Netze überbrücken und als Bridge arbeiten. Dazu erzeugt es virtuelle Netzwerkkarten, die so genannten TAP-Devices. Eine Bridge vermittelt zwischen den TAP-Devices und dem LAN-Interface derart, dass es für alle Beteiligten so aussieht, als wäre eine weitere Netzwerkkarte direkt an das Ethernet angeschlossen. Das TAP-Interface bekommt folglich auch eine IP-Adresse aus dem Bereich des Firmennetzes, beispielsweise 192.168.10.0/24. Das hat eine Reihe von Vorteilen. So kommen beispielsweise alle Broadcasts im Netz auch auf dem VPN-Client an und man kann deshalb Windows-Dateifreigaben auch ohne WINS- oder Samba-Server browsen. Des Weiteren ist es damit möglich, über das VPN auch Nicht-IP-Protokolle wie IPX oder Appletalk einzusetzen. Dafür ist es weniger effizient als das Routing, skaliert nicht so gut und ist zumindest auf der Server-Seite etwas schwieriger aufzusetzen.
In einem einfachen Setup reserviert man für die VPN-Clients einen Bereich aus dem Block der Netzwerkadressen im LAN, beispielsweise 192.168.10.230-250, die für den lokalen DHCP-Server tabu sind. In server.conf kommentiert man die Einträge für dev tun und server und aktiviert stattdessen dev tap0 und server-bridge:
dev tap0
;dev tun
;server 10.8.0.0 255.255.255.0
server-bridge 192.168.10.2 255.255.255.0 192.168.10.230 192.168.10.250
Dabei ist die 192.168.10.2 die Adresse des Servers im LAN; den VPN-Clients weist der Server dynamisch Adressen aus seinem Privat-Pool zu. Windows findet das passende TAP-Device selbst, sodass hier nur tap ohne die 0 einzugeben ist. Nun ist noch das Bridging zu aktivieren. Unter Windows XP geht das vergleichsweise einfach, indem man in den Netzwerkverbindungen die Netzwerkkarte und das TAP-Interface auswählt und "Verbindungen überbrücken" ausführt.
Unter Linux muss man die Bridge wie in der Dokumentation beschrieben von Hand einrichten. Wer einen c't-Debian-Server einsetzt, muss lediglich in /etc/networks/interfaces ein weiteres tap-Device erstellen und bei br0 unter bridge_ports eintragen. Wichtig ist es, auch in client.conf dev tap zu verwenden, da sich TUN- und TAP-Modus nicht vertragen.
