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:
Meine MacBooks versuchen sich mit folgenden Einstellungen per Tunnelblick zu verbinden:
Der Workaround beseitigt den bekannten Input/Qutput Error (Dieses Tun/Tap Ding). Ich habe das Script jetzt doch noch mal geposted:
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.
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: