Sichere WLAN-Vernetzung mit verschlüsseltem OpenVPN-Tunnel

Drahtlose Netze sind praktisch und gefährlich zugleich: Die eingebaute WEP-Verschlüsselung hält keinem Angreifer stand. Abhilfe schaffen zusätzliche Sicherheitsmaßnahmen bis hin zum verschlüsselten OpenVPN-Tunnel.

Die WLAN-Technik arbeitet unsicher, das hat sich herumgesprochen [5]. Die eingebaute Verschlüsselungstechnik ist leicht zu knacken – und zu allem Überfluss oft deaktiviert. Während im klassischen Heimnetz mit Kabel, Stecker und Dose ein Datenspion Zugang in die Wohnung (oder zu einem Rechner) braucht, können neugierige Zeitgenossen mit Laptop und WLAN-Karte ausgerüstet durch die Straßen ziehen und sich in jedes drahtlose Netz einklinken. Dank Verstärker und spezieller Antennen gelingt das problemlos über viele hundert Meter.

Dennoch gehören die praktischen Funknetze heute zu den etablierten Netzwerktechniken. Wer mit seinem Laptop auf dem Balkon oder im Garten arbeitet, will auch hier Webseiten betrachten oder Dateien vom Desktop-PC im Wohnzimmer auf den Laptop kopieren. Dagegen ist auch nichts einzuwenden – es gilt nur einige Grundregeln zu beherzigen, dann verliert die drahtlose Technik ihren Schrecken.

Gezielt schützen

Welche Schutzmaßnahmen sich am besten eignen hängt davon ab, wie die Rechner vernetzt sind und welche Daten das WLAN transportieren soll. Für manche Anwender ist der WLAN-eigene Schutz ausreichend, einige verzichten sogar bewusst auf jede Sicherung. Wer mehr will, greift auf VPN-Protokolle zurück. Einfach zu bedienen aber dennoch modern und sicher erweist sich OpenVPN [1]. Dieses Protokoll verschlüsselt und authentifiziert die komplette Kommunikation zwischen zwei Linux- oder Windows-Rechnern.

Jenseits des Heimnetzes lauern im Internet wieder die gleichen Gefahren wie im WLAN: Angreifer können in beiden Fällen Daten abhören, manipulieren oder eigene Informationen einschleusen. Es sind daher zwei Fälle zu unterscheiden: Der einzelnen PC oder Laptop, der per Funknetz und einem WLAN-Router online geht (siehe Kasten 1) sowie das geschützte Heimnetz, dessen Besitzer die kabelgebundenen Netze durch ein WLAN ergänzt oder ersetzt (Kasten 2).

Kasten 1: Einzelner Computer

Im einfachsten Fall verbindet das WLAN einen Rechner mit einem Accesspoint, der die Daten ins Internet weiterreicht. Als zusätzliche Gefahr im Vergleich zum herkömmlichen Kabel drohen das Schnorren des Online-Zugangs, das Stören der Verbindung (Denial of Service) und der einfachere Zugriff durch Nachbarn und Passanten. Nur wer direkte und gezielte Angriffe fürchtet, sieht Funknetze als besonderes Risiko. Zufällige und ziellose Attacken können ihn bei der Datenübertragung im Internet genauso treffen wie auf dem letzten Teilstück zwischen WLAN-Zugangsrouter und Laptop.

Abbildung 1: Wer nur einen Laptop mit einem WLAN-Zugangsrouter betreibt, braucht kaum mehr Angriffe fürchten als wenn er sein Rechner per Modem oder DSL ins Internet bringt. In beiden Fällen sind die Daten manipulierbar.

