Verbindungsabbrüche mit Tunnelblick / OpenVPN

Nielsen

Aktives Mitglied
Thread Starter
Dabei seit
26.09.2006
Beiträge
196
Reaktionspunkte
6
Liebe Leute,

ich bin nun langsam wirklich ratlos. Weder Google, noch irgendwelche Blogs, noch ein Anschreiben der Entwickler hat mein Tunnelblick-Problem beheben können.
Folgendes SetUp findet sich bei mir:
Linksys WRT54GL mit DD-WRT Firmware (v23sp2 mit OpenVPN Server)
Zwei MacBooks, die von außerhalb per VPN auf meinen iMac, Drucker, NAS, iTunes Server, etc zugreifen wollen.

Auf dem Router läuft nun der Server mit folgenden Einstellungen:
Code:
cd /tmp
openvpn --mktun --dev tap0
brctl addif br0 tap0
ifconfig tap0 0.0.0.0 promisc up

echo "
# Tunnel options
mode server       # Set OpenVPN major mode
proto udp         # Setup the protocol (server)
port 1194         # TCP/UDP port number
dev tap0          # TUN/TAP virtual network device
keepalive 15 60   # Simplify the expression of --ping 
daemon            # Become a daemon after all initialization
verb 3            # Set output verbosity to n 
comp-lzo          # Use fast LZO compression 

# OpenVPN server mode options
client-to-client  # tells OpenVPN to internally route client-to-client traffic 
duplicate-cn      # Allow multiple clients with the same common name

# TLS Mode Options
tls-server        # Enable TLS and assume server role during TLS handshake 
ca ca.crt         # Certificate authority (CA) file
dh dh1024.pem     # File containing Diffie Hellman parameters 
cert server.crt   # Local peer's signed certificate
key server.key    # Local peer's private key 
" > openvpn.conf

echo "
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
" > ca.crt
echo "
-----BEGIN RSA PRIVATE KEY-----
xxx
-----END RSA PRIVATE KEY-----
" > server.key
chmod 600 server.key
echo "
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
" > server.crt
echo "
-----BEGIN DH PARAMETERS-----
xxx
-----END DH PARAMETERS-----
" > dh1024.pem

sleep 5
ln -s /usr/sbin/openvpn /tmp/myvpn
/tmp/myvpn --config openvpn.conf

Meine MacBooks versuchen sich mit folgenden Einstellungen per Tunnelblick zu verbinden:
Code:
tls-client          # we are a client
dev tap         # needs to be same as server
proto udp        # protocol
remote xxx.xxx.xxx 1194   # the server address and port
resolv-retry infinite   # keep trying to resolve domain name
nobind          # doesn't bind, I guess
persist-key     # keep info between sessions
persist-tun     # keep info between sessions
mute-replay-warnings    # silences dupe packet warnings (wlans gen these lots)
ca ca.crt       # certificate authority's cert
cert client.crt   # my cert
key client.key    # my key
ns-cert-type server # does something
comp-lzo        # compress. must be same as server.
verb 3          # verbosity
up ./tap-up-down.sh #tun/tap Workaround

Der Workaround beseitigt den bekannten Input/Qutput Error (Dieses Tun/Tap Ding). Ich habe das Script jetzt doch noch mal geposted:
Code:
------ BEGIN ------- 
#!/bin/sh 
# 
# openvpn-tap-up-down.sh 
# 
# 
# A script to be used as an OpenVPN bridged (tap) up/down script on Mac OSX 10.4 
# - uses ipconfig to acquire a DHCP lease via the OpenVPN tap interface, and scutil to 
# incorporate the DHCP-supplied DNS configuration 
# 
# Use in your OpenVPN config file as follows: 
# 
# up openvpn-tap-up-down.sh 
# 
# - up: openvpn calls the 'up' script after the tun/tap interface is created, but before the link 
# to the server is available for use (ditto 'up-delay' at least for UDP) 
# - on testing w/ openvpn 2.0.5, and tcpdump on the tap interface as soon as it comes up, 
# packets are queued up on the interface (and not actually sent over the openvpn tunnel) 
# until *after* this script returns; this makes sense: this script could fail in which 
# case the connection is invalid 
# - this means the DHCP acquisition can't complete until after this script exits 
# - that's not directly a problem as the OS X DHCP client should do everything we need 
# to make the interface functional, all by itself - *except* for one small thing: as of 
# OS X 10.4.7 the DHCP-acquired DNS information is not "merged" into the System 
# Configuration (OS X bug?) 
# - thus we have a chicken-and-egg situation: we need to manually fixup the DNS config, 
# but can't until we get the DHCP lease; we won't get the lease until we this script exits 
# - the solution is to spawn a little "helper" that waits until the lease is acquired, 
# and then does the DNS fixup 
# 
# - down: the only sensible 'down' action is to release the DHCP lease (as a courtesy to the 
# DHCP server), alas it's too late to do this *after* the connection has been shutdown (as 
# of OpenVPN 2.0 there's no "pre-disconnect" script option; note that both 'down' and 
# 'down-pre' are called only after the connection to the server is closed ('down-pre' before 
# closing the tun/tap device, 'down' after) 
# - OS X automatically cleans up the System Config keys created from ipconfig, but we need to 
# manually remove the DNS fixup 
# 
# 2006-09-21 Ben Low original 
# 
# 200x-xx-xx name 
# 
sleep 1 

if [ -z "$dev" ]; then echo "$0: \$dev not defined, exiting"; exit 1; fi 

# relevant script_type values are 'up' or 'down' 
case "$script_type" in 
up) 

