Sicher zur Arbeit

Mit UMTS kommt man nicht nur mobil ins Internet, sondern auch über verschlüsselte Verbindungen, Virtual Private Networks, in Firmennetze. So kann man unterwegs zum Beispiel auf Firmen-Datenbanken und Fileserver zugreifen oder an der Mail-Kommunikation teilnehmen, als wäre man im Büro.

Ob Funk, Telefonleitung, Kabelmodem oder DSL – Netzwerk-Anwendungen sollten eigentlich keinen Unterschied zwischen den Medien "merken" und sich daher auf allen gleich verhalten – denn "ein Netz ist ein Netz ist ein Netz". Doch Virtual Private Networks (VPN), die auf Mobilfunkverbindungen aufsetzen, funktionieren nicht immer im ersten Anlauf. Wir haben gängige VPN-Software mit allen hiesigen Mobilnetzbetreibern geprüft und festgestellt, dass sich nicht jede für alle vier Netze eignet. Auch lässt sich die Funktion der VPN-Programme im Mobilbetrieb durch angepasste Einstellungen verbessern.

Mobile VPN-Verbindungen kann man sowohl über UMTS- als auch über GSM-Netze mittels diverser Verfahren und Geräte aufbauen. Laptops sowie die meisten PDAs bringen keine Mobilfunkmodems mit, sodass man zu Handys oder Steckkarten für den PC-Card-Slot greift. Handys kann man über Infrarot, Kabel und Bluetooth ankoppeln. Eine interessante Alternative zu PDAs und Notebooks sind mobile Geräte, die nicht nur das Mobilfunkmodem enthalten, sondern auch eigene VPN-Software mitbringen, beispielsweise die Nokia-Smartphones 6260, 6630, 9500 oder auch Funk-PDAs mit dem Betriebssystem Windows Mobile 2003 (etwa HP iPAQ hw6515, Acer n50, O2 XDA IIi, Asus MyPal 730w, Dell Axim X50v oder T-Mobile MDA Compact).

Wie in anderen Netzen auch kommen im Mobilfunk verbindungsorientierte oder paketorientierte Verfahren zum Einsatz. Verbindungsorientierte belegen die Datenfunkkanäle dauerhaft, auch wenn keine Daten befördert werden, wird die Funkressource in Anspruch genommen – etwa so wie bei Sprachverbindungen. Bei paketorientierten können die Mobilnetze Datenkanäle automatisch kurzfristig abschalten, beispielsweise während Surf-Pausen; dann sind nur Signalisierungskanäle geöffnet, sodass Datenkanäle bei Bedarf automatisch geöffnet werden. Die Hersteller von Steckkarten, Handys und Smartphones favorisieren die (teureren) paketorientierten Verfahren bei denen die übertragene Datenmenge berechnet wird. Dabei ist der Mobilnetzbetreiber, dessen SIM-Karte man benutzt, zugleich der Internet-Provider.

Mit dem bei größeren Datenmengen preisgünstigeren verbindungsorientierten High Speed Ciruit Switched Data (HSCSD), kann man wie mit einem Festnetzmodem beliebige Einwahlknoten mit Ortsvorwahlnummern "anrufen", zum Beispiel die in vielen Orten eingerichteten Einwahlknoten von Arcor [1]. Manche Unternehmen machen sich das zu Nutze und bieten ihren Außendienstlern direkten Zugang zum Firmennetz über eigene Einwahlmodems. Eine VPN-Software ist dann nicht erforderlich, weil die Daten nicht über das öffentliche Internet geleitet werden. HSCSD gibt es aber nur bei E-Plus und Vodafone. Je nach Netzlast und Infrastruktur lassen sich maximal 57,6 KBit/s empfangen und maximal 28,8 KBit/s senden.

