© photocase.com

Dass OpenVPN zu mehr taugt als für simple virtuelle Netze, bestätigt ein trickreiches Szenario. Es wertet kurzerhand einen vermeintlich beschränkten WAP-Zugang zu einer kompletten IP-Anbindung auf, die sogar das Mitlauschen des Netzbetreibers verhindert.

Schade, wenn sich hinter der erhofften Handy-Internet-Flatrate in Wahrheit nur ein lausiger WAP-Zugang verbirgt. Gestandene Netzwerker hindert das aber nicht daran, nach Herzenslust mit allen erdenklichen Protokollen im Internet zu arbeiten und dabei auch Schnüffelei am WAP-Gateway zu unterbinden. Ihr wichtigstes Werkzeug ist OpenVPN ([1] bis [3]) zusammen mit geschicktem Tunneln und Routing. Die folgenden Betrachtungen bedienen sich zu Demonstrationszwecken der O2-WAP-Flatrate (Abbildung 1 und [4]), passen aber auch auf andere Angebote.

Abbildung 1: Ein nettes Angebot: Das Surf & E-Mail-Paket von O2 kostet 4,95 Euro im Monat bei unbegrenztem Datenvolumen. Jedoch gilt es, wie bei allen Mobilfunk-Angeboten, das Kleingedruckte zu studieren.

GPRS (General Packet Radio Service, siehe Kasten “GPRS”) ist fast flächendeckend verbreitet und damit trotz beschränkter Bandbreiten für viele Datennomaden eine interessante Online-Option. Für den Zugang sorgen ein Modem-fähiges Mobiltelefon (für diesen Artikel getestet mit einem Nokia 6680) oder eine Datenkarte für GPRS oder UMTS (Universal Mobile Telephone Service, [5], [6]). Die erste Variante verlangt eine Verbindung zwischen Telefon und Laptop, je nach Gerät klappt das per Bluetooth (BT), Infrarot (Irda), USB oder seriellem Kabel. Eine GPRS- oder UMTS-Karte setzt einen passenden Schacht im Laptop voraus. Zudem sollte der Linux-Kernel die Karte unterstützen.

Steht die Verbindung zum Einwahl-Device, muss es die Anweisungen für die GPRS-Verbindung erhalten. Das übernimmt traditionellerweise der PPP-Daemon mit einem Skript. Anschließend stehen einige zusätzliche Routing-Konfigurationen an. Ein geschickt angepasstes OpenVPN sorgt für den Rest.

Handy als Modem

Am besten verbinden sich Laptop oder PC mit dem Mobiltelefon per Bluetooth. Fehlt dieser Drahtlosfunk am Rechner, dann rüsten ein USB-Dongle oder eine PCMCIA-Steckkarte diese Fähigkeit problemlos nach. Dank der drahtlosen Verbindung bleibt das Telefon frei für optimalen Empfang positionierbar. Die Verbindung mittels Kabel (USB oder seriell) ist unhandlicher, dafür leidet der Akku des Mobiltelefons weniger.

Bluetooth richten die meisten Distributionen inzwischen automatisch ein. Bei einigen Dongles oder Karten muss der Anwender eventuell die Firmware nachinstallieren. Umfangreiche Hilfe geben die Projektseiten zum Linux-Bluetooth-Stack ([7] bis [9]). Das Kommando »hciconfig« (Listing 1, Zeile 1) zeigt anschließend die Daten der Schnittstelle. Alternativ reicht auch der Aufruf »hcitool dev« (Zeile 8), der bei Erfolg die MAC-Adresse des BT-Dongle ausgibt.

