Weiterführung: DNS funktioniert nicht mit OpenVPN

rumknapser · 25. Aug 2013

Hallo,
das ist eine Weiterführung dieses Threads, weil ich mit meinem speziellen Problem nicht die Informationsdichte zerstören wollte

Es geht darum, dass ich bei funktionierendem OpenVPN keine Namensauflösung habe, d.h. ich kann die Maschinen im VPN nur mit IP, nicht aber mit Ihrem Namen ansprechen.

fpo4711 schrieb:
Also in deine configs gehört nur device tun.

Das steht dort nun auch wieder, denn so funktioniert das VPN für Mac und iGeräte; wenn auch ohne Namensauflösung.

fpo4711 schrieb:
Im Log von openvpn müßte wahrscheinlich eh drin stehen "connected via tun".

Tja, zur Namensauflösung steht nicht wirklich viel im Log, dafür andere Dinge, die ich wohl auch noch angehen werde. Vermute aber nicht, das die etwas mit der nicht funktionierenden Namensauflösung zu tun haben.

fpo4711 schrieb:
Bei mir klappt da auch die Namensauflösung völlig korrekt. Solltest Du eine Fritzbox als Router dran hängen haben, dann den Namen nehmen der dort angegeben ist. Kann von dem Namen der in der DS eingetragen ist abweichend sein!

Bei mir leider nicht,
Hier steht als Router/DNS-Server ein DD-WRT, dessen DNS hier im Netz wunderbar funktioniert, sowie ein von meinem ISP ausgelieferter NonName Router über den ich es auch versuche. (Leitung vom Nachbarn...)

Der Vollständigkeit halber mal die openvpn.conf

Rich (BBCode):

/usr/syno/etc/packages/VPNCenter/openvpn> cat openvpn.conf
push "route 192.168.18.0 255.255.255.0"
push "route 192.168.17.0 255.255.255.0"
push "dhcp-option DNS 192.168.18.1"

#dev tap
dev tun

management 127.0.0.1 1195

server 192.168.17.0 255.255.255.0

dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh4096.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

max-clients 10

comp-lzo

persist-tun
persist-key

verb 3

#log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 3600

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn

Und das openvpn.log vom Server:

Rich (BBCode):

Aug 25 22:48:27 openvpn[12203]: event_wait : Interrupted system call (code=4)
Aug 25 22:48:32 openvpn[20007]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Aug 25 22:48:32 openvpn[20007]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Aug 25 22:48:33 openvpn[20007]: WARNING: POTENTIALLY DANGEROUS OPTION --client-cert-not-required may accept clients which do not present a certificate
Aug 25 22:50:27 openvpn[27683]: Libgcrypt warning: missing initialization - please fix the application
Aug 25 22:53:07 openvpn[20089]: 80.80.80.80:51715 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1542', remote='link-mtu 1558'
Aug 25 22:53:07 openvpn[20089]: 80.80.80.80:51715 WARNING: 'cipher' is used inconsistently, local='cipher BF-CBC', remote='cipher AES-128-CBC'
Aug 25 22:53:08 openvpn[20089]: DS/80.80.80.80:51715 Authenticate/Decrypt packet error: cipher final failed
[...] diverse...
Aug 25 22:53:24 openvpn[20089]: DS/80.80.80.80:51715 Authenticate/Decrypt packet error: cipher final failed
Aug 25 22:53:24 openvpn[20089]: DS/80.80.80.80:51715 Authenticate/Decrypt packet error: cipher final failed
Aug 25 22:53:25 openvpn[20089]: DS/80.80.80.80:51715 Bad LZO decompression header byte: 111
Aug 25 22:53:25 openvpn[20089]: DS/80.80.80.80:51715 Authenticate/Decrypt packet error: cipher final failed
Aug 25 22:53:25 openvpn[20089]: DS/80.80.80.80:51715 Authenticate/Decrypt packet error: cipher final failed
Aug 25 22:53:26 openvpn[20089]: DS/80.80.80.80:51715 Authenticate/Decrypt packet error: cipher final failed
Aug 25 22:53:28 openvpn[20089]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Aug 25 22:53:38 openvpn[20089]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Aug 25 22:53:48 openvpn[20089]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Aug 25 22:53:58 openvpn[20089]: read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

