ubuntuusers.de

OpenVPN Server: Client kein Internet mehr

Status: Gelöst | Ubuntu-Version: Server 14.04 (Trusty Tahr)
Antworten |

lordfritte

Anmeldungsdatum:
20. April 2008

Beiträge: 96

Hallo, ich habe ein kleines Problem mit einem OpenVPN Server.

Die Verbindung(Windows-Client) zum Server an sich funktioniert, aber auf dem Client habe ich einen Zugriff aufs Internet mehr.

Interessante Weise funktioniert der Zugriff aufs lokale Netzwerk(clientseitig) weiter ohne Problem.

Zur Info: Ich möchte den OpenVPN Server nicht nutzen um anonym oder über eine andere IP-Adresse ins Internet zu gehen, sondern ich möchte von außen, über das Internet auf mein lokales Netzwerk zugreifen.

Zu meiner Konfiguration: Server:

port 1194

proto udp

dev tun

ca ./easy-rsa2/keys/ca.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/dh2048.pem

dh easy-rsa/keys/dh2048.pem

server 10.8.0.0 255.255.255.0

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS xxx.xxx.xxx.xxx"
push "dhcp-option DNS xxx.xxx.xxx.xxx"
push "route-metric 1000"

push "topology subnet"
topology subnet

route 10.8.0.0 255.255.255.0

keepalive 10 120

comp-lzo

user nobody
group nogroup

persist-key
persist-tun

Client

client

;dev tap
dev tun

;dev-node MyTap

;proto tcp
proto udp

remote openvpn-domain.de 1194

;remote-random

resolv-retry infinite

nobind

;user nobody
;group nobody

persist-key
persist-tun

;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

;mute-replay-warnings

ca ca.crt
cert client.crt
key client.key

remote-cert-tls server

;tls-auth ta.key 1

;cipher x

comp-lzo

verb 3

;mute 20

Client-Log

Mon Nov 20 16:22:38 2017 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Mon Nov 20 16:22:38 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Nov 20 16:22:38 2017 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Mon Nov 20 16:22:38 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Nov 20 16:22:38 2017 Need hold release from management interface, waiting...
Mon Nov 20 16:22:39 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Nov 20 16:22:39 2017 MANAGEMENT: CMD 'state on'
Mon Nov 20 16:22:39 2017 MANAGEMENT: CMD 'log all on'
Mon Nov 20 16:22:39 2017 MANAGEMENT: CMD 'echo all on'
Mon Nov 20 16:22:39 2017 MANAGEMENT: CMD 'hold off'
Mon Nov 20 16:22:39 2017 MANAGEMENT: CMD 'hold release'
Mon Nov 20 16:22:39 2017 MANAGEMENT: >STATE:1511191359,RESOLVE,,,,,,
Mon Nov 20 16:22:39 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]OPENVPN_ADDRESS:1194
Mon Nov 20 16:22:39 2017 Socket Buffers: R=[65536->65536] S=[65536->65536]
Mon Nov 20 16:22:39 2017 UDP link local: (not bound)
Mon Nov 20 16:22:39 2017 UDP link remote: [AF_INET]OPENVPN_ADDRESS:1194
Mon Nov 20 16:22:39 2017 MANAGEMENT: >STATE:1511191359,WAIT,,,,,,
Mon Nov 20 16:22:39 2017 MANAGEMENT: >STATE:1511191359,AUTH,,,,,,
Mon Nov 20 16:22:39 2017 TLS: Initial packet from [AF_INET]OPENVPN_ADDRESS:1194, sid=8483c7c7 b950fdba
Mon Nov 20 16:22:39 2017 VERIFY OK: depth=1, C=DE, ST=Nordrhein-Westfalen, L=Cologne, OU=OpenVPN, CN=openvpm-domain.de, name=EasyRSA, emailAddress=t-herweg@arcor.de
Mon Nov 20 16:22:39 2017 VERIFY KU OK
Mon Nov 20 16:22:39 2017 Validating certificate extended key usage
Mon Nov 20 16:22:39 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Nov 20 16:22:39 2017 VERIFY EKU OK
Mon Nov 20 16:22:39 2017 VERIFY OK: depth=0, C=DE, ST=Nordrhein-Westfalen, L=Cologne, OU=OpenVPN, CN=openvpm-domain.de, name=EasyRSA, emailAddress=t-herweg@arcor.de
Mon Nov 20 16:22:39 2017 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Mon Nov 20 16:22:39 2017 [openvpm-domain.de] Peer Connection Initiated with [AF_INET]OPENVPN_ADDRESS:1194
Mon Nov 20 16:22:41 2017 MANAGEMENT: >STATE:1511191361,GET_CONFIG,,,,,,
Mon Nov 20 16:22:41 2017 SENT CONTROL [openvpm-domain.de]: 'PUSH_REQUEST' (status=1)
Mon Nov 20 16:22:41 2017 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route-metric 1000,topology subnet,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0'
Mon Nov 20 16:22:41 2017 OPTIONS IMPORT: timers and/or timeouts modified
Mon Nov 20 16:22:41 2017 OPTIONS IMPORT: --ifconfig/up options modified
Mon Nov 20 16:22:41 2017 OPTIONS IMPORT: route options modified
Mon Nov 20 16:22:41 2017 OPTIONS IMPORT: route-related options modified
Mon Nov 20 16:22:41 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Nov 20 16:22:41 2017 Outgoing Data Channel: Cipher 'BF-CBC' initialized with 128 bit key
Mon Nov 20 16:22:41 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mon Nov 20 16:22:41 2017 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 20 16:22:41 2017 Incoming Data Channel: Cipher 'BF-CBC' initialized with 128 bit key
Mon Nov 20 16:22:41 2017 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mon Nov 20 16:22:41 2017 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 20 16:22:41 2017 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Mon Nov 20 16:22:41 2017 interactive service msg_channel=116
Mon Nov 20 16:22:41 2017 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 I=2 HWADDR=40:16:7e:ac:ef:28
Mon Nov 20 16:22:41 2017 open_tun
Mon Nov 20 16:22:41 2017 TAP-WIN32 device [Ethernet 3] opened: \\.\Global\{62722539-21D1-47FB-A6B2-AAEE76396B77}.tap
Mon Nov 20 16:22:41 2017 TAP-Windows Driver Version 9.21 
Mon Nov 20 16:22:41 2017 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.2/255.255.255.0 [SUCCEEDED]
Mon Nov 20 16:22:41 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.255.0 on interface {62722539-21D1-47FB-A6B2-AAEE76396B77} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
Mon Nov 20 16:22:41 2017 Successful ARP Flush on interface [3] {62722539-21D1-47FB-A6B2-AAEE76396B77}
Mon Nov 20 16:22:41 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Nov 20 16:22:41 2017 MANAGEMENT: >STATE:1511191361,ASSIGN_IP,,10.8.0.2,,,,
Mon Nov 20 16:22:46 2017 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Mon Nov 20 16:22:46 2017 C:\WINDOWS\system32\route.exe ADD OPENVPN_ADDRESS MASK 255.255.255.255 192.168.178.1
Mon Nov 20 16:22:46 2017 Route addition via service succeeded
Mon Nov 20 16:22:46 2017 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Mon Nov 20 16:22:46 2017 Route addition via service succeeded
Mon Nov 20 16:22:46 2017 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.1
Mon Nov 20 16:22:46 2017 Route addition via service succeeded
Mon Nov 20 16:22:46 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Nov 20 16:22:46 2017 Initialization Sequence Completed
Mon Nov 20 16:22:46 2017 MANAGEMENT: >STATE:1511191366,CONNECTED,SUCCESS,10.8.0.2,OPENVPN_ADDRESS,1194,,

Ist vielleicht das, das Problem:

Mon Nov 20 16:22:46 2017 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1

müsste die 0.0.0.0 route nicht über den Router am client (192.168.178.1) gehen?

Bearbeitet von sebix:

Bitte verwende in Zukunft Codeblöcke, um die Übersicht im Forum zu verbessern!

misterunknown Team-Icon

Ehemalige
Avatar von misterunknown

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 4403

Wohnort: Sachsen

lordfritte schrieb:

Zu meiner Konfiguration: Server:

push "redirect-gateway def1 bypass-dhcp"

Mit dieser Anweisung definierst du, dass der OpenVPN-Server zum Gateway für den Client wird, und damit jeglicher Traffic durch den Tunnel geht. Wenn der OpenVPN-Server nicht als Gateway konfiguriert ist, kommt entsprechend der Client nicht mehr ins Internet.

Ist vielleicht das, das Problem:

Mon Nov 20 16:22:46 2017 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1

müsste die 0.0.0.0 route nicht über den Router am client (192.168.178.1) gehen?

Richtig.

lordfritte

(Themenstarter)

Anmeldungsdatum:
20. April 2008

Beiträge: 96

Aber kann ich dem client nicht anweisen "C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1" nicht auszuführen? Oder MUSS der Traffic über den Server gehen?

misterunknown Team-Icon

Ehemalige
Avatar von misterunknown

Anmeldungsdatum:
28. Oktober 2009

Beiträge: 4403

Wohnort: Sachsen

lordfritte schrieb:

Aber kann ich dem client nicht anweisen "C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1" nicht auszuführen? Oder MUSS der Traffic über den Server gehen?

Nein, der Traffic muss nicht über den Server gehen. Du kannst entweder die benannte Zeile in der Server-Konfiguration entfernen, oder mit dieser Methode verhindern, dass sich der Client die Routen zieht.

lordfritte

(Themenstarter)

Anmeldungsdatum:
20. April 2008

Beiträge: 96

Hallo, sorry, dass ich mich erst jetzt melde, ich hatte das Thema total vergessen....

Aber das entfernen der Zeile "push "redirect-gateway def1 bypass-dhcp"" in der Server-Konfiguration hat funktioniert.

Danke!

Antworten |