01 # hciconfig
02 hci0:   Type: PCCARD
03         BD Address: 00:04:76:C8:4A:E8 ACL MTU: 128:8  SCO MTU: 64:8
04         UP RUNNING PSCAN ISCAN AUTH ENCRYPT
05         RX bytes:1046 acl:0 sco:0 events:58 errors:0
06         TX bytes:850 acl:0 sco:0 commands:35 errors:0
07 
08 # hcitool dev
09 Devices:
10         hci0    00:04:76:C8:4A:E8
11 
12 # hcitool scan
13 Scanning ...
14         00:0E:07:47:93:1B       BT-Phone
15 
16 # l2ping 00:0E:07:47:93:1B
17 Ping: 00:0E:07:47:93:1B from 00:04:76:C8:4A:E8 (data size 20) ...
18 0 bytes from 00:0E:07:47:93:1B id 200 time 63.05ms
19 0 bytes from 00:0E:07:47:93:1B id 201 time 48.13ms
20 0 bytes from 00:0E:07:47:93:1B id 202 time 45.13ms
21 3 sent, 3 received, 0% loss
22 
23 # hcitool cc 00:0E:07:47:93:1B
24 # hcitool dc 00:0E:07:47:93:1B

Als einfachen Test prüft »l2ping« (Zeile 16), ob das Mobiltelefon auf Pings an seine MAC-Adresse antwortet. Diese MAC ist am schnellsten durch einen Scan der Umgebung herauszubekommen (Zeile 12). Damit es klappt, muss die lokale Nahfunk-Fähigkeit auf dem Handy aktiviert sein. Nach einer gewissen Verzögerung sollte sich mindestens das eigene Gerät melden.

Paare finden sich

Anschließend wird es Zeit, die beiden Geräte zu paaren (Pairing). Dieser Vorgang führt zu einer verschlüsselten Verbindung mit Shared Secret; ohne erfolgreiches Pairing ist kein Datenaustausch möglich. Wieder ist das Kommando »hcitool« zuständig, das nun dringend Administrator-Rechte benötigt.

Der Parameter »cc« (Listing 1, Zeile 23) dient dem Verbindungsaufbau zum Gerät mit der MAC-Adresse 00:0E:07:47:93:1B. Kennt das Mobiltelefon die Gegenstelle nicht, fordert es den Benutzer auf das Passwort einzugeben, das er am PC in »/etc/bluetooth/pin« hinterlegt hat. Als Code taugen nur Zahlen, sonst wird die Eingabe am Telefon schwierig.

Der Parameter »dc« in Zeile 24 löst die Verbindung wieder. Damit hat sich das Telefon den Partner gemerkt und zum Verbindungsaufbau genügt das Kommando »rfcomm« – bis sich der Rechnername ändert oder ein neuer Dongle im Computer steckt. In dem Fall müsste der Anwender das Passwort für ein erneutes Pairing eingeben.

Über die Bluetooth-Strecke gilt es nun, eine serielle Verbindung aufzubauen: »rfcomm connect 1 00:0E:07:47:93:1B 1« erledigt das. Es quittiert den Vorgang mit folgender Ausgabe:

Connected /dev/rfcomm1 to 00:0E:07:47:93:1B on channel 1
Press CTRL-C for hangup

Das Kommando legt bei einem erfolgreichen Aufruf eine serielle Schnittstelle an, im Beispiel »/dev/rfcomm1«. Auf diese greift im nächsten Schritt der PPP-Daemon zu.

Traditionell übernimmt der PPP-Daemon die Internet-Einwahl, egal ob mit klassischem Modem, ISDN oder GPRS. Die meisten Distributionen halten die Konfiguration unterhalb des »/etc/ppp«-Verzeichnisses vor. Die Skripte »ip-up« und »ip-down« führt der PPP-Daemon nach erfolgreichem Auf- und Abbau der Verbindung aus. Wer zu diesem Zeitpunkt weitere Aktionen triggern will, legt zwei Skripte »ip-up.local« und »ip-down.local« im selben Verzeichnis an.

Gesprächige Skripte

Je nach Distribution landen die Chat-Skripte für die Unterhaltung mit dem Modem in einem eigenen Unterverzeichnis oder ebenfalls in »/etc/ppp«. Üblicherweise ist hierfür das Verzeichnis »peers« vorgesehen. Eine bei der Einwahl nötige Authentifizierung mit Username und Passwort verhandeln Computer und Einwahlserver per PAP (Password Authentication Protocol) oder besser per CHAP (Challenge Authentication Protocol). Die Daten hierfür landen in den nur für Root lesbaren Dateien »pap.secrets« oder »chap.secrets«.

Die meisten Mobilfunkanbieter arbeiten ohne Authentifizierung, da sich der Nutzer bereits mit seiner SIM-Karte (Subscriber Identification Module) eindeutig ausweist. Im »peers«-Unterverzeichnis dürfen mehrere Provider-Profile liegen, der »call«-Parameter beim Aufruf des PPP-Daemon wählt den gewünschten Provider. Für das Beispiel hieß die Datei bei den Autoren »o2-gprs«. In dieser Datei stehen eine Reihe von PPP-Verbindungsoptionen und die Namen der Chat-Skripte (Listing 2, Zeile 14 und 23). Diese Skripte sind in den Listings 3a und 3b abgedruckt.

01 #/etc/peers/o2-gprs
02 hide-password
03 noauth
04 debug
05 #/dev/ircomm0  # IRDA
06 #/dev/ttyS0    # serielles Kabel
07 /dev/rfcomm1   # Bluetooth
08 # Serial port line speed
09 115200
10 nocrtscts # IrDA
11 # To keep pppd on the terminal
12 nodetach
13 # Connect script
14 connect "/etc/ppp/peers/gprs-o2wap-connect"
15 # pppd must not propose any IP address to the peer!
16 noipdefault
17 # Accept peers idea of our local address
18 ipcp-accept-local
19 ipcp-accept-remote
20 # Ignore carrier detect signal from the modem
21 local
22 # Disconnect script
23 disconnect "/etc/ppp/peers/gprs-o2wap-discon"
24 remotename gprs
25 ipparam gprs
26 mtu 660
27 lcp-echo-failure 0
28 lcp-echo-interval 0

01 #!/bin/sh
02 # /etc/ppp/peers/gprs-o2wap-connect
03 exec chat 
04    TIMEOUT   5                             
05    ECHO      ON                            
06    ABORT     'nBUSYr'                    
07    ABORT     'nERRORr'                   
08    ABORT     'nNO ANSWERr'               
09    ABORT     'nNO CARRIERr'              
10    ABORT     'nNO DIALTONEr'             
11    ABORT     'nRINGINGrnrnRINGINGr'  
12    ''        rATZ                         
13    TIMEOUT   12                            
14    SAY       "Press CTRL-C to close the connection at any stage!" 
15    SAY       "ndefining PDP context...n" 
16    OK        'AT&F'                        
17    OK        'ATV1E0S0=0&D2&C1'            
18    OK        AT+CMEE=1                     
19    OK        'AT+cgdcont=1,"IP","wap.viaginterkom.de"'  
20    OK-AT-OK  ATD*99***#                    
21    SAY       "nwaiting for connect...n"  
22    CONNECT   ""                            
23    SAY       "nConnected."                
24    SAY       "nIf the following ppp negotiations fail,n" 
25    SAY       "try restarting the phone.n"

01 #!/bin/sh
02 # /etc/ppp/peers/gprs-o2wap-discon
03 exec chat 
04    ABORT     "BUSY"          
05    ABORT     "ERROR"         
06    ABORT     "NO DIALTONE"   
07    SAY       "nSending break to the modemn" 
08    ""        "K"            
09    ""        "+++ATH"        
10    SAY       "nPDP context detachedn"

AT-Kommandos

Das Handy-Modem verwendet spezielle AT-Befehle, etwa um den GPRS-Modus zu aktivieren. Als Telefonnummer dienen der Code »*99***CID#« oder »*98*CID#«. Das Kürzel CID steht für die Nummer des im Handy angelegten GPRS-Datenkontos. Es ist meist möglich, auf die CID zu verzichten – so geschehen im vorliegenden Beispiel (Connect-Skript in Listing 3a, Zeile 20). Als Basis für dieses Skript diente [10].

