Ich habe einen OpenVPN-Server auf einem Windows 2012-Server laufen. Er funktioniert einwandfrei und ich kann mich von meinem iPhone und iPad aus mit dem VPN verbinden, mein gesamter Webverkehr wird über das VPN geleitet und ich kann mit der iOS Remote Desktop-App auf Geräte in meinem Netzwerk zugreifen.
Ich habe die OpenVPN-App auf meinem Windows 10-Laptop mit demselben Client-Profil wie auf den iOS-Geräten installiert. Obwohl ich damit eine Verbindung herstellen kann, habe ich anschließend keinen Zugriff auf das Internet oder auf die Geräte im LAN.
Es scheint, dass der DNS funktioniert, denn wenn ich versuche, einen Domänennamen anzupingen, wird die IP aufgelöst, aber dann erhalte ich die Meldung „Zeitüberschreitung der Anforderung“.
Ich kann nicht einmal das VPN-Gateway 10.8.0.1 anpingen.
Dies ist meine Serverkonfiguration:
port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway local def1"
push "dhcp-option DNS 8.8.8.8"
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
ca "C:\\Program Files (x86)\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files (x86)\\OpenVPN\\config\\server.crt"
key "C:\\Program Files (x86)\\OpenVPN\\config\\server.key"
dh "C:\\Program Files (x86)\\OpenVPN\\config\\dh1024.pem"
Dies ist meine Client-Konfiguration:
client
dev tun
proto udp
remote xxx.xxx.xxx.xxx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 3
Und dies ist das Protokoll meiner letzten Verbindung:
Mon Jan 16 13:45:08 2017 OpenVPN 2.4.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 27 2016
Mon Jan 16 13:45:08 2017 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Jan 16 13:45:08 2017 library versions: OpenSSL 1.0.2i 22 Sep 2016, LZO 2.09
Enter Management Password:
Mon Jan 16 13:45:08 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Jan 16 13:45:08 2017 Need hold release from management interface, waiting...
Mon Jan 16 13:45:09 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Jan 16 13:45:09 2017 MANAGEMENT: CMD 'state on'
Mon Jan 16 13:45:09 2017 MANAGEMENT: CMD 'log all on'
Mon Jan 16 13:45:09 2017 MANAGEMENT: CMD 'hold off'
Mon Jan 16 13:45:09 2017 MANAGEMENT: CMD 'hold release'
Mon Jan 16 13:45:09 2017 MANAGEMENT: >STATE:1484574309,RESOLVE,,,,,,
Mon Jan 16 13:45:09 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:1194
Mon Jan 16 13:45:09 2017 Socket Buffers: R=[65536->65536] S=[65536->65536]
Mon Jan 16 13:45:09 2017 UDP link local: (not bound)
Mon Jan 16 13:45:09 2017 UDP link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Mon Jan 16 13:45:09 2017 MANAGEMENT: >STATE:1484574309,WAIT,,,,,,
Mon Jan 16 13:45:09 2017 MANAGEMENT: >STATE:1484574309,AUTH,,,,,,
Mon Jan 16 13:45:09 2017 TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx:1194, sid=153bc069 fc314ff6
Mon Jan 16 13:45:10 2017 VERIFY OK: depth=1, C=UK, ST=...
Mon Jan 16 13:45:10 2017 VERIFY OK: nsCertType=SERVER
Mon Jan 16 13:45:10 2017 VERIFY OK: depth=0, C=UK, ST=...
Mon Jan 16 13:45:10 2017 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Jan 16 13:45:10 2017 [server] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:1194
Mon Jan 16 13:45:11 2017 MANAGEMENT: >STATE:1484574311,GET_CONFIG,,,,,,
Mon Jan 16 13:45:11 2017 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon Jan 16 13:45:11 2017 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,redirect-gateway local def1,dhcp-option DNS 8.8.8.8,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Mon Jan 16 13:45:11 2017 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jan 16 13:45:11 2017 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jan 16 13:45:11 2017 OPTIONS IMPORT: route options modified
Mon Jan 16 13:45:11 2017 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Jan 16 13:45:11 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jan 16 13:45:11 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 Jan 16 13:45:11 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jan 16 13:45:11 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jan 16 13:45:11 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 Jan 16 13:45:11 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jan 16 13:45:11 2017 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Mon Jan 16 13:45:11 2017 interactive service msg_channel=536
Mon Jan 16 13:45:11 2017 ROUTE_GATEWAY 172.20.10.1/255.255.255.240 I=12 HWADDR=14:10:9f:ce:13:73
Mon Jan 16 13:45:11 2017 open_tun
Mon Jan 16 13:45:11 2017 TAP-WIN32 device [Ethernet 4] opened: \\.\Global\{27AC27A1-A13C-4E12-B90F-C2797B3E8157}.tap
Mon Jan 16 13:45:11 2017 TAP-Windows Driver Version 9.21
Mon Jan 16 13:45:11 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {27AC27A1-A13C-4E12-B90F-C2797B3E8157} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Mon Jan 16 13:45:11 2017 Successful ARP Flush on interface [6] {27AC27A1-A13C-4E12-B90F-C2797B3E8157}
Mon Jan 16 13:45:11 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Jan 16 13:45:11 2017 MANAGEMENT: >STATE:1484574311,ASSIGN_IP,,10.8.0.6,,,,
Mon Jan 16 13:45:16 2017 TEST ROUTES: 3/3 succeeded len=2 ret=1 a=0 u/d=up
Mon Jan 16 13:45:16 2017 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.5
Mon Jan 16 13:45:16 2017 Route addition via service succeeded
Mon Jan 16 13:45:16 2017 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.5
Mon Jan 16 13:45:16 2017 Route addition via service succeeded
Mon Jan 16 13:45:16 2017 MANAGEMENT: >STATE:1484574316,ADD_ROUTES,,,,,,
Mon Jan 16 13:45:16 2017 C:\WINDOWS\system32\route.exe ADD 192.168.0.0 MASK 255.255.255.0 10.8.0.5
Mon Jan 16 13:45:16 2017 Route addition via service succeeded
Mon Jan 16 13:45:16 2017 C:\WINDOWS\system32\route.exe ADD 10.8.0.0 MASK 255.255.255.0 10.8.0.5
Mon Jan 16 13:45:16 2017 Route addition via service succeeded
Mon Jan 16 13:45:16 2017 Initialization Sequence Completed
Mon Jan 16 13:45:16 2017 MANAGEMENT: >STATE:1484574316,CONNECTED,SUCCESS,10.8.0.6,xxx.xxx.xxx.xxx,1194,,
Irgendwelche Ideen, wo ich anfangen könnte?
Antwort1
Könnten Sie bitte die Routing-Tabelle des Windows 10-Clients während der Verbindung anzeigen?
C:\> route print
Laut Client-Protokoll hat der OpenVPN-Client keine statische Route zum OpenVPN-Server über das ursprüngliche Standard-Gateway (das vor dem Verbindungsaufbau verwendete) hinzugefügt. Dies verhindert, dass OpenVPN-Client-Pakete den Server erreichen, da keine Route dorthin vorhanden ist. Ich schlage vor, dass Sie die Serverkonfiguration ändern und die folgende Zeile ersetzen:
push "redirect-gateway local def1"
Mit einem davon:
push "redirect-gateway autolocal def1"
push "redirect-gateway def1"
Referenz:
$ man 8 openvpn
--redirect-gateway flags...
Automatically execute routing commands to cause all outgoing IP traffic to be redirected over the VPN. This is a client-side option.
This option performs three steps:
(1) Create a static route for the --remote address which forwards to the pre-existing default gateway. This is done so that (3) will not create a routing loop.
(2) Delete the default gateway route.
(3) Set the new default gateway to be the VPN endpoint address (derived either from --route-gateway or the second parameter to --ifconfig when --dev tun is specified).
When the tunnel is torn down, all of the above steps are reversed so that the original default route is restored.
Option flags:
local -- Add the local flag if both OpenVPN servers are directly connected via a common subnet, such as with wireless. The local flag will cause step 1 above to be omit‐
ted.
autolocal -- Try to automatically determine whether to enable local flag above.
def1 -- Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the
original default gateway.
bypass-dhcp -- Add a direct route to the DHCP server (if it is non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows
clients).
bypass-dns -- Add a direct route to the DNS server(s) (if they are non-local) which bypasses the tunnel (Available on Windows clients, may not be available on non-Windows
clients).
block-local -- Block access to local LAN when the tunnel is active, except for the LAN gateway itself. This is accomplished by routing the local LAN (except for the LAN
gateway address) into the tunnel.
ipv6 -- Redirect IPv6 routing into the tunnel. This works similar to the def1 flag, that is, more specific IPv6 routes are added (2000::/4, 3000::/4), covering the whole
IPv6 unicast space.
!ipv4 -- Do not redirect IPv4 traffic - typically used in the flag pair ipv6 !ipv4 to redirect IPv6-only.
Antwort2
Bei älteren Versionen der OpenVPN-GUI war dies ein Symptom dafür, dass die Datei OpenVPN.exe nicht mit Administratorrechten ausgeführt wurde, die erforderlich waren, um Änderungen an der Routing-Tabelle vorzunehmen.
Stellen Sie eine Verbindung her und überprüfen Sie die Routing-Tabelle mit netstat -rn. Wenn keine Routen zu Ihren Remote-Netzwerken vorhanden sind, suchen Sie die Binärdatei openvpn.exe und ändern Sie sie so, dass sie als Administrator ausgeführt wird.
Antwort3
Es mag offensichtlich klingen, aber haben Sie versucht, die Firewall in Windows 10 zu deaktivieren? Eine andere Möglichkeit besteht darin, Ihre Adressierung noch einmal zu überprüfen, da es Ihrem Protokoll zufolge so aussieht, als ob Ihre Gateway-Adresse 10.8.0.5 und nicht 10.8.0.1 ist.
Antwort4
Für diejenigen, die wie ich von einem Drittanbieter-VPN-Anbieter auf einen eigenen OpenVPN-Server umgestiegen sind, gilt: Sie müssen ALLE VPN-Clients auf Ihrem System deinstallieren, einschließlich OpenVPN. Stellen Sie sicher, dass Sie alle Konfigurationen und Registrierungseinträge löschen. Installieren Sie OpenVPN dann neu, sauber und frisch. Diese anderen VPN-Clients basieren wahrscheinlich auf einem OpenVPN-Client und teilen TAP-Adapter und Konfigurationen und sind wahrscheinlich nicht die richtigen.
Auch derAuto-Installerfür die Serverseite, hilft beim Beheben möglicher Fehler in der Serverkonfiguration.