Für HSCSD eignen sich nur wenige Endgeräte. Der große "Rest" besteht aus zwei Gruppen für paketorientierte Verbindungen: einfache Geräte für GPRS sowie Kombigeräte, die vornehmlich für UMTS gedacht sind, aber außerhalb des Deckungsbereichs automatisch auf GPRS umschalten. Die Netzbetreiber berechnen UMTS- und GPRS-Übertragungen gleich, lediglich die Übertragungsgeschwindigkeiten unterscheiden sich. Tipps zur Auswahl von Volumen- und Zeittarifen für den mobilen Internetzugang haben wir online veröffentlicht [2]. UMTS liefert bis zu 384 KBit/s und sendet bis zu 64 KBit/s. GPRS erreicht je nach Gerät bis zu 53,6 KBit/s.

Sinngemäße Übersetzung

Trotz der vielen Gerätevarianten gibt es bei VPN-Verbindungen eine Gemeinsamkeit: Man wählt sich zunächst ins Internet ein und baut dann die VPN-Verbindung zur Firma auf. Nutzt man als Träger Mobilfunkverbindungen – also UMTS oder GPRS -, bekommt man vom Einwahlrouter des Providers eine IP-Adresse, in der Regel aus einem privaten Bereich, etwa 10.0.0.0/8. Solche Adressen sind im Internet nicht sichtbar, ein Host kann von dort aus unter dieser Adresse nicht erreicht werden.

PPP-Brücke: L2TP over IPSec befördert PPP-Pakete durch IPSec-Tunnel.

Um trotzdem eine Kommunikation mit dem Internet zu ermöglichen, vermitteln Router zwischen dem privaten Netz und dem öffentlichen Internet mittels Network Address Translation (NAT) – und gerade von der NAT-Technik des Routers hängt es ab, ob VPN funktioniert oder nicht.

Network Address Translation spart öffentliche IP-Adressen auf Providerseite, und Clients genießen automatisch einen gewissen Schutz, denn von außen eintreffende Pakete, die nicht zu einer vom Client angestoßenen Verbindung gehören, werden vom NAT-Router verworfen – also auch Pakete von Angreifern.

Dass dieser Schutzwall gegeben ist, sollte man aber nicht voraussetzen. Während unseres mehrwöchigen Testbetriebs lieferten zwar E-Plus, O2 und Vodafone wie erwartet private IP-Adressen, aber das T-Mobile-Netz versorgte unsere Clients mit öffentlichen. Da alle Mobilnetzbetreiber diesen Netzwerk-Parameter ebenso wie andere unangekündigt ändern können, sollte man auf den Clients vorsichtshalber Firewalls einrichten. Von "Nachbarn", die im gleichen Mobilnetz online sind, dürfte keine Gefahr ausgehen, weil die NAT-Router der Mobilnetzbetreiber die Pakete nicht unter den Clients weiterleiten.

Im Normalfall weisen die Provider private Adressen zu. Damit Clients mit Adressen aus privaten Netzen ins Internet kommen, bildet ein NAT-Router alle internen, privaten IP-Adressen auf eine öffentliche IP-Adresse ab und manipuliert in den weiterzuleitenden Päckchen den vom jeweiligen Client gesetzten Quell-Port, an den er die anschließend eintreffende Antwort zustellen muss [3]. Dazu hält er diese Änderungen in einer Tabelle fest. Anhand der Tabelle kann er eingehende Antwortpakete dem Client zuordnen und also Zieladresse und -Port ersetzen. Aus Sicht des Internet sieht es aus, als würden alle Verbindungen von einer einzigen Maschine ausgehen.

Einfache Client-Server-Anwendungen, die einen festen Zielport benutzen, funktionieren reibungslos über NAT-Router. Probleme kommen jedoch bei Protokollen vor, die zum Beispiel für die Kontrolle der Verbindung und für die Übertragung von Nutzdaten unterschiedliche Ports nutzen (Multiport-Protokolle). Ein NAT-Router braucht dabei detaillierte Kenntnisse über das Protokoll und muss eingehende Päckchen wesentlich genauer analysieren, um zusammengehörige Verbindungen zu erkennen – also unter Umständen in den Headern die Zieladresse und die Zielports verändern, sodass sie den Weg zum Client finden (Passthrough).

Intelligente Router sind zwar mit diversen Passthrough-Verfahren gerüstet, aber nicht jeder Mobilnetzbetreiber setzt solche Router ein, sodass Multiport-Protokollen gelegentlich Riegel vorgeschoben sind. Deshalb stellen wir zunächst die unterschiedlichen VPN-Protokolle vor und erklären, ob und wie gut sie sich für NAT-Umgebungen eignen.

VPN und NAT

Bei IPSec laufen der Schlüsselaustausch und die Authentifizierung über den UDP-Port 500 ab. Die VPN-Tunnelpakete werden über Encapsulating Security Payload (ESP) übertragen, ein separates IP-Protokoll ohne Portnummern.

In NAT-Umgebungen stößt IPSec typischerweise auf zwei Probleme: Ältere Router wissen mit ESP-Paketen nichts anzufangen und verwerfen sie. Moderne Router können sie zwar durchreichen, aber weil sie während des IKE-Schlüsselaustauschs die Port-Nummer verändern, scheitert der Verbindungsaufbau – IKE setzt voraus, dass beide Seiten über Port 500 kommunizieren.

Zudem scheitern NAT-Router an der Zuordnung der Tunnel-Pakete zu den einzelnen Clients, weil die dafür erforderliche Information während des gegenüber Dritten abgesicherten Schlüsselaustauschs übertragen werden; die NAT-Router können die SPI-Werte nicht mitlesen (Security Parameters Index, ein Wert, mit dem Tunnel zu Hosts zugeordnet werden) und wissen also nicht, wem sie die einzelnen Pakete zuordnen sollen.

Behelfsmäßig bieten manche NAT-Router ein einfaches IPSec-Passthrough an, bei dem nur ein bestimmter Client eine IPSec-Verbindung aufbauen darf. ESP-Pakete werden automatisch nur an diesen Client weitergeleitet, und die IP-Adresse wird für diesen Client umgeschrieben. Zwar ist unklar, ob die in den Mobilnetzen eingesetzten Router diese Minimalversion des IPSec-Passthrough beherrschen, aber selbst wenn sie das tun, dürfte es in der Praxis keinen Wert haben, denn man kann davon ausgehen, dass in jedem Mobilnetz zumindest zeitweise mehr als ein Teilnehmer IPSec nutzen möchte.

In NAT-Umgebungen ist das ursprüngliche IPSec daher kaum noch gebräuchlich. Vielmehr setzt man es dabei nur mit der IPSec-Erweiterung NAT-Traversal ein, die in den beiden RFCs 3947 und 3948 spezifiziert ist. Dabei werden ESP-Pakete in UDP-Pakete verpackt und über Port 4500 verschickt; NAT-Router können dabei sowohl IP-Adressen als auch Ports bedarfsgerecht umschreiben. IPSec mit NAT-Traversal funktioniert mit praktisch jedem NAT-Router und hat auch in unseren Tests in allen vier Mobilnetzen geklappt.

Gestapelte Verbindungen

Microsoft setzt IPsec meist in Kombination mit dem Layer 2 Tunneling Protocol ein (L2TP), das eine Punkt-zu-Punkt-Verbindung zwischen zwei virtuellen Netzwerkschnittstellen durch den IPSec-Tunnel führt. Windows-XP-Rechner mit dem Service Pack 2 bringen L2TP/IPSec inklusive NAT-Traversal mit. Für ältere Windows-Versionen ist ein Patch erhältlich [4]. Wenn man IPSec mit NAT-Traversal kombiniert, stellen NAT-Router für dieses Protokoll-Paar kein Hindernis dar.

Weil die SPI-Werte zu Beginn der IPSec-Verbindung verschlüsselt übertragen werden, kann sie ein NAT-Router später, wenn sie im ESP-Datenstrom benutzt werden, nicht zuordnen.