Der Modembefehl »+cdgcont=1, “IP”, “Internet”« (Zeile 19) wählt den APN aus (Access Point Name), an den die Verbindung geht. Einige Telefone, etwa das Nokia 6310i, verlangen, dass die Angabe des Datenkontos hinter »cdgcont« unterbleibt. Hier heißt die Eingabe also »+cdgcont=, “IP”, “Internet”«. In einem Anbieternetz kann es durchaus verschiedene Accesspoints geben: O2 kennt »internet« für den allgemeinen Internetzugang sowie »wap.viaginterkom.de« für spezielle WAP-only-Pakete [4], zu denen auch die Flatrate gehört.

Die Verbindung startet per »pppd call o2-gprs«. In Abbildung 2 ist die Ausgabe des Chat-Skripts zu sehen. Ging alles bei der Initialisierung des Mobiltelefons glatt, erscheinen die Debug-Meldungen der PPP-Verbindung, die sich über den Debuglevel in der Konfiguration steuern lassen. Zu sehen sind die Übermittlung der lokalen und der Gegenstellen-IP sowie je nach Art des Accesspoints die Übertragung der IP-Adressen der DNS-Server des Providers. Bei passender Konfiguration trägt der »pppd« die DNS-Server in »/etc/resolv.conf« ein und legt ein Backup der Ursprungsdatei an.

Abbildung 2: Der PPP-Daemon kümmert sich um die Aufnahme der Verbindung zum Accesspoint und die anschließende IP-Konfiguration. Üblicherweise erfährt er dabei die IP des Clients und das Gateway, bei klassischer Internet-Einwahl zusätzlich bis zu drei DNS-Serveradressen.

Sparversion ohne DNS

Wählt sich der Kunde nur in einen WAP-Dienst ein, teilt ihm der Server üblicherweise keine DNS-Dienstadressen mit. WAP leitet alle Verbindungen über einen Proxy, der sich unter anderem um die DNS-Auflösung kümmert. Es bleiben zwei Möglichkeiten: Einen DNS-Server fest einstellen und den »pppd« daran hindern, die »resolv.conf« zu ändern, oder das Einwahlskript »ip-up.local« so ändern, dass es den bevorzugten DNS selbst einträgt.

Ob die Einwahl geklappt hat, zeigt die Ausgabe von »ifconfig«. Das Device »ppp0« sollte eine öffentliche IP-Adresse haben und im Up-Zustand sein. Noch leitet das Routing im Kernel per Default den Verkehr an diesem Interface vorbei. Der PPP-Daemon kann das zwar ändern und die Defaultroute anpassen. Das geht aber schief, wenn der Server keine Remote-IP übermittelt. Dann würde der »pppd« versuchen die Defaultroute auf eine sinnlose PPP-Defaultadresse zu legen. An dieser Stelle wäre ein Routing auf die eigene lokale PPP-IP sinnvoller.

Per Default durchs Handy

Genau diesen Weg beschreitet das Skript »ip-up.local« aus Listing 4. Es erhält folgende Parameter vom aufrufenden Skript »ip-up« übermittelt: »$1« ist der Interfacename, in den meisten Fällen »ppp0«. In »$2« steht das TTY-Device, es hängt von der Art der Verbindung zum Modem ab. »$3« enthält die Geschwindigkeit. »$4« und »$5« sind relevant: Die lokale und die ferne IP-Adresse. In »$6« stehen noch Parameter, so der Name der Datei beim PPP-Call (im Beispiel »o2-gprs«). Zeile 8 in Listing 4 setzt die Defaultroute entsprechend auf die lokale PPP-IP-Adresse.

01 #!/bin/sh
02 # ip-up.local
03 case "$6" in
04    gprs*)
05       killall -9 privoxy 2&>1 >> $LOG
06       rcprivoxy start >> $LOG
07       modprobe tun
08       /sbin/ip route add 195.182.114.52 via $4
09       echo "/sbin/ip route add 195.182.114.52 via $4" >> $LOG
10       /sbin/ip route show >> $LOG
11       test -c /dev/net/tun || {
12          mkdir /dev/net;
13          mknod /dev/net/tun c 10 200; }
14       /usr/sbin/openvpn.wap --cd /etc/openvpn --config wap.conf >> $LOG &
15       #ip route add default via 10.8.0.2
16    ;;
17 esac