Es gilt in jedem Fall, gegenüber sämtlichen Daten ein gewisses Maß an Misstrauen zu entwickeln. Nur mit kryptografischen Mitteln lässt sich feststellen, ob Daten authentisch sind, sowie vermeiden, dass Unbefugte darauf zugreifen. Also: Wo möglich, Webseiten per SSL/TLS geschützt abholen, und auch beim Abholen von E-Mail den SSL-Schutz der gängigen Mail-Programme aktivieren. SSL verschlüsselt und authentifiziert die Daten während der Übertragung. Wer noch einen Schritt weiter geht, setzt auf PGP oder S/MIME Diese Verfahren verschlüsseln die E-Mail selbst und nicht nur deren Übertragung. Für sichere Remote-Logins empfiehlt sich SSH.

Kasten 2: Heimnetz mit WLAN

Deutlich komplizierter zu bewerten als der Fall in Kasten 1 ist ein Heimnetz, in dem sich mehrere Rechner befinden. Den Internet-Zugang solcher Netze schützt meist eine Firewall, hinter der sich die Benutzer sicher vor Angriffen fühlen. Häufig verhindert die Firewall jede Kontaktaufnahme aus dem Internet in das LAN. In dieser heimeligen Atmosphäre konnten sich viele gefährliche Praktiken halten: Da gibt der NFS– oder Samba-Server die privaten Verzeichnisse für alle Rechner frei, der Druckserver sendet seine Daten im Klartext, Logins über Telnet oder Rlogin sind erlaubt. Kurz: Jeder Computer vertraut dem Netz und den angeschlossenen Rechnern.

Abbildung 2: Auf die Übertragung zwischen beiden Desktops haben Außenstehende keinen Zugriff, so lange sie nicht das LAN-Kabel anzapfen. Bei WLAN entfällt dieser physische Schutz, jeder Nachbar und jeder Passant kann die Daten abhören oder eigene Pakete einschleusen.

Dieses Vertrauen ist schon im klassischen LAN gefährlich, im WLAN aber deutlich schlimmer. Hier sitzt der Angreifer auf der falschen Seite der Firewall und greift das lokale Netz von innen an. Beim herkömmlichen drahtgebundenen Netz brauchen die Spione und Saboteure dazu immerhin Zugang in die Wohnung. Bei WLAN genügt es, wenn sie vor Wohnung oder im Nachbargebäude stehen – der Zugang zu Kabeln oder Steckdosen wird überflüssig.

Nur mit Kryptographie gelingt es, Funkverbindungen vor fremden Zugriffen wirksam zu schützen. Der erste Versuch, dies für WLAN zu standardisieren, scheiterte jedoch: Das WEP-Verfahren ist recht einfach zu knacken und erfüllt damit seinen Aufgabe nur ungenügend. Per VPN-Protokoll lässt sich dieser Schutz jedoch nachrüsten (siehe Artikel).

Schnorrer und Störer

Eine neue Gefahr bringen WLAN-Netze jedoch mit: Fremde können offene WLAN-Accesspoints mitbenutzen, um darüber eine Online-Verbindung ins Internet zu schnorren. Der potenzielle Schaden hängt in erster Linie vom Online-Tarif ab. Viele Flatrate-Eigner kümmert es nicht, wenn sich der Nachbar per WLAN auf Umwegen ins Netz schummelt. Bei Volumen- oder Zeittarifen droht dem eigenen Geldbeutel aber durchaus Gefahr. Diese lässt sich immerhin begrenzen, wenn der MAC-Filter im WLAN-Router aktiviert ist und die WEP-Verschlüsselung zum Einsatz kommt (zur Konfiguration siehe die anderen Artikel in diesem Heftschwerpunkt).

Beide Maßnahmen stellen zwar keinen sicheren Schutz dar, aber sie dienen immerhin als zusätzliche Hürden, die ein Schnorrer nehmen muss. Er kann sich nicht mehr darauf herausreden, das fremde WLAN versehentlich zu verwenden oder denken, der Besitzer des WLAN-Hotspots wäre damit einverstanden, dass jeder den Online-Zugang mitbenutzt. MAC-Filter und WEP sollten daher immer aktiviert sein, sie abzuschalten gilt fast als Einladung für Cracker, Schnorrer und Spione.

