Problem beim VPN bei ähnlichen remote und local Netzen (192.168.)
Hallo zusammen,
ich habe ein Problem mit meinem VPN, welches ich einfach nicht gelöst bekomme.
Der Text ist etwas länger geworden, aber ich hoffe, ich konnte ihn einigermaßen strukturieren.
Kontext:
Wenn ich unterwegs bin, möchte ich gerne meine mitgeführten Geräte per VPN nach Hause verbinden, um entweder auf das dortige NAS zugreifen zu können, aber auch um sicher das offene WLAN nutzen zu können.
Dazu habe ich mir mehrere Möglichkeiten geschaffen:
Zu Hause läuft ein weiterer Raspberry als VPN Server (Raspberry-VPNS), den ich mit PiVPN aufgesetzt habe. Dieser hängt an einer FritzBox, bei der ein entsprechendes Portforwarding eingerichtet ist. Die Fritzbox erzeugt intern ein 192.168.3.0/24 Netz (ich weiß, 192.168.3.x ist suboptimal...). Zusätzlich ist in der FritzBox auch noch eine statische Route eingetragen, damit die per VPN eingewählten Geräte vom internen Netz erreicht werden können (was für meine Zwecke aber nicht notwendig ist).
Problembeschreibung:
In zwei dokumentierten Fällen nutzt das unterwegs zur Verfügung stehende WLAN (Hotel oder Handy Hotspot) das 192.168 Netz wie folgt:
WLAN Hotel: 192.168.44.0/22
Hotspot Android Handy: 192.168.43.0/24
In diesen Fällen kommt zwar eine Verbindung per VPN zu Stande, aber einige Dinge funktionieren nicht:
Wird das VPN genutzt?
Unter Linux:
Unter Windows:
Probleme:
Aber nicht beim iPad oder beim Laptop mit Win10 - hier funktioniert es.
Aber nicht beim Laptop mit Win10 (iPad nicht getestet).
Aber nicht beim Laptop mit Win10 (iPad und Handy nicht getestet).
Positive Szenarien:
Zusammenfassung des Problems:
Kurz gesagt:
Anmerkungen:
Bitte um Unterstützung
Die Fragen sind, was genau hier das Problem ist und was gemacht werden muss, um das zu beheben?
Einiges funktioniert und die 192.168(.3/24|.44/22|.43/24) Netze sind ja nicht identisch, sollte doch machbar sein!?
Technische Details:
Im offenen Hotel-WLAN bekam ich für den Laptop/Mint19.3
und unter Windows10 folgendes:
Nach VPN Verbindungsaufbau:
Unter Linux:
und unter Windows10
Raspberry-VPNS Config
Mit folgender client ovpn-config baue ich das VPN unter Mint19.3 auf:
Diese Inhalte, allerdings ohne die Zeilen 17 bis 21, nutze ich auch unter Windows.
Verbinden unter Linux:
Verbinden mit Windows10
Beenden VPN unter Linux:
Beenden VPN unter Windows10
ich habe ein Problem mit meinem VPN, welches ich einfach nicht gelöst bekomme.
Der Text ist etwas länger geworden, aber ich hoffe, ich konnte ihn einigermaßen strukturieren.
Kontext:
Wenn ich unterwegs bin, möchte ich gerne meine mitgeführten Geräte per VPN nach Hause verbinden, um entweder auf das dortige NAS zugreifen zu können, aber auch um sicher das offene WLAN nutzen zu können.
Dazu habe ich mir mehrere Möglichkeiten geschaffen:
- Auf dem Laptop (Win10 und Mint19.3 installiert) ist jeweils OpenVPN installiert, ebenso auf dem Android-Handy und dem iPad. Die Geräte werden einzeln mit dem offenen WLAN eines Hotels verbunden und gehen dann jeweils mit OpenVPN via VPN nach Hause.
- Mit dem Android-Handy wird ein Hotspot eröffnet, über den sich Laptop und iPad verbinden und dann jeweils mit eigenem VPN nach Hause gehen.
- Ein Raspberry mit installiertem OpenVPN, der zusätzlich als Accesspoint u.a. für meine oben genannten Geräte dient (Raspberry-AP). In diesem Fall verbindet sich nur der Raspberry-AP mit dem offenen WLAN, geht via VPN nach Hause und als Accesspoint bedient er die Geräte.
Zu Hause läuft ein weiterer Raspberry als VPN Server (Raspberry-VPNS), den ich mit PiVPN aufgesetzt habe. Dieser hängt an einer FritzBox, bei der ein entsprechendes Portforwarding eingerichtet ist. Die Fritzbox erzeugt intern ein 192.168.3.0/24 Netz (ich weiß, 192.168.3.x ist suboptimal...). Zusätzlich ist in der FritzBox auch noch eine statische Route eingetragen, damit die per VPN eingewählten Geräte vom internen Netz erreicht werden können (was für meine Zwecke aber nicht notwendig ist).
Problembeschreibung:
In zwei dokumentierten Fällen nutzt das unterwegs zur Verfügung stehende WLAN (Hotel oder Handy Hotspot) das 192.168 Netz wie folgt:
WLAN Hotel: 192.168.44.0/22
Hotspot Android Handy: 192.168.43.0/24
In diesen Fällen kommt zwar eine Verbindung per VPN zu Stande, aber einige Dinge funktionieren nicht:
Wird das VPN genutzt?
Unter Linux:
kda@LT-I73615QM:~$ traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 64 hops max
1 10.8.0.1 298,156ms 55,807ms 63,660ms
2 192.168.3.1 59,547ms 61,234ms 127,077ms
3 80.133.249.82 48,479ms 120,448ms 77,484ms
4 217.5.116.106 101,727ms 122,363ms 71,657ms
5 62.157.251.38 109,014ms 77,186ms 106,493ms
6 82.98.102.7 71,079ms 69,726ms 92,178ms
7 82.98.102.65 69,685ms 111,500ms 74,823ms
8 * * *
9 * 212.19.61.13 123,432ms !X *
Unter Windows:
C:\Users\kda>tracert -d www.heise.de
Routenverfolgung zu www.heise.de [193.99.144.85] über maximal 30 Hops:
1 58 ms 59 ms 62 ms 10.8.0.1
2 57 ms 59 ms 57 ms 192.168.3.1
3 62 ms 62 ms 62 ms 80.133.249.82
4 68 ms 75 ms 66 ms 217.0.195.137
5 68 ms 70 ms 71 ms 62.157.251.38
6 70 ms 70 ms 69 ms 82.98.102.7
7 73 ms 74 ms 69 ms 82.98.102.23
8 67 ms 67 ms 69 ms 212.19.61.13
9 70 ms 73 ms 67 ms 193.99.144.85
Ablaufverfolgung beendet.
Probleme:
- 1) Im Browser (Firefox oder Chrom) 'dnsleaktest.com' geöffnet und bei erfolgreicher VPN Einwahl wird auf der Seite die öffentliche IP Adresse der FritzBox zu Hause angezeigt. Der Standard-Test der Seite läuft durch, aber der Extended-Test bleibt hängen.
Aber nicht beim iPad oder beim Laptop mit Win10 - hier funktioniert es.
- 2) Im Browser kann ich meinen WebMailer www.posteo.de aufgrufen und UID/PWD eingeben, aber nach "Enter" passiert lange nichts (mehrere Minuten) und dann kommt die Fehlermeldung, dass die Seite nicht erreicht werden kann.
Aber nicht beim Laptop mit Win10 (iPad nicht getestet).
- 3) Ich kann mich zu Hause in die Fritzbox einloggen, ebenso in den Raspberry-VPNS und auch Dateien im NAS sehen. Wenn ich aber anfange Dateien (Umfang pdf-Dokumente mit eingen Seiten) vom NAS zu laden oder dorthin zu schieben, hängt die Konsole bzw. der Prozess und es geht nicht weiter. Das Hängen den Konsole geschieht häufig auch, wenn ich bspw. auf dem Raspberry-VPNS ein 'find /' mache, also viel Text in der Konsole anzuzeigen ist.
Aber nicht beim Laptop mit Win10 (iPad und Handy nicht getestet).
Positive Szenarien:
- 4) bash.ws/dnsleak funktioniert
- 5) Die beiden erstgenannten Probleme treten mit dem Android Handy nicht auf, wenn es selbst per mobiles Netz und dann per VPN verbunden ist (das dritte Problem habe ich nicht getestet).
- 6) Wenn ich mit einem iPhone einen Hotspot erzeuge, wird ein Netz mit 172.20.10.0/28 erzeugt. Hier funktionieren jetzt die eben geschilderten drei Fälle ohne Probleme mit dem Laptop Mint19.3 und auch dem Raspberry-AP (der hat testweise auch einen Desktop mit Browser installiert bekommen). Der Raspberry-AP in seiner zweiten Funktion als AP erzeugt selbst ein 192.168.4.0/24 Netz. Auch wenn hier der Laptop mit Mint19.3 mit dem Raspberry AP verbunden ist, der Raspberry AP per VPN zu Hause ins Internet geht, funktioniert es. In diesem Fall ist das vom Raspberry-AP als AP aufgespannte 192.168.4.0/24 Netz kein Problem.
Zusammenfassung des Problems:
Kurz gesagt:
IO: Laptop Mint19.3 VPNC - 172.20.10.0-iPhone/28 - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
NIO: Laptop Mint19.3 VPNC - 192.168.44.0-Hotel/22 - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
NIO: Laptop Mint19.3 VPNC - 192.168.43.0-Handy/24 - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
IO: Laptop Window10 VPNC - 172.20.10.0-iPhone/28 - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
IO: Laptop Window10 VPNC - 192.168.44.0-Hotel/22 - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
IO: Laptop Window10 VPNC - 192.168.43.0-Handy/24 - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
IO: (Laptop Mint19.3 - 192.168.4.0/24) - Raspberry-AP VPNC - 172.20.10.0/28-iPhone - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
NIO: (Laptop Mint19.3 - 192.168.4.0/24) - Raspberry-AP VPNC - 192.168.44.0/22-Hotel - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
NIO: (Laptop Mint19.3 - 192.168.4.0/24) - Raspberry-AP VPNC - 192.168.43.0/24-Handy - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
Anmerkungen:
- NIO heisst, dass das VPN steht und genutzt werden kann, aber nicht alles funktioniert.
- IO Windows10 könnte auch bedeuten, dass Windows doch am VPN vorbei arbeitet (...)
Bitte um Unterstützung
Die Fragen sind, was genau hier das Problem ist und was gemacht werden muss, um das zu beheben?
Einiges funktioniert und die 192.168(.3/24|.44/22|.43/24) Netze sind ja nicht identisch, sollte doch machbar sein!?
Technische Details:
Im offenen Hotel-WLAN bekam ich für den Laptop/Mint19.3
kda@LT-I73615QM:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.44.1 0.0.0.0 UG 600 0 0 wlp2s0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0
192.168.44.0 0.0.0.0 255.255.252.0 U 600 0 0 wlp2s0
kda@LT-I73615QM:~$ systemd-resolve --status
Global
DNSSEC NTA: 10.in-addr.arpa
[...]
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 3 (wlp2s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 176.9.1.117 (DNS Server manuell für das WLAN angegeben!)
DNS Domain: ~.
Link 2 (enp3s0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
und unter Windows10 folgendes:
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.44.1 192.168.45.163 55
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.44.0 255.255.252.0 Auf Verbindung 192.168.45.163 311
192.168.45.163 255.255.255.255 Auf Verbindung 192.168.45.163 311
192.168.47.255 255.255.255.255 Auf Verbindung 192.168.45.163 311
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.45.163 311
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.45.163 311
===========================================================================
Ständige Routen:
Keine
Nach VPN Verbindungsaufbau:
Unter Linux:
kda@LT-I73615QM:~$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.0.1 128.0.0.0 UG 0 0 0 tun0
0.0.0.0 192.168.44.1 0.0.0.0 UG 600 0 0 wlp2s0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
80.133.249.82 192.168.44.1 255.255.255.255 UGH 0 0 0 wlp2s0
128.0.0.0 10.8.0.1 128.0.0.0 UG 0 0 0 tun0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlp2s0
192.168.44.0 0.0.0.0 255.255.252.0 U 600 0 0 wlp2s0
kda@LT-I73615QM:~$ systemd-resolve --status
Global
DNSSEC NTA: 10.in-addr.arpa
[...]
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 6 (tun0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 10.8.0.1 (Raspberry VPNS als DNS Server)
DNS Domain: ~.
Link 3 (wlp2s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 176.9.1.117 (DNS Server manuell für das WLAN angegeben!)
DNS Domain: ~.
Link 2 (enp3s0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
und unter Windows10
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.44.1 192.168.45.163 55
0.0.0.0 128.0.0.0 10.8.0.1 10.8.0.4 259
10.8.0.0 255.255.255.0 Auf Verbindung 10.8.0.4 259
10.8.0.4 255.255.255.255 Auf Verbindung 10.8.0.4 259
10.8.0.255 255.255.255.255 Auf Verbindung 10.8.0.4 259
80.133.249.82 255.255.255.255 192.168.44.1 192.168.45.163 311
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
128.0.0.0 128.0.0.0 10.8.0.1 10.8.0.4 259
192.168.44.0 255.255.252.0 Auf Verbindung 192.168.45.163 311
192.168.45.163 255.255.255.255 Auf Verbindung 192.168.45.163 311
192.168.47.255 255.255.255.255 Auf Verbindung 192.168.45.163 311
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.8.0.4 259
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.45.163 311
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.8.0.4 259
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.45.163 311
===========================================================================
Ständige Routen:
Keine
Raspberry-VPNS Config
pi@RP3-2:~ $ cat /etc/openvpn/server.conf
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server_SPtFAtJiSPjOkCaW.crt
key /etc/openvpn/easy-rsa/pki/private/server_SPtFAtJiSPjOkCaW.key
dh none
topology subnet
push "topology subnet"
server 10.8.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 10.8.0.1"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client 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.
push "redirect-gateway def1"
#push "route 192.168.3.0 255.255.255.0"
client-to-client
keepalive 1800 3600
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#duplicate-cn
# Generated for use by PiVPN.io
Mit folgender client ovpn-config baue ich das VPN unter Mint19.3 auf:
client
dev tun
proto udp
remote mypublicservername.dd-dns.de 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
tls-version-min 1.2
verify-x509-name server_SPtSRtJiSPjOkCaW name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
# Use DNS server given bei VPN-Server only
script-security 2
up /etc/openvpn/update-systemd-resolved
down /etc/openvpn/update-systemd-resolved
down-pre
dhcp-option DOMAIN-ROUTE .
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----
</key>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-crypt>
Diese Inhalte, allerdings ohne die Zeilen 17 bis 21, nutze ich auch unter Windows.
Verbinden unter Linux:
kda@LT-I73615QM:~$ sudo openvpn --config ovpns/s700.ovpn
Sun Jun 7 13:58:26 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Sun Jun 7 13:58:26 2020 library versions: OpenSSL 1.1.1 11 Sep 2018, LZO 2.08
Sun Jun 7 13:58:26 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Enter Private Key Password: *****************
Sun Jun 7 13:58:30 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun Jun 7 13:58:30 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jun 7 13:58:30 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sun Jun 7 13:58:30 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sun Jun 7 13:58:30 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]80.133.249.82:1194
Sun Jun 7 13:58:30 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Jun 7 13:58:30 2020 UDP link local: (not bound)
Sun Jun 7 13:58:30 2020 UDP link remote: [AF_INET]80.133.249.82:1194
Sun Jun 7 13:58:30 2020 TLS: Initial packet from [AF_INET]80.133.249.82:1194, sid=c8a78657 aa82e5ec
Sun Jun 7 13:58:31 2020 VERIFY OK: depth=1, CN=ChangeMe
Sun Jun 7 13:58:31 2020 VERIFY KU OK
Sun Jun 7 13:58:31 2020 Validating certificate extended key usage
Sun Jun 7 13:58:31 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sun Jun 7 13:58:31 2020 VERIFY EKU OK
Sun Jun 7 13:58:31 2020 VERIFY X509NAME OK: CN=server_SPtFAtJiSPjOkCaW
Sun Jun 7 13:58:31 2020 VERIFY OK: depth=0, CN=server_SPtFAtJiSPjOkCaW
Sun Jun 7 13:58:31 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit EC, curve: prime256v1
Sun Jun 7 13:58:31 2020 [server_SPtFAtJiSPjOkCaW] Peer Connection Initiated with [AF_INET]80.133.249.82:1194
Sun Jun 7 13:58:32 2020 SENT CONTROL [server_SPtFAtJiSPjOkCaW]: 'PUSH_REQUEST' (status=1)
Sun Jun 7 13:58:32 2020 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.8.0.1,block-outside-dns,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 1800,ping-restart 3600,ifconfig 10.8.0.2 255.255.255.0,peer-id 1,cipher AES-256-GCM'
Sun Jun 7 13:58:32 2020 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:2: block-outside-dns (2.4.4)
Sun Jun 7 13:58:32 2020 OPTIONS IMPORT: timers and/or timeouts modified
Sun Jun 7 13:58:32 2020 OPTIONS IMPORT: --ifconfig/up options modified
Sun Jun 7 13:58:32 2020 OPTIONS IMPORT: route options modified
Sun Jun 7 13:58:32 2020 OPTIONS IMPORT: route-related options modified
Sun Jun 7 13:58:32 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Jun 7 13:58:32 2020 OPTIONS IMPORT: peer-id set
Sun Jun 7 13:58:32 2020 OPTIONS IMPORT: adjusting link_mtu to 1624
Sun Jun 7 13:58:32 2020 OPTIONS IMPORT: data channel crypto options modified
Sun Jun 7 13:58:32 2020 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun Jun 7 13:58:32 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Jun 7 13:58:32 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sun Jun 7 13:58:32 2020 ROUTE_GATEWAY 192.168.44.1/255.255.252.0 IFACE=wlp2s0 HWADDR=c4:85:08:0a:4b:23
Sun Jun 7 13:58:32 2020 TUN/TAP device tun0 opened
Sun Jun 7 13:58:32 2020 TUN/TAP TX queue length set to 100
Sun Jun 7 13:58:32 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sun Jun 7 13:58:32 2020 /sbin/ip link set dev tun0 up mtu 1500
Sun Jun 7 13:58:32 2020 /sbin/ip addr add dev tun0 10.8.0.2/24 broadcast 10.8.0.255
Sun Jun 7 13:58:32 2020 /etc/openvpn/update-systemd-resolved tun0 1500 1552 10.8.0.2 255.255.255.0 init
<14>Jun 7 13:58:32 update-systemd-resolved: Link 'tun0' coming up
<14>Jun 7 13:58:32 update-systemd-resolved: Adding DNS Routed Domain .
<14>Jun 7 13:58:32 update-systemd-resolved: Adding IPv4 DNS Server 10.8.0.1
<14>Jun 7 13:58:32 update-systemd-resolved: SetLinkDNS(6 1 2 4 10 8 0 1)
<14>Jun 7 13:58:32 update-systemd-resolved: SetLinkDomains(6 1 . true)
Sun Jun 7 13:58:32 2020 /sbin/ip route add 80.133.249.82/32 via 192.168.44.1
Sun Jun 7 13:58:32 2020 /sbin/ip route add 0.0.0.0/1 via 10.8.0.1
Sun Jun 7 13:58:32 2020 /sbin/ip route add 128.0.0.0/1 via 10.8.0.1
Sun Jun 7 13:58:32 2020 Initialization Sequence Completed
Verbinden mit Windows10
Sat Jun 06 13:30:01 2020 OpenVPN 2.4.9 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 16 2020
Sat Jun 06 13:30:01 2020 Windows version 6.2 (Windows 8 or greater) 64bit
Sat Jun 06 13:30:01 2020 library versions: OpenSSL 1.1.1f 31 Mar 2020, LZO 2.10
Sat Jun 06 13:30:01 2020 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sat Jun 06 13:30:01 2020 Need hold release from management interface, waiting...
Sat Jun 06 13:30:02 2020 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sat Jun 06 13:30:02 2020 MANAGEMENT: CMD 'state on'
Sat Jun 06 13:30:02 2020 MANAGEMENT: CMD 'log all on'
Sat Jun 06 13:30:02 2020 MANAGEMENT: CMD 'echo all on'
Sat Jun 06 13:30:02 2020 MANAGEMENT: CMD 'bytecount 5'
Sat Jun 06 13:30:02 2020 MANAGEMENT: CMD 'hold off'
Sat Jun 06 13:30:02 2020 MANAGEMENT: CMD 'hold release'
Sat Jun 06 13:30:09 2020 MANAGEMENT: CMD 'password [...]'
Sat Jun 06 13:30:09 2020 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Jun 06 13:30:09 2020 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Jun 06 13:30:09 2020 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Sat Jun 06 13:30:09 2020 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Jun 06 13:30:09 2020 MANAGEMENT: >STATE:1591443009,RESOLVE,,,,,,
Sat Jun 06 13:30:09 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]80.133.249.82:1194
Sat Jun 06 13:30:09 2020 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sat Jun 06 13:30:09 2020 UDP link local: (not bound)
Sat Jun 06 13:30:09 2020 UDP link remote: [AF_INET]80.133.249.82:1194
Sat Jun 06 13:30:09 2020 MANAGEMENT: >STATE:1591443009,WAIT,,,,,,
Sat Jun 06 13:30:09 2020 MANAGEMENT: >STATE:1591443009,AUTH,,,,,,
Sat Jun 06 13:30:09 2020 TLS: Initial packet from [AF_INET]80.133.249.82:1194, sid=2dae4a85 f79f7be5
Sat Jun 06 13:30:09 2020 VERIFY OK: depth=1, CN=ChangeMe
Sat Jun 06 13:30:09 2020 VERIFY KU OK
Sat Jun 06 13:30:09 2020 Validating certificate extended key usage
Sat Jun 06 13:30:09 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Jun 06 13:30:09 2020 VERIFY EKU OK
Sat Jun 06 13:30:09 2020 VERIFY X509NAME OK: CN=server_SPtFAtJiSPjOkCaW
Sat Jun 06 13:30:09 2020 VERIFY OK: depth=0, CN=server_SPtFAtJiSPjOkCaW
Sat Jun 06 13:30:09 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit EC, curve: prime256v1
Sat Jun 06 13:30:09 2020 [server_SPtFAtJiSPjOkCaW] Peer Connection Initiated with [AF_INET]80.133.249.82:1194
Sat Jun 06 13:30:10 2020 MANAGEMENT: >STATE:1591443010,GET_CONFIG,,,,,,
Sat Jun 06 13:30:10 2020 SENT CONTROL [server_SPtFAtJiSPjOkCaW]: 'PUSH_REQUEST' (status=1)
Sat Jun 06 13:30:10 2020 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 10.8.0.1,block-outside-dns,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 1800,ping-restart 3600,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Sat Jun 06 13:30:10 2020 OPTIONS IMPORT: timers and/or timeouts modified
Sat Jun 06 13:30:10 2020 OPTIONS IMPORT: --ifconfig/up options modified
Sat Jun 06 13:30:10 2020 OPTIONS IMPORT: route options modified
Sat Jun 06 13:30:10 2020 OPTIONS IMPORT: route-related options modified
Sat Jun 06 13:30:10 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Jun 06 13:30:10 2020 OPTIONS IMPORT: peer-id set
Sat Jun 06 13:30:10 2020 OPTIONS IMPORT: adjusting link_mtu to 1624
Sat Jun 06 13:30:10 2020 OPTIONS IMPORT: data channel crypto options modified
Sat Jun 06 13:30:10 2020 Data Channel: using negotiated cipher 'AES-256-GCM'
Sat Jun 06 13:30:10 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Jun 06 13:30:10 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Jun 06 13:30:10 2020 interactive service msg_channel=632
Sat Jun 06 13:30:10 2020 ROUTE_GATEWAY 192.168.44.1/255.255.252.0 I=12 HWADDR=c4:85:08:0a:4b:23
Sat Jun 06 13:30:10 2020 open_tun
Sat Jun 06 13:30:10 2020 TAP-WIN32 device [LAN-Verbindung] opened: \\.\Global\{6AAC7603-18FF-496E-B5C6-37B5CE989FDA}.tap
Sat Jun 06 13:30:10 2020 TAP-Windows Driver Version 9.24
Sat Jun 06 13:30:10 2020 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.2/255.255.255.0 [SUCCEEDED]
Sat Jun 06 13:30:10 2020 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.255.0 on interface {6AAC7603-18FF-496E-B5C6-37B5CE989FDA} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
Sat Jun 06 13:30:10 2020 Successful ARP Flush on interface [4] {6AAC7603-18FF-496E-B5C6-37B5CE989FDA}
Sat Jun 06 13:30:10 2020 MANAGEMENT: >STATE:1591443010,ASSIGN_IP,,10.8.0.2,,,,
Sat Jun 06 13:30:10 2020 Blocking outside dns using service succeeded.
Sat Jun 06 13:30:15 2020 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Sat Jun 06 13:30:15 2020 C:\Windows\system32\route.exe ADD 80.133.249.82 MASK 255.255.255.255 192.168.44.1
Sat Jun 06 13:30:15 2020 Route addition via service succeeded
Sat Jun 06 13:30:15 2020 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Sat Jun 06 13:30:15 2020 Route addition via service succeeded
Sat Jun 06 13:30:15 2020 C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.1
Sat Jun 06 13:30:15 2020 Route addition via service succeeded
Sat Jun 06 13:30:15 2020 Initialization Sequence Completed
Sat Jun 06 13:30:15 2020 MANAGEMENT: >STATE:1591443015,CONNECTED,SUCCESS,10.8.0.2,80.133.249.82,1194,,
Beenden VPN unter Linux:
Sat Jun 6 20:14:34 2020 event_wait : Interrupted system call (code=4)
Sat Jun 6 20:14:34 2020 /sbin/ip route del 80.133.249.82/32
Sat Jun 6 20:14:34 2020 /sbin/ip route del 0.0.0.0/1
Sat Jun 6 20:14:34 2020 /sbin/ip route del 128.0.0.0/1
Sat Jun 6 20:14:34 2020 /etc/openvpn/update-systemd-resolved tun0 1500 1552 10.8.0.2 255.255.255.0 init
<14>Jun 6 20:14:34 update-systemd-resolved: Link 'tun0' going down
Sat Jun 6 20:14:34 2020 Closing TUN/TAP interface
Sat Jun 6 20:14:34 2020 /sbin/ip addr del dev tun0 10.8.0.2/24
Sat Jun 6 20:14:34 2020 SIGINT[hard,] received, process exiting
Beenden VPN unter Windows10
Sat Jun 06 13:34:59 2020 C:\Windows\system32\route.exe DELETE 80.133.249.82 MASK 255.255.255.255 192.168.44.1
Sat Jun 06 13:34:59 2020 Route deletion via service succeeded
Sat Jun 06 13:34:59 2020 C:\Windows\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.8.0.1
Sat Jun 06 13:34:59 2020 Route deletion via service succeeded
Sat Jun 06 13:34:59 2020 C:\Windows\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.8.0.1
Sat Jun 06 13:34:59 2020 Route deletion via service succeeded
Sat Jun 06 13:34:59 2020 Closing TUN/TAP interface
Sat Jun 06 13:34:59 2020 TAP: DHCP address released
Sat Jun 06 13:34:59 2020 Unblocking outside dns using service succeeded.
Sat Jun 06 13:34:59 2020 SIGTERM[hard,] received, process exiting
Sat Jun 06 13:34:59 2020 MANAGEMENT: >STATE:1591443299,EXITING,SIGTERM,,,,,
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 582705
Url: https://administrator.de/contentid/582705
Ausgedruckt am: 28.03.2024 um 20:03 Uhr
12 Kommentare
Neuester Kommentar
Moin,
schön ausführlich, aber hätte hier gar nicht müssen sein. Da das Hotel Subnetz größer ist, als deines wird der Traffic einfach nicht hingeroutet, sprich du musst dein Netz daheim umstellen.
https://www.heise.de/netze/tools/netzwerkrechner/
Das war es schon.
Grüße,
Christian
certifiedit.net
schön ausführlich, aber hätte hier gar nicht müssen sein. Da das Hotel Subnetz größer ist, als deines wird der Traffic einfach nicht hingeroutet, sprich du musst dein Netz daheim umstellen.
https://www.heise.de/netze/tools/netzwerkrechner/
Das war es schon.
Grüße,
Christian
certifiedit.net
Das ist die Crux wenn man sich VORHER keine Gedanken macht über eine sinnvolle IP Adressierung im VPN Betrieb und diese dümmlichen 192.168er Netze verwendet die millionenfach in Nutzung sind mit wilden CIDR Prefixes. Sowas rächt sich dann früher oder später.
Der RFC 1918 Bereich der privaten IP Netze bietet eine Menge intelligenter Alternativen wenn man einmal etwas nachdenkt. RFC 6598 wäre auch eine durchaus intelligente Alternative.
Siehe auch hier:
VPNs einrichten mit PPTP
Lesen und verstehen !
Der Rest ist wie immer in den hiesigen OpenVPN Tutorials umfassend erklärt !
Merkzettel: VPN Installation mit OpenVPN
bzw. hier für LAN zu LAN Kopplung:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Problem 1:
Das ist ja auch normal. Du machst auf allen Clients einen Gateway Redirect, sprich mit aktivem VPN Client wird den Clients als einziger DNS Server die interne OVPN IP des VPN Servers gepusht.
Vermutlich rennt hier ein Caching Inbound DNS der lokale Namen im Heimnetz beantwortet und dann an die heimische FritzBox weiterreicht. Deshalb wird für externe Domain Namen natürlich die FB angezeigt. Works as designed. Wenn man keine lokalen Namen aufzulösen hat könnte man hier auch die FritzBox IP pushen als DNS.
Problem 2:
Dürfte normal nicht passieren. Es sei denn du machst überflüssigerweise NAT (Adress Translation) im VPN Tunnel was natürlich dann fatal wäre.
Leider schreibst du zu den iptables Settings des RasPis nichts. Hier darf KEIN irgendwie geartetes NAT im Tunnel gemacht werden.
Problem 3:
Das sieht sehr nach einem MTU Mismatch aus. Hast du die Tunnel MTU im OpenVPN entsprechend angepasst ?!! Das ist sehr wichtig sonst kommt es zu solchen Hängern, weil du im Heimnetz zusätzlich zum OVPN SSL Header noch den PPPoE Header hast.
Der RFC 1918 Bereich der privaten IP Netze bietet eine Menge intelligenter Alternativen wenn man einmal etwas nachdenkt. RFC 6598 wäre auch eine durchaus intelligente Alternative.
Siehe auch hier:
VPNs einrichten mit PPTP
Lesen und verstehen !
Der Rest ist wie immer in den hiesigen OpenVPN Tutorials umfassend erklärt !
Merkzettel: VPN Installation mit OpenVPN
bzw. hier für LAN zu LAN Kopplung:
OpenVPN - Erreiche Netzwerk hinter Client nicht
Problem 1:
Das ist ja auch normal. Du machst auf allen Clients einen Gateway Redirect, sprich mit aktivem VPN Client wird den Clients als einziger DNS Server die interne OVPN IP des VPN Servers gepusht.
Vermutlich rennt hier ein Caching Inbound DNS der lokale Namen im Heimnetz beantwortet und dann an die heimische FritzBox weiterreicht. Deshalb wird für externe Domain Namen natürlich die FB angezeigt. Works as designed. Wenn man keine lokalen Namen aufzulösen hat könnte man hier auch die FritzBox IP pushen als DNS.
Problem 2:
Dürfte normal nicht passieren. Es sei denn du machst überflüssigerweise NAT (Adress Translation) im VPN Tunnel was natürlich dann fatal wäre.
Leider schreibst du zu den iptables Settings des RasPis nichts. Hier darf KEIN irgendwie geartetes NAT im Tunnel gemacht werden.
Problem 3:
Das sieht sehr nach einem MTU Mismatch aus. Hast du die Tunnel MTU im OpenVPN entsprechend angepasst ?!! Das ist sehr wichtig sonst kommt es zu solchen Hängern, weil du im Heimnetz zusätzlich zum OVPN SSL Header noch den PPPoE Header hast.
Zitat von @WhiteShad:
[...] In zwei dokumentierten Fällen nutzt das unterwegs zur Verfügung stehende WLAN (Hotel oder Handy Hotspot) das 192.168 Netz wie folgt:[...]
[...] In zwei dokumentierten Fällen nutzt das unterwegs zur Verfügung stehende WLAN (Hotel oder Handy Hotspot) das 192.168 Netz wie folgt:[...]
In der Zeit, in der Du die Frage verfasst hast, hättest Du auch Dein Netz auf ein 10.###.###.*** - Netz umstellen können.
Spätestens, wenn Du aus seinem 192.168er-Netz mal eine Verbindung zu einem hilfesuchenden 192.168er Netz aufbauen möchtest und auch dieses nicht optimal konfiguriert ist, kommen wieder Probleme auf Dich zu.
In einem 10er Netz bist Du frei bei der Wahl der Nummerierung der Blöcke 2 und 3 und kannst Dir merkbare oder passende Nummern auswählen und nach PLZ, Vorwahl, Geburtstag oder wwi sortieren.
Muss ja nicht jetzt sein, aber beim nächsten Gerätewechsel könnte man nochmal drüber nachdenken...
Gruß
Zitat von @WhiteShad:
Wenn schon ähnliche Netze Probleme machen, sollte ich nicht auf ein 10er umstellen, da mein AG auch ein 10er hat.
Wenn schon ähnliche Netze Probleme machen, sollte ich nicht auf ein 10er umstellen, da mein AG auch ein 10er hat.
Funktioniert bei mir und im Büro problemlos.
In beide Richtungen.
Und 10.xxx. sind dabei identisch.
Gastnetze sind auch Berücksichtigt.
Subnetzmasken sind auch gesetzt.
Bei beiden Netzen kenne ich aber die Konfigurationen.
und
schlecht konfigurierte Netze können immer Probleme bereiten.