Das Point-to-Point Tunneling Protocol (PPTP) ist ein VPN-Verfahren für Remote Access und setzt eine verschlüsselte PPP-Brücke auf. Die Kommunikation ist zweigeteilt: Der Client öffnet eine Kontrollverbindung zum Server über den TCP-Port 1723; als Quell-Port kann er einen beliebigen freien benutzen (z. B. 3283, siehe Grafik "Zweigeteilt" auf der folgenden Seite). Anschließend baut er eine GRE-Verbindung auf (Generic Routing Encapsulation, ein IP-Protokoll ohne Portnummern) und tunnelt darüber PPP-Pakete.

Die Problemquellen sind ähnlich denen des herkömmlichen IPSec, nämlich die Annahme von GRE-Paketen sowie deren Zuordnung zu den Clients. Manche Router nehmen GRE-Pakete nicht an und verwerfen sie kommentarlos. Anders als bei IPSec lassen sich Tunnelpakete jedoch einfach zuordnen, weil PPTP die zugehörigen Kenndaten unverschlüsselt befördert (Call ID, eine Art Kanalnummer, z. B. 49152, siehe Grafik "Zweigeteilt"). Moderne NAT-Router führen daher eine Liste der von Clients verwendeten Call IDs und übersetzen sie bedarfsgerecht – das bezeichnet man mit PPTP Passthrough respektive PPTP mit NAT. So kann ein NAT-Router gegenüber dem PPTP-Server reibungslos mehrere Clients repräsentieren.

In der Praxis kann man sich nicht darauf verlassen, dass jeder Router die NAT-Umsetzung durchführt, auch wenn er technisch dazu in der Lage sein sollte – der Betreiber muss das halt auch wollen. Beispielsweise stellte sich bei unseren Tests ein Problem im O2-Netz heraus – PPTP-Tunnel ließen sich nicht aufbauen. Die VPN-Verfahren IPSec mit NAT-Traversal, OpenVPN und L2TP over IPSec spielten dagegen im O2-Netz. In den übrigen drei Netzen ließen sich alle vier VPN-Kandidaten reibungslos nutzen.

Den SSL/TLS-basierten VPN-Protokollen wie zum Beispiel Browser-VPNs stellt sich die Network Address Translation kaum als Hürde dar. Da sie nur einen Zielport verwenden, funktionieren sie in der Regel anstandslos, etwa wie HTTPS-Verbindungen. Auch die beliebte Open-Source-Lösung OpenVPN funktioniert reibungslos mit NAT sowie in den vier Mobilnetzen. Sie nutzt nämlich ebenfalls nur einen, frei wählbaren UDP- oder TCP-Port (in der Grundeinstellung Port 1194).

port 1194
proto udp
dev tun
ca my-ca.pem
cert servercert.pem
key serverkey.pem
dh dh1024.pem
server 10.12.34.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.1.1Ó
keepalive 30 300
auth SHA1
cipher AES-128-CBC
comp-lzo
verb 3
tun-mtu 1300

Mobilitätsprobleme

NAT allein erklärt nicht alle Probleme von VPN-Netzen über Mobilfunkverbindungen. Im Unterschied zu einer Festnetzleitung schwankt im Mobilfunk der Durchsatz erheblich, die Verzögerungen sind höher und Verbindungsabbrüche häufiger. Bei GPRS-Verbindungen verstreichen nach einer Anfrage zwischen 400 und 1000 Millisekunden bis zur Antwort. Im kabelgebundenen Internet sind dagegen Werte unter 100 ms die Regel; bei UMTS sind es immerhin noch 200 bis 300 ms.

Zweigeteilt: Dass PPTP neben TCP auch noch das GRE-Protokoll nutzt, stellt manche NAT-Router vor Probleme.