Besserer Schutz gelingt nur mit deutlich mehr Aufwand. Immerhin steht bereits ein WEP-Nachfolger fest: Die IEEE hat Ende Juni 2004 einen Standard namens 802.11i verabschiedet, auch WPA-2 genannt. Leider beherrschen nur neuere Karten diese Technik. Der korrekte Einsatz ist nicht einfach: Der neue Standard beschreibt viele Techniken, aber nicht alle gelten als sicher. Empfehlenswert sind AES-CCMP zur Verschlüsselung und 802.1x für Authentifizierung und Schlüssel-Management.

Mit VPN geschützt

Auch ohne neue WLAN-Karten ist ein sicherer und Schnorrer-resistenter WLAN-Betrieb unter Linux möglich. Was die Hardware nicht leistet, muss die Software nachrüsten: VPN-Protokolle (Virtuelle Private Netze) verschlüsseln und authentifizieren die Daten auf der IP-Schicht. Ein VPN-Endpunkt nimmt alle Daten entgegen, verschlüsselt und signiert sie und überträgt sie drahtlos. Das Gegenstück am anderen Ende packt die Pakete wieder aus.

Ein VPN nutzt das herkömmliche WLAN, sieht für den Client aber aus wie ein zusätzliches Netz – eben virtuell. Abbildung 3 verdeutlicht das Prinzip: Laptop und Desktop sind über ein WLAN miteinander verbunden. Im drahtlosen Netz sind beide über ihre reale IP-Adresse zu erreichen. Das VPN gibt Laptop und Desktop je eine zusätzliche IP-Adresse. Alle Daten, die über die virtuellen Adressen gesendet werden, verpackt das VPN und sendet sie an die reale IP des Gegenübers. Der Empfänger packt die Daten wieder aus und behandelt sie so, als ob sie über seine virtuelle Adresse hereingekommen wären. Dadurch entsteht ein Tunnel zwischen Laptop und Desktop.

Abbildung 3: Das Virtuelle Private Netz wird durch einen Tunnel geleitet, der an den realen IP-Adressen von Laptop und Desktop beginnt und endet.

Zusätzliche Firewall-Regeln sorgen dafür, dass beide Rechner nur die Daten annehmen, die durch den Tunnel gekommen sind. Pakete, die ein Angreifer direkt in das WLAN einschleust, haben damit keine Chance.

OpenVPN

Das VPN-Prinzip findet sich in verschiedenen Protokollen, Produkten und Projekten. Als stabile und einfache Variante, die ohne Eingriff in den Kernel oder den IP-Stack auskommt, hat sich OpenVPN [1] bewährt. Da dieses Programm auf dem etablierten Krypto-Protokoll TLS basiert und sauber implementiert ist, gilt es unter Experten als sehr sicher [6].

OpenVPN sammelt an beiden Enden des Tunnels die Datenpakete, die für die Gegenseite bestimmt sind. Dann verschlüsselt es sie mithilfe eines lokal hinterlegten Schlüssels und sendet die so geschützten Pakete zur anderen Seite. Das Gegenüber packt die Daten aus und prüft deren Herkunft. Nur Daten, die mit dem korrekten Schlüssel verpackt wurden, akzeptiert die Gegenstelle und leitet sie weiter, andere Pakete ignoriert sie. So tunneln Datenpakete in sicheren Containern durch ein Meer der Unsicherheit.

Das folgende Beispiel geht davon aus, dass das drahtlose Netz über wlan0 angebunden ist. Der Desktop-Rechner hat zudem eine herkömmliche, drahtgebundene Netzwerkkarte, die er mit eth0 anspricht. Über dieses Ethernet sind andere Rechner im heimischen Netz sowie das Internet zu erreichen (Abbildung 3).

Kasten 3: Installation

OpenVPN ist recht einfach zu installieren. Das Source-Paket der stabilen Version 1.6.0 ist auf der Projekt-Homepage [1] oder auf unserer Heft-CD zu finden. Folgende Kommandos entpacken das Paket, übersetzen es und installieren es mit Root-Rechten:

tar -xvzf openvpn-1.6.0.tar.gz
cd openvpn-1.6.0
./configure --disable-lzo
make
su
make install

Der Configure-Aufruf ist hier mit dem Parameter --disable-lzo angegeben, um die Kompression abzuschalten. Da sich die Daten nach der Verschlüsselung nicht mehr komprimieren lassen, ist diese Bibliothek für langsame Leitungen jedoch sehr zu empfehlen. Sie ist auf [3] oder der Heft-CD zu finden. Auf jeden Fall nötig ist die OpenSSL-Bibliothek zusammen mit den Entwicklerdateien. Bei SuSE sind das zwei getrennte Pakete: openssl und openssl-devel.

Das Tunnel-Device ist in aktuellen Kerneln bereits enthalten, für ältere Versionen steht das Paket auf [2] bereit. Wer den Kernel selbst übersetzt, findet in make xconfig das TUN-Modul in der Sektion “Network device support” unter dem Namen “Universal TUN/TAP device driver support”. Das Modul lässt sich auch einzeln nachträglich übersetzen und installieren, ohne den ganzen Kernel auszutauschen. Nach dem Konfigurieren des Kernels genügt:

make modules
make modules_install

Nun muss noch das Device-File /dev/net/tun angelegt werden. Falls das Verzeichnis /dev/net/ noch nicht vorhanden ist: mkdir /dev/net/. Dann noch das Device anlegen:

mknod /dev/net/tun c 10 200

Erste Schritte

Falls nicht schon vorhanden, ist als erstes das OpenVPN-Paket zu installieren (siehe Kasten 3). OpenVPN nimmt keine Änderungen am Kernel vor. Damit das Umleiten der Pakete dennoch klappt, nutzt es den TUN/TAP-Treiber [2]. Das entsprechende Kernelmodul gehört längst zur Standardausstattung der großen Distributionen. Das Modul muss nur noch geladen werden. Folgendes Kommando als Root-User eingeben genügt:

modprobe tun

In Linux erhalten Netzwerk-Interfaces normalerweise kein Device-File, es gibt kein /dev/eth0. Das erscheint zwar nicht ganz konsequent, ist aber auch nicht nötig – für die Kommunikation kommt die Socket-Schnittstelle zum Einsatz. Das TUN-Interface nutzt diesen Umstand und legt gegen die Regel doch ein Device-File an. Damit kann ein Userspace-Daemon die IP-Pakete abgreifen, neu verpacken und weiter senden.

Der Daemon schreibt Pakete nach /dev/tun0 oder /dev/net/tun (siehe Kasten 1), beim Kernel kommen sie über das tun0-Interface an. Jedes Paket, das der Kernel zu tun0 leitet, erhält der Daemon über /dev/tun0 oder /dev/net/tun (siehe Abbildung 3). Das Interface funktioniert wie jedes gewöhnliche Netzwerk-Interface, man kann IP-Adressen daran binden, es in das Routing aufnehmen und Firewall-Regeln anwenden – nur sendet es die Daten nicht über eine Ethernet-Karte ins Netz, sondern über ein Device-File zu einem Prozess.

Schlüsselfrage

OpenVPN benötigt Schlüssel, um sicher zu arbeiten. In der einfachsten Variante verwenden beide zu verbindenden Rechner den gleichen geheimen Schlüssel, Shared Secret genannt. Folgendes Kommando erzeugt einen Schlüssel und legt ihn in der Datei geheimer.key ab:

openvpn --genkey --secret geheimer.key

Diesen Key dürfen nur die beiden Rechner kennen, und dort nur für Root lesbar sein – wer den Schlüssel kennt, kann den Tunnel problemlos knacken. Das Kopieren der Key-Datei auf den zweiten Rechner muss abhörsicher ablaufen. Auf der Funkstrecke könnte schon jemand mitlauschen. Am besten eignet sich eine Diskette, die man anschließend vollständig formatiert. Wer bereits OpenSSH, PGP, GnuPG oder ähnliches installiert hat, kann auch diese Programme benutzen, um die Datei sicher zu übermitteln.