Anzeige · 25. Aug 2013

Hallo rumknapser,

Bücher und Hardware zum Thema gibt es bei Amazon: Weiterführung: DNS funktioniert nicht mit OpenVPN

rumknapser · 25. Aug 2013

Hier noch das OpenVPN Log vom iPad:

Rich (BBCode):

2013-08-25 22:57:44 ----- OpenVPN Start -----
2013-08-25 22:57:44 LZO-ASYM init swap=0 asym=0
2013-08-25 22:57:44 EVENT: RESOLVE
2013-08-25 22:57:44 Contacting 111.111.111.111:1194 via UDP
2013-08-25 22:57:44 EVENT: WAIT
2013-08-25 22:57:44 Connecting to server.domain.de:1194 (111.111.111.111) via UDPv4
2013-08-25 22:57:44 EVENT: CONNECTING
2013-08-25 22:57:44 Tunnel Options:V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client
2013-08-25 22:57:44 Peer Info:
IV_VER=1.0
IV_PLAT=ios
IV_NCP=1
IV_LZO=1

2013-08-25 22:57:49 SSL Handshake: TLSv1.0/SSL-EDH-RSA-AES-256-SHA
2013-08-25 22:57:49 Session is ACTIVE
2013-08-25 22:57:50 EVENT: GET_CONFIG
2013-08-25 22:57:50 Sending PUSH_REQUEST to server...
2013-08-25 22:57:50 OPTIONS:
0 [route] [192.168.18.0] [255.255.255.0] 
1 [route] [192.168.17.0] [255.255.255.0] 
2 [dhcp-option] [DNS] [192.168.18.1] 
3 [route] [192.168.17.1] 
4 [topology] [net30] 
5 [ping] [10] 
6 [ping-restart] [60] 
7 [ifconfig] [192.168.17.10] [192.168.17.9] 

2013-08-25 22:57:50 LZO-ASYM init swap=0 asym=0
2013-08-25 22:57:50 EVENT: ASSIGN_IP
2013-08-25 22:57:50 Connected via tun
2013-08-25 22:57:50 EVENT: CONNECTED user@server.domain.de:1194 (111.111.111.111) via /UDPv4 on tun/192.168.17.10/
2013-08-25 22:58:30 Session invalidated
2013-08-25 22:58:30 Client terminated, restarting in 2...
2013-08-25 22:58:32 EVENT: RECONNECTING
2013-08-25 22:58:32 LZO-ASYM init swap=0 asym=0
2013-08-25 22:58:32 Contacting 111.111.111.111:1194 via UDP
2013-08-25 22:58:32 EVENT: WAIT
2013-08-25 22:58:32 Connecting to server.domain.de:1194 (111.111.111.111) via UDPv4
2013-08-25 22:58:32 EVENT: CONNECTING
2013-08-25 22:58:32 Tunnel Options:V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client
2013-08-25 22:58:32 Peer Info:
IV_VER=1.0
IV_PLAT=ios
IV_NCP=1
IV_LZO=1

2013-08-25 22:58:36 SSL Handshake: TLSv1.0/SSL-EDH-RSA-AES-256-SHA
2013-08-25 22:58:36 Session is ACTIVE
2013-08-25 22:58:37 EVENT: GET_CONFIG
2013-08-25 22:58:37 Sending PUSH_REQUEST to server...
2013-08-25 22:58:37 OPTIONS:
0 [route] [192.168.18.0] [255.255.255.0] 
1 [route] [192.168.17.0] [255.255.255.0] 
2 [dhcp-option] [DNS] [192.168.18.1] 
3 [route] [192.168.17.1] 
4 [topology] [net30] 
5 [ping] [10] 
6 [ping-restart] [60] 
7 [ifconfig] [192.168.17.14] [192.168.17.13] 