Diese teils dürftigen und teils drastisch wechselhaften Rahmenbedingungen beeinflussen aber lediglich den Arbeitskomfort, sie bringen das VPN nicht aus dem Tritt. Erst wenn man in schlecht erschlossenen Gebieten mit vielen Funklöchern unterwegs ist, wird man auch häufige VPN-Verbindungsabbrüche verzeichnen mit der Folge, dass man mehr Gelegenheit bekommt, als einem lieb ist, die Kennungen und Passwörter für die verschiedenen Dienste des Firmennetzes zu üben.

In solchen Fällen, etwa auf Bahnstrecken mit vielen langen Tunneln ohne Mobilfunkversorgung, empfiehlt es sich, die Frist auszudehnen, nach der die VPN-Verbindung gekappt wird, wenn zwischenzeitlich keine Daten eingetroffen sind. Weil dieser Parameter nicht zwischen Client und Server ausgetauscht wird, sollte man ihn sowohl auf Server- als auch auf Client-Seite auf den gleichen Wert erhöhen – sonst ist nur der kürzere wirksam. Damit Festnetzverbindungen nicht unnötig lax gehandhabt werden, legt man für diese gesonderte Parameter fest.

Beispielsweise kann man für die IPSec-Implementierungen strongSwan und Openswan die Standardwerte für keepalive in der Datei /etc/ipsec.conf für jede einzelne Verbindung spezifizieren. Für VPN-Verbindungen über das Festnetz legt man einen gesonderten "conn"-Eintrag mit dem Standardwert von zwei Minuten an – dpdtimeout=120. In einem zweiten "conn"-Eintrag für Mobilfunkverbindungen stellt man eine höhere Frist ein, zum Beispiel dpdtimeout=300. Alle anderen Parameter bleiben gleich.

Bei OpenVPN findet sich die Konfigurationsdatei im Ordner /etc/openvpn/, der Name ist frei wählbar. Wenn Sie die Software so eingerichtet haben, wie in unserem separaten Beitrag beschrieben [5], dann heißt sie server.conf respektive client.conf.

Zusammengefasste Bits

Damit sind die Maßnahmen für ein robustes VPN-Verhalten getroffen. Zusätzlich kann man den gegenüber Festnetzverbindungen deutlich niedrigeren Durchsatz durch Kompression erhöhen, sowohl bei IPSec und PPTP als auch bei OpenVPN. Dabei wird vor dem Verschlüsseln das zu versendende Paket komprimiert und auf der Gegenseite nach der Entschlüsselung dekomprimiert. Daraus resultiert eine subjektiv höhere Übertragungsgeschwindigkeit, weil die Kompression, Übertragung und Dekompression weit schneller ablaufen als die Übertragung der nichtkomprimierten Daten. Dies gilt nur für Daten, die sich effektiv komprimieren lassen – bei Bildern und ZIP-Archiven bietet die Kompression keinen Vorteil.

Bei PPTP-Verbindungen wird das von Microsoft spezifizierte Verfahren MPPC (Microsoft Point-to-Point Compression) automatisch zwischen Client und Server ausgehandelt – ist es Server-seitig eingerichtet, wird es auch genutzt. Bei den IPSec-Implementierungen strongSwan und Openswan muss man in der Konfigurationsdatei /etc/ipsec.conf die Option "compress=yes" eintragen. Wer Racoon einsetzt, trägt in /etc/racoon/racoon.conf "compression_algorithm deflate" ein.

Die zurzeit erhältlichen Versionen von OpenVPN sind von Haus aus für die Kompression vorbereitet und inzwischen Bestandteil gängiger Linux-Distributionen. Wer eine ältere nachrüsten will, etwa Suse 9.0, findet über rpmfind.net aktuelle RPM-Pakete mit lzo-Kompression [6]. Startet man OpenVPN mit der Option "-comp-lzo", wird die Kompression eingeschaltet.

Smart ins VPN gehen