Tunnel graben

Nun geht es daran, den Tunnel zu erzeugen. Dazu benötigt OpenVPN die (feste) IP-Adresse des Zielrechners, den Namen des Tunnel-Devices (standardmäßig tun0) sowie die beiden virtuellen IP-Adressen für das VPN und die Datei mit dem Schlüssel. Auf dem Laptop sieht das so aus:

openvpn --dev tun0 --remote [Reale_DesktopIP] \
 --ifconfig [Virtuelle_LaptopIP] [Virtuelle_DesktopIP] \
 --secret geheimer.key

Das Kommando muss von Root aufgerufen werden, wie auch alle folgenden Befehle. Auf dem Desktop lautet dieser Aufruf mit angepassten IP-Adressen:

openvpn --dev tun0 --remote [Reale_LaptopIP] \
 --ifconfig [Virtuelle_DesktopIP] [Virtuelle_LaptopIP] \
 --secret geheimer.key

Die virtuellen Tunneladressen sind (fast) beliebig, es müssen aber private Adressen sein. Die virtuellen Adressen sollten auch aus einem anderen Block stammen als die realen Adressen, da somit das Routing einfacher wird – reales und virtuelles Netz sind leicht zu unterscheiden.

Adressvergabe

Als konkretes Beispiel könnte die WLAN-Karte des Laptops die reale IP-Adresse 172.16.0.1 haben, der Desktop 172.16.0.2. Das VPN braucht eigene Adressen aus einem privaten Adressraum, etwa 10.0.0.1 als virtuelle Laptop-IP-Adresse und 10.0.0.2 für den Desktop. Damit lautet das Kommando auf dem Laptop:

openvpn --dev tun0 --remote 172.16.0.2 \
 --ifconfig 10.0.0.1  10.0.0.2 \
 --secret geheimer.key

Und auf dem Desktop:

openvpn --dev tun0 --remote 172.16.0.1 \
 --ifconfig 10.0.0.2  10.0.0.1 \
 --secret geheimer.key

Ob der Tunnel steht, zeigt ein abschließender Ping-Test. Auf dem Laptop sollte ping 10.0.0.2 funktionieren und zeigen, dass die virtuelle IP-Adresse des Desktops erreichbar ist.

Wenn alles klappt, darf OpenVPN auch als Daemon laufen, der im Hintergrund arbeitet und seine Meldungen über Syslog ausgibt. Dazu muss der Aufruf die Option --daemon enthalten. Aber Vorsicht: Jetzt ist die Datei, die den geheimen Schlüssel enthält, mit ihrem absoluten Pfad anzugeben.

Kasten 4: Funktionsvielfalt in OpenVPN

Neben dem hier dargestellten einfachen Client-to-Site-VPN kann OpenVPN auch ganze Standorte vernetzen, dazu ist lediglich das Routing anzupassen. Im Bridge-Modus verbindet es sogar transparent zwei Teile eines LAN, die beide die gleichen Adressräume nutzen.

Das im Artikel beschriebene Shared-Secret-Verfahren stößt schnell an seine Grenzen, wenn viele Knoten im VPN eingebunden sind. Dann zeigt sich die TLS-Basis von ihrer besten Seite: Sie ist für den Einsatz von X.509-Zertifikaten ausgelegt. Version 2.0 (derzeit im Beta-Stadium) bringt Admins eine zusätzliche Vereinfachung: Sie müssen dann nicht mehr für jeden VPN-Client eine eigene Server-Konfiguration erstellen, gültige X.509-Zertifikate genügen. Außerdem soll der neue Server unter hoher Last deutlich performanter arbeiten.

OpenVPN unterscheidet im UDP-Modus nicht zwischen Client und Server, sondern arbeitet als Peer-to-Peer-Applikation. Wenn bei aktivierter Option --float einer der Endpunkte eine neue IP erhält, etwa durch den verbreiteten Zwangs-Reset nach 24 Stunden, kann er mit seiner neuen realen Adresse den Tunnel unterbrechungsfrei weiterführen. TCP-Verbindungen bleiben bestehen – besonders praktisch beim FTP-Transfer wirklich großer Dateien.