2013-08-25 22:58:37 LZO-ASYM init swap=0 asym=0
2013-08-25 22:58:37 EVENT: ASSIGN_IP
2013-08-25 22:58:37 Connected via tun
2013-08-25 22:58:37 EVENT: CONNECTED user@server.domain.de:1194 (111.111.111.111) via /UDPv4 on tun/192.168.17.14/

rumknapser · 25. Aug 2013

Und zuguterletzt, das sehr ausführliche Log von Tunnelblick (TEIL1):

Rich (BBCode):

2013-08-25 23:15:32 *Tunnelblick: OS X 10.8.4; Tunnelblick 3.3.0 (build 3518)
2013-08-25 23:15:32 *Tunnelblick: Attempting connection with DS_VPN_TEST using shadow copy; Set nameserver = 1; monitoring connection
2013-08-25 23:15:32 *Tunnelblick: openvpnstart start DS_VPN_TEST.tblk 1337 1 0 1 0 817 -atADGNWradsgnw 
2013-08-25 23:15:32 *Tunnelblick: Established communication with OpenVPN
2013-08-25 23:15:32 *Tunnelblick: Obtained VPN username and password from the Keychain
2013-08-25 23:15:32 *Tunnelblick: openvpnstart starting OpenVPN:
                    *                    /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.2.1/openvpn --cd /Library/Application Support/Tunnelblick/Users/user/DS_VPN_TEST.tblk/Contents/Resources --daemon --management 127.0.0.1 1337 --config /Library/Application Support/Tunnelblick/Users/user/DS_VPN_TEST.tblk/Contents/Resources/config.ovpn --log /Library/Application Support/Tunnelblick/Logs/-SUsers-Suser-SLibrary-SApplication Support-STunnelblick-SConfigurations-SDS_VPN_TEST.tblk-SContents-SResources-Sconfig.ovpn.1_0_1_0_817.1337.openvpn.log --management-query-passwords --management-hold --redirect-gateway def1 --script-security 2 --up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -f -atADGNWradsgnw --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -m -w -d -f -atADGNWradsgnw --up-restart
2013-08-25 23:15:32 OpenVPN 2.2.1 i386-apple-darwin10.8.0 [SSL] [LZO2] [PKCS11] [eurephia] built on Jul 22 2013
2013-08-25 23:15:32 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
2013-08-25 23:15:32 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2013-08-25 23:15:32 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2013-08-25 23:15:32 LZO compression initialized
2013-08-25 23:15:32 UDPv4 link local (bound): [undef]:1194
2013-08-25 23:15:32 UDPv4 link remote: 81.173.237.11:1194
2013-08-25 23:15:32 TLS Error: local/remote TLS keys are out of sync: 81.173.237.11:1194 [0]
2013-08-25 23:15:32 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2013-08-25 23:15:36 [OpenVPN_SVR] Peer Connection Initiated with 81.173.237.11:1194
2013-08-25 23:15:38 TUN/TAP device /dev/tun0 opened
2013-08-25 23:15:38 /sbin/ifconfig tun0 delete
                                        ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2013-08-25 23:15:38 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2013-08-25 23:15:38 /sbin/ifconfig tun0 192.168.17.10 192.168.17.9 mtu 1500 netmask 255.255.255.255 up
