HOWTO_ OpenVPN mit HTTPTunnel durch Proxyserver bugsieren
Im ersten Teil ging es um die Einrichtung von OpenVPN-Server und Client. Nun ist allerdings der Zugriff auf das WWW aus vielen größeren Netzwerken durch Proxy-Server kontrolliert und beschränkt. Es gibt doch einige Mechanismen, wie sich eine VPN-Verbindung darüber aufbauen lässt.
Tunneln per CONNECT
Etliche Proxyserver erlauben auch Verbindungen zu HTTPS-Servern. Dabei hat der Proxy allerdings keinen Zugriff auf die aufgebaute Verbindung (wir erinnern uns: Verschlüsselung) und leitet die Daten einfach nur durch. Prinzipiell weiß er nicht einmal, dass am Ende eine SSL-Verbindung aufgebaut wurde, denn initial wird lediglich eine unverschlüsselte TCP/IP-Verbindung verwendet.
Dieser Mechanismus ist im OpenVPN-Client bereits eingebaut und kann einfach in der Konfigurationsdatei eingestellt werden.
http-proxy [proxy server] [proxy port #]
Standardmäßig werden HTTPS-Verbindungen zum Port 443 aufgebaut, und daher beschränken Proxyadministratoren auch gerne das CONNECT-Kommando auf diesen Port. In meinem Falle "sitzt" da zu Hause aber bereits ein Webserver, so dass ich auf diese Methode leider nicht zurückgreifen kann. Mit ein wenig Herumprobieren ließe sich eventuell der Port mittels iptables sharen.HTTPTunnel
Was aber erlaubt wird, sind unverschlüsselte, les- und cachebare HTTP-Verbindungen. Wer wirklich Pech hat, darf auch diese nur zu einem Port 80 aufbauen und - genau - da sitzt eben oft auch ein Webserver. Glücklicherweise wird der Port 8080 oftmals auch freigeschaltet, und über den lasse ich nun HTTPTunnel laufen. Tipps dazu habe ich aus diesem Artikel.Setup Server (Debian Sarge 3.1 "stable")
Nach apt-get install httptunnel wird mit touch /etc/init.d/httptunnelein kleines Startupscript angelegt und mit folgendem Inhalt gefüllt:
#!/bin/bashAutomatisch bei Systemstart laden:
# Startup-script für HTTPTunnel
# Tunnelendpunkt auf Port 8080 wird auf
# 1194 (OpenVPN-Server) weitergeleitet
echo Starting HTTPTunnel for OpenVPN
hts --forward-port localhost:1194 8080
chmod +x /etc/init.d/httptunnel
update-rc.d httptunnel defaults 98
Damit ist der Tunnel eingerichtet, aber zwei Anpassungen für OpenVPN sind in der /etc/openvpn/server.conf noch vorzunehmen:
# HTTP-Tunnelling funktioniert nur mit TCP-Paketen!Nach einem Neustart sind die Änderungen übernommen:
proto tcp
;proto udp
# Mit tun funktioniert das NAT-Routing auf dem VPN-Server nicht
dev tap
;dev tun
/etc/init.d/openvpn stop
/etc/init.d/openvpn startSetup Client (Max OS X)
Hier ist ein bisschen mehr Arbeit nötig. Auf jeden Fall müssen die aktuellen XCode-Tools installiert werden, da sonst die GCC nicht vorhanden ist.
Die Sources müssen heruntergeladen und entpackt werden, aktuell ist 3.0.5. Nun in das Verzeichnis wechseln und mit
./configurekompilieren und installieren. Der Tunnelclient ist nun einsatzbereit:
make
sudo make install
sudo ./install-sh hts /usr/local/bin
sudo ./install-sh htc /usr/local/bin
htc --forward-port 8080 --proxy <PROXY>[:<PORT>] [--proxy-authorization <USER>:<PASS>] <VPN_HOSTNAME>:8080
Damit auch der VPN-Client über den HTTPTunnel geht, müssen ihm diese Änderungen über die Konfiguration bekannt gemacht werden. In den Utilities mit einem Doppelklick Tunnelblick starten, auf das Icon klicken, Details... auswählen und auf Edit Configuration klicken.
# TAP statt TUN verwendenAbspeichern und fertig ist.
;dev tun
dev tap
# HTTP verwendet TCP und nicht UDP
;proto udp
proto tcp
# Tunnel wird lokal geöffnet
;remote myserver.dyndns.org 1149
remote localhost 8080
Bei dem von mir verwendeten Proxy bricht leider die Verbindung nach kurzer Zeit immer wieder ab, eine runde halbe Minute später beendet sich dann auch der HTTPTunnel-Client und muss neu gestartet werden. Eventuell lässt sich dies aber noch über die verschiedenen Parameter (htc --help) optimieren.
Last but not least fehlt noch ein elegantes (automatisches?) Startupscript für den HTTPTunnel-Client. Wenn ich mal wieder nichts zu tun habe...
cypressor - 22. Apr, 16:47
Warum TAP-Adapter?
Gibt es deinerseits irgendwelche Argumente, die für TAP sprechen wenn man keine Ethernet-Frames benötigt?