Wer häufiger große Files durch den Tunnel sendet, wird auch die Option --shaper [Bandbreite] schätzen. Sie begrenzt die Bandbreite in den Tunnel hinein auf die angegebenen Bytes pro Sekunde. Um beide Richtungen zu begrenzen, ist die Option an beiden Enden anzugeben. Für administrative Aufgaben besonders interessant: OpenVPN kann gleichzeitig mehrere Tunnel zwischen zwei Partnern öffnen und ihnen unterschiedliche Bandbreiten zuteilen. Das Routing entscheidet, welche Daten durch welchen Tunnel laufen.

Seit Version 1.5 unterstützt OpenVPN ersatzweise auch TCP. Wer hinter einer Firewall sitzt, die nur TCP akzeptiert, hat kaum eine andere Wahl als auf dieses Verfahren zu setzen. Der Nachteil: Treten auf dem Netzwerk Probleme auf, dann verschlimmert die Kombination VPN-über-TCP die Situation. Wo möglich, sollte OpenVPN daher den klassischen Weg über UDP wählen.

Der richtige Weg

Der Tunnel steht und die Pakete wandern brav zum anderen Ende – aber Laptop und Desktop müssen auch wissen, welche Pakete durch den Tunnel gehen sollen. Ist die virtuelle IP-Adresse des Gegenübers angegeben, dann klappt das schon. Der OpenVPN-Aufruf setzt die Route für genau diese Adresse passend. Alle anderen Adressen werden wie vorher geroutet – am Tunnel vorbei.

Der Weg vom Desktop zum Laptop klappt schon, wenn der Laptop mit seiner neuen virtuellen Adresse angesprochen wird. Die alten realen Adressen der WLAN-Karten in Laptop und Desktop erfüllen nur noch einen Zweck: Sie sind die Endpunkte des Tunnels. In normalen Verbindungen haben sie nichts zu suchen.

Der Weg vom Laptop zurück zum Desktop und weiter zu den anderen Rechnern im eigenen Netz und im Internet benötigt noch etwas Handarbeit: Die Default-Route ist neu zu setzen. Mit folgendem Aufruf sendet der Laptop alle Pakete durch den Tunnel:

route del default
route add default gw 10.0.0.2

Nicht von der Default-Route betroffen sind die Pakete, die zur realen WLAN-IP-Adresse des Desktops (172.16.0.2) gehen. Das ist auch gut so, da der Tunnel selbst an dieser Adresse angedockt ist. Nun muss der Desktop noch wissen, dass er die ausgepackten Pakete bei Bedarf weiterzuleiten hat. Dies geschieht mit folgendem Befehl:

echo "1" > /proc/sys/net/ipv4/ip_forward

Feuerdämmend

Damit ist es auf beiden Seiten schon fast getan. Von sich aus nutzen Laptop und Desktop den Tunnel, die Daten sind geschützt und niemand kann sie abhören. Neue Pakete einschleusen ist aber immer noch möglich: So schnorrt ein Angreifer die Internet-Anbindung des Desktops. Selbst wer eine Flatrate hat, wird die Bandbreite eventuell nicht verschenken wollen. Alle Netzdienste, die der Laptop und der Desktop anbieten (etwa Web-, SSH- oder FTP-Server), sind vom WLAN aus angreifbar. Wer ein eigenes Netz betreibt, sieht sich noch einer weiteren Gefahr ausgesetzt: Die Pakete, die ins WLAN eingeschleust werden, umgehen eine Firewall, die zwischen Internet und lokalem Netz steht.

Gegen diese Lücke schützt eine geeignete Firewall-Konfiguration [4]. Der Artikel vom Mai 2002 beschreibt, wie eine Firewall mit iptables funktioniert. Die OpenVPN-Distribution [1] enthält auch ein Beispiel-Firewall-Skript. Für die WLAN-Tunnel-Kombination sind aber zusätzliche Regeln nötig. Abbildung 4 zeigt, an welchen Stellen diese Regeln ansetzen.

Abbildung 4: Einige Firewall-Regeln verhindern, dass Fremde durch das WLAN eindringen. Über das WLAN-Interface darf nur der OpenVPN-Tunnel senden.

Du kommst da nicht rein

OpenVPN versendet die verschlüsselten Pakete mit UDP an Port 5000 der Gegenseite. Dazu benutzt es das WLAN, am Interface wlan0 muss also der UDP-Port 5000 freigeschaltet sein. Für das Empfangen von Paketen erledigt das folgender Aufruf:

iptables -A INPUT -i wlan0 -p udp --dport 5000 -j ACCEPT
iptables -A INPUT -i wlan0 -j DROP

Die letzte Zeile sorgt dafür, dass der Rechner über das WLAN keine anderen Pakete annimmt. Die erste Input-Regel könnte sogar noch strenger sein und mit -s RealeIP vorgeben, von welcher IP-Adresse die Pakete stammen dürfen. Hier wäre die reale IP des jeweiligen Gegenübers anzugeben, auf dem Laptop also -s 172.16.0.2. Auch das Senden und Weiterleiten von Paketen ist einzuschränken:

iptables -A OUTPUT -o wlan0 -p udp --dport 5000 -j ACCEPT
iptables -A OUTPUT -o wlan0 -j DROP
iptables -A FORWARD -i wlan0 -j DROP

Die Tunnel-Enden leiten nur Pakete weiter, die von einem bekannten Partner stammen, der den richtigen (geheimen) Schlüssel benutzt hat. Daher kann man den Paketen vertrauen, die von einem tun-Device stammen, sie annehmen und verarbeiten. Auch das Senden in den Tunnel hinein muss erlaubt sein. Folgende Aufrufe gestatten das Empfangen und Senden:

iptables -A INPUT -i tun0 -j ACCEPT
iptables -A OUTPUT -o tun0 -j ACCEPT

Auf dem Laptop genügt das schon. An ihm sind keine weiteren Netzwerke angeschlossen, er muss daher keine Pakete weiterleiten.

Weiter leiten

Der Desktop benötigt noch eine Forwarding-Regel. Außerdem muss er Masquerading einsetzen, damit der Laptop auch nach außen senden kann:

iptables -A FORWARD -i tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Die Masquerading-Regel sorgt dafür, dass der Desktop seine eigene öffentliche IP-Adresse an Stelle der privaten Adresse aus dem VPN einsetzt. Mit der privaten Adresse könnte das Paket nicht ins Internet geleitet werden. So aber routet der Desktop alle Pakete, die vom Laptop durch den OpenVPN-Tunnel kommen, weiter zu seiner LAN-Schnittstelle und ins Internet. Ist der Desktop per DSL oder Modem ans Internet angebunden, dann ist ppp0 an Stelle von eth0 anzugeben.

Grenzen der Sicherheit

Jedes Netzwerk ist nur so sicher wie die angeschlossenen Rechner. Hat ein Unbefugter Zugriff auf einen OpenVPN-Laptop, dann erfährt er den Schlüssel und erhält Zugang zum virtuellen Netz und darüber ins LAN. Drahtlose Geräte sind daher besonders gegen Diebstahl zu sichern.

Wer diese Grundsätze berücksichtigt, findet in OpenVPN ein sehr sicheres und dennoch einfach zu bedienendes VPN-Produkt. Es umschifft die Schwächen der WLAN-Verschlüsselung elegant. So darf man ruhigen Gewissens die Bequemlichkeit eines Funknetzes nutzen.

Glossar