Setzt man ein Laptop in Verbindung mit Handys oder Mobilfunkkarten ein, kann man sowohl mit Linux als auch mit Windows alle genannten VPN-Techniken nutzen. Auf Handhelds sind nicht alle VPN-Verfahren für beide genannten Betriebssysteme angepasst. Besitzer des Linux-bewehrten Sharp Zaurus können in Kombination mit der Software des Poptop-Projekts [7] PPTP-Verbindungen aufbauen und mit dem Client des Openswan-Projekts [8] sind IPSec-Verbindungen möglich. Berichte über den Einsatz von OpenVPN auf dem Zaurus sind ebenfalls im Internet zu finden [9]. Besitzer von Windows-Mobile- und PalmOS-Geräten können nur zwischen PPTP und IPSec wählen; OpenVPN ist bisher nicht auf diese Plattformen portiert worden.

VPN für die Faust: Der IPSec-Client von NCP eignet sich auch für NAT-Umgebungen.

Weil Handhelds und Smartphones auf Basis von Windows Mobile 2003 verbreitet sind, halten viele Benutzer die VPN-Technik bereits buchstäblich in der Hand. Die Premiumversion von Windows Mobile 2003 (Second Edition) eignet sich sowohl für PPTP als auch für L2TP over IPSec. IPSec lässt sich damit wahlweise mit Pre-Shared Keys (PSK) oder mit X.509-Zertifikaten nutzen, wobei die Einrichtung von Zertifikaten deutlich aufwendiger ist. Eine Anleitung dafür sowie eine Übersicht darüber, welche Versionen VPN unterstützen, ist unter [10] veröffentlicht.

In allen Fällen baut der in Windows Mobile integrierte Connection Manager sowohl die Internet- als auch die VPN-Verbindung automatisch auf. Dabei gibt es allerdings auch Stolperfallen, denn Bedienung und Einrichtung des Connection Managers sind nicht gerade intuitiv.

Alternativ zu dem im Betriebssystem verankerten VPN-Client von Microsoft gibt es nachrüstbare Clients; auch für PalmOS. Als Beispiel für Windows Mobile sei der IPSec-Client der Firma NCP genannt. Er wartet mit PSK, X.509 und auch mit NAT-Traversal auf, sogar Dead Peer Detection ist integriert (DPD). Mittels DPD werden automatisch Keepalive-Nachrichten zwischen Client und Server gesendet, sodass beide "wissen", dass die Verbindung zur Gegenstelle noch steht. Bleiben Keepalive-Nachrichten aus, kann man umgehend davon ausgehen, dass die Verbindung abgebrochen ist; es müssen also keine Fristen ausgewertet werden (Timeouts). Zudem verhindert DPD in NAT-Szenarien Abbrüche durch den Router, denn da Keepalive-Pakete auch dann über den Tunnel gesendet werden, wenn keine VPN-Nutzdaten zu befördern sind, kommt es nicht zu Fristüberschreitungen. Der Quellport für die Tunnelpakete bleibt im Router also ständig geöffnet.

Fazit

Die Mehrzahl der gängigen VPN-Verfahren lässt sich im Mobilfunk problemlos einsetzen, freilich handelt es sich um jüngere Verfahren, bei denen die NAT-Problematik berücksichtigt ist. In einem Fall ließ sich PPTP nicht nutzen, und IPSec sollte man grundsätzlich mit der Erweiterung NAT-Traversal verwenden. Die Beobachtungen gelten natürlich nur für die Mobilnetze in Deutschland, bei ausländischen Betreibern kann das anders aussehen. VPN-Verfahren, die nur einen Port öffnen, also OpenVPN oder SSL-VPN, dürften aber auch in fremden Mobilnetzen funktionieren. Passt man ferner einige Verbindungsparameter an, sind Tunnel zu Firmennetzen auch zuverlässig. Welche Lösung für den mobilen Einsatz am besten geeignet ist, hängt letztlich von den eingesetzten Geräten, der Verfügbarkeit entsprechender Clients für die jeweiligen Betriebssysteme und nicht zuletzt vom Budget ab. (dz)

Literatur