2013-08-25 23:15:38 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m -w -d -f -atADGNWradsgnw tun0 1500 1542 192.168.17.10 192.168.17.9 init
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: Retrieved from OpenVPN: name server(s) [ 192.168.18.1 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: MAN_DNS_CONFIG = No such key
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: MAN_SMB_CONFIG = <dictionary> { NetBIOSName : MAC Workgroup : WORKGROUP }
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: CUR_DNS_CONFIG = <dictionary> { DomainName : localdomain ServerAddresses : <array> { 192.168.0.1 } }
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: CUR_SMB_CONFIG = <dictionary> { NetBIOSName : MAC Workgroup : WORKGROUP }
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: DYN_DNS_DN = openvpn; DYN_DNS_SA = 192.168.18.1; DYN_DNS_SD =
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: DYN_SMB_NN = ; DYN_SMB_WG = ; DYN_SMB_WA =
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: MAN_DNS_DN = ; MAN_DNS_SA = ; MAN_DNS_SD =
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: MAN_SMB_NN = MAC; MAN_SMB_WG = WORKGROUP; MAN_SMB_WA =
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: CUR_DNS_DN = 192.168.0.1; CUR_DNS_SA = 192.168.0.1; CUR_DNS_SD =
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: CUR_SMB_NN = MAC; CUR_SMB_WG = WORKGROUP; CUR_SMB_WA =
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: ServerAddresses were not aggregated because running on OS X 10.6 or higher
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: Setting search domains to 'openvpn' because running under OS X 10.6 or higher and the search domains were not set manually and 'Prepend domain name to search domains' was not selected
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: FIN_DNS_DN = openvpn; FIN_DNS_SA = 192.168.18.1; FIN_DNS_SD = openvpn
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: FIN_SMB_NN = MAC; FIN_SMB_WG = WORKGROUP; FIN_SMB_WA =
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: OS X 10.8 or higher, so will modify DNS settings using Setup: in addition to State:
2013-08-25 23:15:40 *Tunnelblick client.up.tunnelblick.sh: DEBUG: SKP_DNS = ; SKP_DNS_SA = ; SKP_DNS_SD = ; SKP_DNS_DN =
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: SKP_SETUP_DNS =
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: SKP_SMB = #; SKP_SMB_NN = #; SKP_SMB_WG = #; SKP_SMB_WA = #
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: /etc/resolve = domain localdomain nameserver 192.168.0.1
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: scutil --dns BEFORE CHANGES = DNS configuration resolver #1 search domain[0] : localdomain nameserver[0] : 192.168.0.1 if_index : 5 (en1) reach : Reachable,Directly Reachable Address resolver #2 domain : local options : mdns timeout : 5 order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 order : 301000 DNS configuration (for scoped queries) resolver #1 search domain[0] : localdomain nameserver[0] : 192.168.0.1 if_index : 5 (en1) flags : Scoped reach : Reachable,Directly Reachable Address

rumknapser · 25. Aug 2013

Und TEIL2:

Code:

2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Configuration changes:
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD State: ServerAddresses 192.168.18.1
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD State: SearchDomains openvpn
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD State: DomainName openvpn
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD Setup: ServerAddresses 192.168.18.1
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD Setup: SearchDomains openvpn
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ADD Setup: DomainName openvpn
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ##ADD State: NetBIOSName MAC
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ##ADD State: Workgroup WORKGROUP
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: ##ADD State: WINSAddresses
2013-08-25 23:15:41 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Pause for configuration changes to be propagated to State:/Network/Global/DNS and .../SMB
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Configurations as read back after changes:
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/.../DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 192.168.18.1 } }
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/.../SMB = No such key
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Setup:/.../DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 192.168.18.1 } }
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Setup:/.../SMB = <dictionary> { NetBIOSName : MAC Workgroup : WORKGROUP }
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/Global/DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 192.168.18.1 } }
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/Global/SMB = <dictionary> { NetBIOSName : MAC Workgroup : WORKGROUP }
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: Expected by process-network-changes:
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/OpenVPN/DNS = <dictionary> { DomainName : openvpn SearchDomains : <array> { openvpn } ServerAddresses : <array> { 192.168.18.1 } }
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: State:/Network/OpenVPN/SMB = <dictionary> { NetBIOSName : MAC Workgroup : WORKGROUP }
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: /etc/resolve = search openvpn nameserver 192.168.18.1
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: DEBUG: scutil --dns AFTER CHANGES = DNS configuration resolver #1 search domain[0] : openvpn nameserver[0] : 192.168.18.1 reach : Reachable resolver #2 domain : local options : mdns timeout : 5 order : 300000 resolver #3 domain : 254.169.in-addr.arpa options : mdns timeout : 5 order : 300200 resolver #4 domain : 8.e.f.ip6.arpa options : mdns timeout : 5 order : 300400 resolver #5 domain : 9.e.f.ip6.arpa options : mdns timeout : 5 order : 300600 resolver #6 domain : a.e.f.ip6.arpa options : mdns timeout : 5 order : 300800 resolver #7 domain : b.e.f.ip6.arpa options : mdns timeout : 5 order : 301000 DNS configuration (for scoped queries) resolver #1 search domain[0] : openvpn nameserver[0] : 192.168.18.1 if_index : 5 (en1) flags : Scoped reach : Reachable
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: Saved the DNS and SMB configurations for later use
2013-08-25 23:15:42 *Tunnelblick client.up.tunnelblick.sh: Flushed the DNS Cache