Denial of Service: Bei dieser Technik blockiert der Angreifer einen Dienst oder eine Datenübertragung.
WLAN-Zugangsrouter: Kompaktes Gerät, das neben einem WLAN-Accesspoint auch über einen Kabel-gebunden Internet-Anschluss verfügt (etwa per Ethernet, Modem, ISDN oder DSL).
SSL/TLS: Die Secure Sockets Layer ist ein von Netscape entwickeltes Krypto-Protokoll. SSL hat sich beim verschlüsselten Übertragen bewährt und etabliert. Die Weiterentwicklung findet unter dem Namen Transport Layer Security statt.
PGP: Pretty Good Privacy kommt beim Verschlüsseln und Signieren von E-Mail zum Einsatz. PGP bezeichnet ein Programm, OpenPGP ist der Standard für das Verfahren und GnuPG eine neuere Implementierung.
S/MIME: Secure/Multipurpose Internet Mail Extensions ist ein weiteres Verfahren neben PGP, um E-Mails zu verschlüsseln und digital zu signieren.
SSH: Mit der Secure Shell können sich Linux-User auf anderen Computern einloggen. Die komplette Sitzung inklusive Passwort-Übertragung wird von SSH verschlüsselt.
NFS: Das Network File System ist eine recht alte aber weiterhin verbreitete Technik, um Verzeichnisse von fernen Unix/Linux-Rechnern einzubinden (mounten).
Samba: Dieses Programmpaket ist kompatibel zur Windows-Verzeichnisfreigabe. Hiermit kann man Linux-Verzeichnisse für Windows-Clients freigeben und umgekehrt Windows-Shares unter Linux einbinden.
VPN: Virtuelles Privates Netz. Benutzt ein tatsächlich vorhandenes Netz, um darüber eine andere Vernetzung nachzubilden. Die VPN-Software verschlüsselt die übertragenen Daten meist, bevor es sie weiterleitet.
WEP: Mit Wired Equivalent Privacy wollten die Väter des WLAN ein sicheres Krypto-Protokoll standardisieren, mit dem der Funkverkehr ebenso geschützt ist wie in einem Kabel. Es zeigte sich aber bald, dass das Protokoll fehlerhaft und damit unsicher arbeitet.
MAC: Media Access Control. Innerhalb dieser Protokollschicht kommen eigene Adressen zum Einsatz. Die so genannten MAC-Adressen sind jedem Gerät bereits bei der Auslieferung vorgegeben und weltweit eindeutig.
IEEE: Institute of Electrical and Electronics Engineers, eine internationale Organisation, die unter anderem Standards entwickelt und festschreibt.
802.11i: Neuer Standard für Sicherheit in Funknetzen, der WEP und WPA ablöst. Er basiert auf WPA, 802.1x sowie RSN (Robust Security Network).
WPA-2: Das WPA-Protokoll (WiFi Protected Access) behebt die bekannten Fehler von WEP, ist aber kein anerkannter Standard. Die WiFi-Organisation bezeichnet den WPA-Nachfolger 802.11i als WPA-2.
AES-CCMP: Advanced Encryption Standard, ein moderner (symmetrischer) Verschlüsselungsalgorithmus. Das Counter-Mode/CBC-MAC Protocol ist eine Sicherheitsschicht, die Daten verschlüsselt und authentifiziert.
private Adressen: Normale, öffentliche IP-Adressen sind weltweit eindeutig. Nur so kann ein Paket den Weg zum richtig Ziel finden. Im Gegensatz dazu sind die privaten IP-Adressen nur im lokalen Netz gültig, sie werden nicht in das öffentliche Internet geroutet. Dadurch können mehrere Netze die selben privaten Adressen nutzen. Für diesen Zweck sind einige IP-Bereiche reserviert: 10.x.x.x und 192.168.z.z sowie 172.16.y.y bis 172.31.y.y.
Routing: Wegewahl für IP-Pakete. Linux entscheidet anhand einer Routing-Tabelle, über welches Interface es ein Paket senden muss, damit es seinem Ziel näher kommt. Bei einem Einzelplatzrechner ist die Entscheidung einfach: 127.0.0.1 geht über das Loopback-Device lo, der Rest über die Default-Route über eth0 oder Ähnliches. Router mit vielen Netzwerkkarten müssen hier komplizierter entscheiden.