Die Privoxy-Arbeit in den Zeilen 5 und 6 erklärt ein Abschnitt gegen Ende des Artikels. Das Skript könnte auch die oben angesprochenen DNS-Server eintragen. Je nach Tarif sind Routing und DNS aber gar nicht wichtig, da der Betreiber nur eine Verbindung zu dem WAP-Proxy (siehe Kasten “Proxy, WAP und Connect”) erlaubt und erst ein überlagertes VPN die IP-Anbindung ans Internet herstellt (Abbildung 3a).

Abbildung 3a: Per OpenVPN tunneln IP-Pakete unbeschadet und unbemerkt vom Providernetz über den WAP-Proxy zum OpenVPN-Server. Cleveres Routing gaukelt dem Laptop eine direkte Internetanbindung vor.

Für den Aufbau von virtuellen privaten Netzwerken hat sich neben dem umständliche IPsec das viel einfacher zu benutzende OpenVPN etabliert ([1] bis [3]). Es kommt auch gut mit Hindernissen zurecht, tunnelt beispielsweise durch HTTP-Proxies oder überwindet Network-Address Translation, wie sie an vielen Access-Routern auftritt.

OpenVPN überwindet Hinternisse

Das Hindernis im vorliegenden Fall ist WAP (Wireless Application Protocol). Waren lange Zeit das komplexe WAP 1.0 und seine teilweise inkompatiblen Nachfolger WAP 1.X Standard, so sind die Anbieter aufgrund des hohen Aufwands bei geringer Resonanz zu den Internetprotokollen zurückgekehrt. Das mittlerweile verbreitete WAP 2.0 lehnt sich stark an HTTP an und transportiert unfreiwillig auch OpenVPN-Verbindungen, die einen IP-over-WAP-Tunnel bereitstellen. Ganz ohne manuelle Anpassungen auf der Client-Seite klappt dieser Trick aber nicht. Zudem verlangt der Ansatz eine Gegenstelle im Internet, also einen Server, auf dem der Tunnel endet. Der Server dient dann als Gateway ins Netz (Abbildungen 3a und 3b).

Abbildung 3b: Beim Einsatz der Connect-Methode mit einem Proxy sendet der Client erst das Schlüsselwort »CONNECT«. Der Proxy baut daraufhin die Verbindung zum Server auf (2. und 3.). Bei erfolgreichem Verbindungsaufbau meldet er »200 Connection established« zurück.

OpenVPN muss auf dem Client und dem Gateway installiert sein. Da der Server auf Requests des Clients reagiert, genügt dort die Standardversion der jeweiligen Distribution. Er sollte aber die gleiche Versionsnummer tragen wie der Client, am besten Version 2.0.x. Der Provider-Proxy akzeptiert die Verbindung allerdings erst nach einer Änderung am OpenVPN-Client, daher steht beim Client das Kompilieren aus den Quellen auf dem Programm.

Client-OpenVPN

Die folgenden Beschreibungen beziehen sich auf das aktuelle OpenVPN 2.0.7, sollten aber leicht abgewandelt auch auf andere 2er Versionen passen. Die Sourcen hängen von ein paar Paketen ab. Debian-User installieren dazu »openssl-lib«, »lzo-lib« und »pthread« via »apt-get install Paketname«.

OpenVPN verwendet das so genannte TUN/TAP-Interface. Die meisten Distributionen haben dieses Kernelmodul schon in ihrem Standardumfang, andernfalls ist ein zusätzlicher Kompilierschritt fällig. Beim Kernel 2.6 versteckt sich das Modul im Untermenü »Device Drivers | Networking support | Universal TUN/TAP device driver support«.

Die Änderungen an OpenVPN beschränken sich auf die Datei »openvpn-2.0.7/proxy.c«. Der Proxy-Code gibt sich als Browser aus. Damit der O2-Proxy die Pakete akzeptiert, muss sich OpenVPN als WAP-Browser auf einem Handy tarnen. In den Zeilen 285 bis 288 stellt der Code die Connect-Anfrage zusammen, mit der er den Proxy anweist künftig alle Paket an die Zieladresse durchzureichen. In dieser Anfrage fehlt jegliche Angabe zum User-Agent. Steht Folgendes in den Zeilen 285 bis 288, gleicht die Anfrage der eines Sony-Ericsson-Telefons:

openvpn_snprintf (buf, sizeof(buf), "CONNECT %s:%d HTTP/1.1rnHost: %srnUser-Agent: Mozilla/1.22 (compatible; MSIE 5.01; PalmOS 3.0) EudoraWeb 2.1rnProfile: http://wap.sonyericsson.com/UAprof/P800R102.xml",
   host,
   port,
   host);

Anschließend übersetzt »./configure && make && make install« die Quellen und installiert das Programm.

Gut tarnen und den Proxy austricksen

OpenVPN kennt zwei Prinzipien, nach denen sich Client und Server authentifizieren und ihre Sitzungsschlüssel aushandeln: ein simples Preshared Secret und der Verbindungsaufbau mit X.509-Zertifikaten wie von SSL/TLS/HTTPS bekannt. Da das vorliegende VPN mit nur einem Tunnel sehr simpel ausfällt, genügt der Preshared-Secret-Modus.

Der Admin erzeugt einen symmetrischen Schlüssel und teilt diesen dem Client und dem Server mit. Diese einfache Methode ist zudem flotter, spart sie doch den langwierigen Austausch von Zertifikaten über die schmalbandige GPRS-Verbindung. Zertifikate sind hingegen für Setups anzuraten, bei denen viele Clients ein Gateway frequentieren.

Der Aufruf »openvpn –genkey –secret secret.key« erstellt einen 2048-Bit-Key und speichert ihn in der Datei »secret.key«. Diese muss der Admin anschließend auf Client und Server in das Konfigurationverzeichnis kopieren, also nach »/etc/openvpn«.

Die Enden des Tunnels

Eine für den OpenVPN-Server geeignete Konfigurationsdatei mit dem Namen »server.conf« ist in Listing 5a zu sehen. Der Server braucht im realen Internet eine bekannte IP-Adresse (Zeile 1); diese ist an die jeweiligen Gegebenheiten anzupassen. Die restlichen Einträge dürften meist passen.

01 local     192.168.0.120  # Gateway-IP
02 port      443
03 proto     tcp-server
04 dev       tun
05 secret    secret.key
06 ifconfig  10.8.0.1  10.8.0.2
07 link-mtu  620
08 keepalive 10 120
09 comp-lzo
10 status    openvpn-status.log
11 verb      3

Besonders erwähnenswert sind die Parameter »port« (Zeile 2), »comp-lzo« (Zeile 9) und »link-mtu« (Zeile 7). Da die Verbindung über GPRS läuft, dürfen die getunnelten Pakete nicht zu groß sein. Die Erfahrung zeigt, dass ein MTU-Wert (Maximum Transmission Unit) von 620 für gute Ping-Zeiten sorgt.

Zur Geschwindigkeitsoptimierung komprimiert OpenVPN dank »comp-lzo« die übertragenen Daten. Trickreich lauscht der OpenVPN-Server mit der vorliegenden Konfiguration auf Port 443. Der ist normalerweise für SSL-Verbindungen reserviert. Da bei echten SSL-Verbindungen auch Client und Server direkt verbunden sein müssen, erlaubt der Provider-Proxy den Connect.

Doppelt belegt

Wer den SSL-Port auf seinem Webserver nicht komplett für OpenVPN opfern will, kann durch DNAT (Destination Network Address Translation) den eingehenden Verkehr geschickt multiplexen. Die folgende IPtables-Regel leitet beispielsweise jeglichen vom O2-Gateway kommenden Traffic an den OpenVPN-Server weiter, der in diesem Alternativszenario auf Port 4443 lauscht.

Alle anderen anfragenden Clients (die nicht zum O2-Netz 82.113.100.0/24 gehören) bekommen den HTTPS-Zugang zu sehen, wie sie es erwarten:

iptables -t nat -A PREROUTING  -p tcp -s 82.113.100.0/24 --dport 443 -j DNAT --to 129.30.134.173:4443

Damit der OpenVPN-Server seine Konfiguration auch findet und verwendet, muss ihm der Aufruf den Namen und Ort der Datei mitteilen: »openvpn –cd /etc/openvpn –config server.conf«. Das TUN/TAP-Device des Gateway erhält daraufhin die IP-Adresse 10.8.0.1 (Zeile 6 in Listing 5a). Ein »ip route show«-Aufruf bestätigt das bei Bedarf (siehe auch Abbildung 4).

Abbildung 4: Zuerst bestätigt das Kommando »ip route show«, dass der Kernel die Pakete in den Tunnel senden will. Ein »ping« auf die TUN/TAP-IP-Adresse des OpenVPN-Servers gibt dann Gewissheit: Der Tunnel durch das WAP-2.0-Gateway steht.

Routen finden

Das Routing des Gateway muss die Pakete vom TUN/TAP-Device ins Internet leiten und die Rückrichtung ebenso bedienen. Dazu ist Paketweiterleitung (Routing) nötig, die global im Kernel zu aktivieren ist. Zudem braucht das Szenario Masquerading (SNAT, Source Network Address Translation), um die virtuellen Tunneladressen mit gültigen Netzwerkadressen zu ersetzen:

echo 1 >/proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0

Nun leitet Linux die Pakete des virtuellen TUN/TAP-Device an die reale Netzwerkschnittstelle des Gateway.

Damit der Tunnel zustande kommt, muss der Client eine Verbindung initiieren. Die läuft dann vom eigenen Rechner über das Handy und über den Provider-Proxy bis zum OpenVPN-Gateway. Im WAP-2.0-Standard arbeitet der WAP-Proxy als HTTP-Proxy. Praktischerweise unterstützt OpenVPN seit Version 2.0 diese Funktionalität (Listing 5b). Die weiter oben genannten Änderungen sorgen für passende HTTP-Header, die dem Proxy einen Telefonbrowser vorgaukeln.

01 dev        tun
02 proto      tcp-client
03 remote     192.168.0.120  443
04 ifconfig   10.8.0.2  10.8.0.1
05 http-proxy 195.182.114.52 8080
06 http-proxy-retry
07 http-proxy-timeout 1
08 resolv-retry infinite
09 nobind
10 link-mtu   620
11 persist-tun
12 secret     secret.key
13 comp-lzo
14 verb       3

Passender Client

Einige Einträge der Client-Konfiguration gleichen den Einstellungen des Servers (Listing 5a). Hierzu zählen die MTU (Zeile 10 in Listing 5b) und die IP-Verbindungsdaten (Zeile 4). Die Kombination aus »proto tcp-client« (Zeile 2) und »http-proxy« (Zeile 5) sorgt dafür, dass OpenVPN eine TCP-Verbindung über den eingetragenen Proxy vornimmt. Der »remote«-Wert in Zeile 3 gibt die OpenVPN-Gegenstelle an.

Nach dem Start des Clients mit »openvpn –cd /etc/openvpn –config wap.conf« ist der Tunnel betriebsbereit. Der Client informiert über seine Aktionen dank der hohen Protokollierungsstufe 3 (Option »verb« in Zeile 14) recht ausführlich auf der Standardausgabe. Wer gleichzeitig mit einem Sniffer wie Ethereal (Abbildungen 5a und 5b) auf der PPP-Schnittstelle mitlauscht, sieht, wie sich der Client an den WAP-Proxy wendet und diesen anweist die Verbindung zum Gateway herzustellen.

Abbildung 5a: Ethereal verfolgt den Datenverkehr am PPP-Device. Per »CONNECT«-Verbindungsaufbau überwindet der OpenVPN-Client den WAP-Proxy. Im mittleren Bereich ist der komplette HTTP-Header erkennbar, der ein Sony-Ericsson-Telefon nachahmt. Der Proxy bestätigt brav mit »HTTP 1/1 200 Connected«.

Abbildung 5b: Der TCP-Stream von OpenVPN zeigt, dass der Verbindungsaufbau noch unverschlüsselt erfolgt. Nach der Connected-Bestätigung des Proxy schaltet OpenVPN auf authentifizierten und chiffrierten Betrieb um, unter Verwendung des Preshared-Key. Das hier mitgesniffte Ping bleibt unerkannt.

Sparmaßnahme sorgt für weniger Daten

Ähnlich wie sich viele einen “Werbung nein danke”-Aufkleber am Briefkasten gönnen, hilft es gerade bei schwachbrüstigen Verbindungen, diesen schwergewichtigen Teil von Webseiten wegzulassen. Privoxy ([11], [12]), auf dem Client-Rechner installiert, fördert das Surfvergnügen und verringert die Menge an Daten, die sich durch die GPRS-Verbindung quälen. Im Browser auf dem Notebook muss dann Privoxy als HTTP-Proxy eingetragen sein, wie im Quickstart-Guide angegeben die 127.0.0.1 sowie Port 8118. Um den Start dieses Proxy kümmert sich Listing 4 bereits (Zeilen 5 und 6).

Nebenbei sorgt der Proxy auf Wunsch dafür, dass die angesurften Webseiten eine zum Setup passende Browserkennung sehen. Eine entsprechende Action-Konfiguration für Privoxy ist in Listing 6 zu sehen: Sie fügt die Sony-Ericsson-Browserkennung ein, mit dem weiter oben bereits OpenVPN dem WAP-Proxy ein Mobiltelefon vorgegaukelt hat. Zusätzlich verbirgt Zeile 5 die umstrittenen Referrer-Header.

01 # default.action
02 { 
03 +add-header{Profile: http://wap.sonyericsson.com/UAprof/P800R102.xml} 
04 -block 
05 +hide-referrer{forge} 
06 +hide-user-agent{Mozilla/1.22 (compatible; MSIE 5.01; PalmOS 3.0) EudoraWeb 2.1} 
07 [...]

Wilde Tunnelei

In Summe ergibt sich ein reichlich wilder Stapel an Protokollen: Der Rechner kommuniziert via Bluetooth mit einem Handy. Auf der Spitze dieses in sich schon komplexen Protokollberges liegt eine serielle Verbindung. Mit der steuert der Rechner das Modem im Mobiltelefon und öffnet eine PPP-Verbindung zum Provider. Als nächste Schichten folgen IP, TCP und schließlich HTTP.

In bester WAP-2.0-Manie ist HTTP das einzige mögliche Protokoll – aber nur bis zum WAP-Proxy. Der Client nötigt dem Proxy einen Connect zu einem Gateway-Rechner ab. Dieser Connect transportiert nicht das vom Proxy erwartete HTTPS, sondern OpenVPN. Darüber laufen dann erneut IP und – als eine mögliche Anwendung – TCP und erneut HTTP, das einen weiteren Proxy nutzt, der diesmal die Privatsphäre des Benutzers und die GPRS-Bandbreite schont. Alternativ sind über OpenVPN alle IP-Anwendungen machbar.

Die leichte Bedien- und Konfigurierbarkeit von OpenVPN küren die IPsec-Alternative zum guten Spielzeug auch in ungewöhnlichen Setups. Gerade die Aufgabe, durch schmale Pfade aus einem geschützten Netzwerk ins Internet zu kommen, verdreht die ursprüngliche Intention eines VPN. Achtung: Die Sicherheitsphilosophie der Firewall-Administratoren oder das Kleingedruckte im Mobilfunkvertrag verbieten es vielleicht auch auf nicht-technischer Ebene, einen WWW-Port zum vollen Internetzugang aufzublasen. (fjl)