ich möchte hier niemanden zwingen, mir zu antworten, evtl. ist es ja ein sehr spezifisches OpenVPN Problem (Eher aber, der Fehler befindet sich *vor* dem Rechner), da ich den Thread auch nicht allzusehr zumüllen möchte mit spezieller Analyse meines Problems.

Nur falls etwas sehr offensichtlich ist, und jemand sich die Zeit nehmen kann, die Logs anzusehen, wäre das sehr nett.

fpo4711 · 26. Aug 2013

Ja, ne Menge Stoff. Bevor ich mir das antue vieleicht zur Sicherheit noch eine Frage. Du testest das auch wirklich von ausserhalb? Und wie prüftst Du denn die Namensauflösung?

Auf jeden Fall kann ich schon mal keinen Fehler in der Server-Config von OpenVPN feststellen.

Gruß Frank

fpo4711 · 26. Aug 2013

Hab mir das mal grob angeschaut. Als erstes ist mir aufgefallen das Du Warnungen über MTU und CIPHER drin hast und somit eigentlich überhaupt kein TLS-Handshake zustande kam. Wie der Rest dann doch funktionierte ???

Um jedenfalls mal einen Ansatz zu haben hier eine Config (Client) die auf einem iPad funktioniert. Ich kann das auch schlecht mit Tunnelblick prüfen (war mir damals auch zu unübersichtlich weshalb ich mich generell für Viscosity entschieden hab).

Rich (BBCode):

dev tun
tls-client

remote der.server.de 1194

redirect-gateway
pull
proto udp
script-security 2
comp-lzo
reneg-sec 8640000
auth-user-pass
setenv CLIENT_CERT 0

<ca>
-----BEGIN CERTIFICATE-----
... ca
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
.... cert
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN RSA PRIVATE KEY-----
.... key
-----END RSA PRIVATE KEY-----
</key>

Gruß Frank

rumknapser · 26. Aug 2013

Hi Frank,
ja, ich teste von aussen, über das WLAN vom Nachbarn, mit dem ich mich mit dem iPad und dem Mac verbinde.
Die Namensauflösung teste ich mit simplen Ping oder SSH, also z.B. Ping IP oder Ping Maschinenname oder Ping Maschinenname.local
Bei SSH warte ich solange, bis ich zum Eingeben des PW aufgefordert werde, ergo eine Verbindung stattfindet.

Als ich das TAP device im Server und im Mac-Client(Tunnelblick) eingetragen hatte, bekam ich Antworten bei z.B. Ping Maschinename. Mit dem TUN Device in beiden Configs bekomme ich nur Antwort über IP. Mehr hatte ich bei diesem Test IMHO nicht umgestellt, NUR dev tun auf dev tap.
Der rest der Konfig ist identisch.

Danke f.d. angehangene Config, ich versuche nun erstmal die MTU und CIPHER Themen anzugehen indem ich diesbezüglich die Konfigurationen angleiche (Hoffentlich ist das so einfach) und gucke mir dabei Deine Config auch mal an...

Wird schon schiefgehen und ich melde mich dann wieder ;-)

jahlives · 26. Aug 2013

80.80.80.80:51715 WARNING: 'cipher' is used inconsistently, local='cipher BF-CBC', remote='cipher AES-128-CBC'

das kann nicht wirklich funzen

rumknapser · 26. Aug 2013