# bring the interface up and set it to DHCP 
# - System Configuration dynamic store will be automatically updated, with the 
# State:/Network/Service/DHCP-tap0 
# data store created. 
# - the ipconfig man page notes that it should only be used for "test and debug" purposes, 
# and that you're supposed to use the SystemConfiguration APIs to manipulate the network 
# configuration 
# - alas, there appears to be no CLI utility other than ipconfig 

/usr/sbin/ipconfig set "$dev" DHCP 

# spawn our little DNS-fixerupper 
{ 
# whilst ipconfig will have created the neccessary Network Service keys, the DNS 
# settings won't actually be used by OS X unless the SupplementalMatchDomains key 
# is added 
# ref. <http://lists.apple.com/archives/Macnetworkprog/2005/Jun/msg00011.html> 
# - is there a way to extract the domains from the SC dictionary and re-insert 
# as SupplementalMatchDomains? i.e. not requiring the ipconfig domain_name call? 

# - wait until we get a lease before extracting the DNS domain name and merging into SC 
# - despite it's name, ipconfig waitall doesn't (but maybe one day it will  
/usr/sbin/ipconfig waitall 

# usually takes at least a few seconds to get a DHCP lease 
sleep 3 
n=0 
while [ -z "$domain_name" -a $n -lt 5 ] 
do 
sleep $n 
n=`expr $n + 1` 
domain_name=`/usr/sbin/ipconfig getoption $dev domain_name 2>/dev/null` 
done 

if [ "$domain_name" ]; then 
/usr/sbin/scutil <<EOF 
d.init 
get State:/Network/Service/DHCP-$dev/DNS 
d.add SupplementalMatchDomains * $domain_name 
set State:/Network/Service/DHCP-$dev/DNS 
EOF 
fi 

} & 

;; 

down) 

# for completeness... 
if [ `/usr/bin/id -u` -eq 0 ]; then 
/usr/sbin/ipconfig set "$dev" NONE 
fi 

;; 
*) echo "$0: invalid script_type" && exit 1 ;;

Im internen Netzwerk haben alle Geräte eine IP von 192.168.1.x und die Macs nutzen Leopard mit der neusten Tunnelblick Version.

Nun ist es so, dass sich die Macs zunächst ohne Probleme beim Server verbinden, aber dann nach ca. 10 Sekunden (maximal) die Verbindung ohne Fehlermeldung wieder abbricht. Danach kommt wieder der Input/Output Error. Wenn ich dann einen Moment warte, geht's wieder erst ganz normal und nach 10 Sek. bricht die Verbindung wieder ab.
Wenn ich mich nun aber per Windows-Client verbinde, klappt alles ohne Probleme und die Verbindung bleibt bestehen.
Von den Entwicklern habe ich keine Nachricht bekommen, ob sich das fixen lässt, eine neue Version kommt oder das Projekt eingestellt ist.
Ich bin jetzt wirklich ratlos, was ich da noch machen könnte.

Vielleicht habt Ihr ja noch Ideen oder Einfälle?

Beste Grüße,
Niels.
 
Zuletzt bearbeitet:
Offensichtlich liegt die Fehlerursache hier beim Client auf dem Mac, da der Windows Client keine Probleme macht.

In wie weit das Workaround Script bei deinem Problem eine Rolle spielt, vermag ich nicht zu beurteilen, da ich so ein Script nicht benötige.

Die Frage ist, ob bei deiner Konstellation Tunnelblick zickt oder ob das Problem doch in der OpenVPN Konfiguration liegt. Nach meiner Erfahrung, in verwende eine Multi-Client <-> Server Konstellation, ist Tunnelblick sehr zuverlässig.

Wenn es anders nicht zu lösen ist, würde ich Tunnelblick mal aussen vor lassen und den Mac ohne dieses GUI Tool als OpenVPN-Client betreiben. Die Einrichtung ist wohl ungleich aufwendiger, sie entspricht in etwa der Server Einrichtung.
 
Die Servereinrichtung war ja denkbar einfach: anmachen! :)
Aber inwiefern kann denn Tunnelblick das Problem sein? Und was lässt sich dagegen tun? Warum geht's bei einem und beim anderen nicht? :(
 
Die Servereinrichtung war ja denkbar einfach: anmachen! :)

Ha, der war gut. :D
Na klar, du hast ja eine fertig konfigurierte Firmware auf dem Router.

Aber inwiefern kann denn Tunnelblick das Problem sein? Und was lässt sich dagegen tun? Warum geht's bei einem und beim anderen nicht? :(

Na, wenn Windows und Mac Client die gleiche Conf verwenden und der Mac scheitert, wäre es eine Möglichkeit, Tunnelblick mal wegzulassen, um eine mögliche Fehlerursache auszuschalten.

Das Aufsetzen des OpenVPN-Clients auf dem Mac ist zwar nicht wirklich schwierig, aber mit Aufwand verbunden. Bei Bedarf kann ich dir die notwendigen Schritte zeigen. Wie gesagt scheint mir Tunnelblick aber nicht der Übeltäter zu sein.

Ansonsten ist mir an deiner Client Conf nichts Besonderes aufgefallen, ausser dass ich dein Workaround Skript nicht verwende, weil bei mir so ein Fehler nicht auftritt.
Dort vermute ich die Fehlerursache, event. eine Timing Geschichte beim DHCP, das nicht richtig ausbalanciert ist. Hast du schon mal mit den Zeitwerten im Skript rumgespielt?
 
Erstmal vielen Dank für Deine Hilfe. Also, nein, an dem Script habe ich nicht rumgespielt. Kommt ja auch nicht von mir. Ist eigentlich eh ein Wunder, dass ich das alles bisher so eingerichtet bekommen habe. Bin nämlich eigentlich nicht so Profi in dem Bereich. Wenn ich das Script weglasse, bekomme ich eben diesen Tun/Tap Input/Output Fehler... und da bin ich wohl nicht der einzige.
 
Zurück
Oben Unten