jahlives schrieb:
das kann nicht wirklich funzen

Soweit ein Tunnel aufgebaut wird, funzt es aber. Evtl. weil sich der Client und der Server dann doch auf den kleinsten gemeinsamen Nenner einigen? Nur eine schlichte Vermutung, die noch nicht mal durch einen Log-Eintrag bestätigt wird.

Dennoch werde ich zuallererst versuchen, diese offensichtlichen Fehler zu beheben um mich dann um die Namensauflösung zu kümmern.

Dafür brauche ich allerdings ersteinmal Zeit zum Lesen und Verstehen (und ggf. eine längere Mittagspause)

DrHasen · 27. Sep 2013

So, die Mittagspause muss nun um sein. Gibt es denn schon eine Lösung?

http://www.synology-forum.de/showth...S-Client-keine-Verbindung&p=363753#post363753

VG Hagen

rumknapser · 27. Sep 2013

Hi,
prinzipiell hast Du recht, doch (leider?) hab ich i.d.l.Z. einfach zu wenig Motivation, mich da dran zu hängen, denke aber öfter mit einem schlechten Gewissen an diesen Thread und meine vor mir liegende Arbeit ;-/
'Schuldigung. Erst nen großen Haufen machen, ihn aber dann in der Sonne vertrocknen lassen...so sind'se ;=)

DrHasen · 27. Sep 2013

Hi,

wie es scheint, habe ich eine Lösung mit einiger Hilfe gefunden.

http://www.synology-forum.de/showth...S-Client-keine-Verbindung&p=363753#post363753

Ich habe einfach die Verschlüsselung auf Clint- und Serverseite angepasst.

http://openvpn.net/index.php/access...ange-the-cipher-in-openvpn-access-server.html

Dazu in die Serverconfig openvpn.conf und die Clientdatei client.ovpn einfach die Zeile "cipher AES-256-CBC" einfügen.

Ob AES256 da die richtige Wahl ist, kann ich aber auch nicht sagen. Ich denke, die ist sicher, aber auch recht "langsam".

VG Hagen

jahlives · 27. Sep 2013

DrHasen schrieb:
Ob AES256 da die richtige Wahl ist, kann ich aber auch nicht sagen. Ich denke, die ist sicher, aber auch recht "langsam".

der beste Kompromiss aus Sicherheit und Performance dürfte wohl der blowfish Algo sein. AES-256 erfordert sicher deutlich mehr Prozessorarbeit als der Blowfish.

DrHasen · 27. Sep 2013

jahlives schrieb:
der beste Kompromiss aus Sicherheit und Performance dürfte wohl der blowfish Algo sein. AES-256 erfordert sicher deutlich mehr Prozessorarbeit als der Blowfish.

Die DS 713+ wird das Serverseitig sicher nicht bei sehr geringen gleichzeitigen Nutzern überfordern. Wie die iOS Geräte (iPhone 5 und iPad mini) damit umgehen werden werde ich die Tage feststellen. Sollte das nicht zufriedenstellend sein, werde ich auf blowfish wechseln.

Danke

jahlives · 27. Sep 2013

DrHasen schrieb:
Wie die iOS Geräte (iPhone 5 und iPad mini) damit umgehen werden werde ich die Tage feststellen.

an die habe ich im speziellen gedacht

Man hat mit blowfish nicht unbedingt mehr Durchsatz als mit AES, aber weil es deutlich weniger Prozessorarbeit braucht halten die Akkus sicher länger.

Suche

Weiterführung: DNS funktioniert nicht mit OpenVPN

rumknapser

Benutzer

Anzeige

rumknapser

Benutzer

rumknapser

Benutzer

rumknapser

Benutzer

fpo4711

Benutzer

fpo4711

Benutzer

rumknapser

Benutzer

jahlives

Benutzer

rumknapser

Benutzer

DrHasen

Benutzer

rumknapser

Benutzer

DrHasen

Benutzer

jahlives

Benutzer

DrHasen

Benutzer

jahlives

Benutzer

Kaffeautomat