whiteshad
Goto Top

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:
  • 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.
Das passiert beim Laptop mit Mint19.3, beim Android Handy (via Hotel WLAN) und beim Raspberry AP.
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.
Das passiert beim Laptop mit Mint19.3, beim Android Handy (via Hotel WLAN) und beim Raspberry AP.
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.
Das passiert beim Laptop mit Mint19.3 und beim Raspberry AP.
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,,,,,

Content-Key: 582705

Url: https://administrator.de/contentid/582705

Ausgedruckt am: 28.03.2024 um 20:03 Uhr

Mitglied: falscher-sperrstatus
falscher-sperrstatus 27.06.2020 um 15:15:18 Uhr
Goto Top
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
Mitglied: aqui
aqui 27.06.2020 aktualisiert um 16:26:29 Uhr
Goto Top
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 ! face-wink
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.
Mitglied: WhiteShad
WhiteShad 27.06.2020, aktualisiert am 28.06.2020 um 00:33:03 Uhr
Goto Top
Danke für die schnelle Reaktionen face-smile

@aqui
Die drei URLs hatte ich bereits gefunden und den Inhalt gelesen (vestehen... mal sehen face-wink)

CRUX
Wie ich ja schon geschrieben habe, ist mir bewusst, dass das 192.168.3.x Netz zu Hause suboptimal ist.

AFAIU sind die Netze hier in meinem Fall ja nicht identisch (sondern nur ähnlich) und in dem Beispiel LAN zu LAN kommen ja auch beiden Seiten auch 192.168 Netze zum Einsatz, nur habe ich im Falle eines Hotel ja nicht die Möglichkeit auf dem Router des Hotels eine statische Route einzutragen und ich möchte ja auch nicht allen Clients des Hotel Netzes Zugriff auf mein lokales Netz geben.

Zu Problem 1:
Mein Problem 1 ist nicht, dass die IP meiner Fritzbox auf der Website angezeigt wird (ansonsten hätte das VPN an dieser Stelle ja nicht funktioniert), sondern dass die auf der Website angebotene Funktion über zwei Buttons (Standard Test und Extended Test) nur im ersten Fall funktioniert. Im Extended Test wird auch ein größeres JSON zum Server geschickt und darauf erhält der Browser keine Antwort mehr:
{"identifiers":["8f0ee6c8-2bdd-4b7b-a18a-5b02edf2c182","85671c0e-4d96-4122-bde9-fbf44b04cb5f","5a44b333-dd32-4693-9da9-b4f175afcc19","fe468e6b-8be6-418b-9650-7ac0213df8e6","ecee00b2-e1ee-43e5-be38-58ee187bb733","06ee6dde-97d2-46b8-be0c-0c11318f0ffe","8b4422b2-a438-43d9-8473-4ebfe6950bac","5201a765-78c9-40d1-bdd0-585c27bbafe8","7ec9c21a-5fe4-4b47-87ae-233f699e3773","38e23d23-1503-4425-beed-00f6343a126c","3dea9476-3a73-46b8-a8c9-9c6429a0eba9","fbde7982-3933-475d-acfe-3a6475a956ae","c14d33fe-6645-421a-9526-7a48ef6bb4dc","9324c433-bceb-47ce-bd09-17774a73af25","1c0eded5-582b-4641-9513-8de99b26cd43","2e938739-928a-4f2d-9763-4fbccd4f66d7","aacafb0b-bc68-436c-976d-b77fd71308b0","eb930973-f72e-45b8-b00d-87e6b07db024","27f990c1-4d22-42ac-9ce6-4fce0e1f4732","45209ee2-0669-4099-abc9-f22a6a869daa","3176e1ba-1356-4324-a3fc-587f11636cf4","f4db8969-ae44-4790-b27d-b5d6851803a4","04669071-89dd-4f5d-be2f-1fc67e6d8144","802e9d87-ec98-43b2-91ce-c13efed79cfc","fdbc1d68-a177-4559-ad29-8e8da7cc4c92","57bac8ce-4864-4358-b7e6-33952edffba4","c147afba-5977-4dcb-8c94-e8d5cae8ea21","fc05c3de-383b-4ef7-98d4-47784ece6748","de45f5d5-b95d-4a9d-8970-ad825fe651e9","68115b84-4364-45ba-afc3-36bf66921e5c","04834534-6ae5-4b35-b07b-2aec4753ed77","85a1dfaa-6bce-4eb6-8cd2-f362d8c717e3","0a07a4c6-189a-4145-adaf-c210a13fae21","f170626d-8af3-4da1-87bd-763b79cc54f5","c0d0e43b-10d4-4735-9099-8d0385c9976d","f61e0616-076f-4d59-a1f7-7f52d611c270"]}  
vs
{"identifiers":["d7775d4b-a646-4b35-8852-8c4d68d73a7d","26b96ed5-0706-45c2-a8fa-798ca806bccf","baf1b839-b3c1-4632-b496-b488e710948e","18089275-8e67-473d-ad23-a4fd4cb6afde","e09be9c5-42cd-4610-8189-c807498e3108","7b1267b2-4728-4d6b-8cb3-c2ba419dc4bd"]}  

Zu Problem 2:
Ja sollte nicht passieren, wenn ich schon soweit gekommen bin (eigentlich sollte dann auch Problem 1 nicht auftreten).

Iptables auf dem Raspberry VPNS:
pi@RP3-2:~ $ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.8.0.0/24          anywhere

Problem 3:
Wenn es hier ein MTU-Mismatch sein sollte, dann könnte dies auch die Ursache für Problem 1+2 sein.
Dann sollte / könnte es ein Problem zu Hause sein...

Aber was ich dann nicht begreife, wieso es dann "as-is" unter Windows funktioniert
und ebenso unter Linux, wenn ich mit dem iPhone einen Hotspot mit 172.20.10.0/28 aufmache und per VPN nach Hause gehe.

Was passiert wenn ich dann zu Haus mein Netz bspw. auf 172.24.1.0 /24 umgestellt habe? Funktioniert dann der Hotspot mit dem iPhone nicht mehr, aber das WLAN vom Hotel oder der Hotspot von meinem Android Handy (192.168... s.o.)?

Das Problem muss doch grundsätzlich lösbar sein, solange die Netze local und remote nicht identisch sind.

@Christian (certifiedit.net)
Vielleicht verstehe ich das nicht richtig (und ich bin kein Netzwerker):
Unter "Hotel Subnetz größer ist, als deines" verstehe ich, dass mehr Clients angeschlossen werden können (/22 gegenüber /24),
dann wäre das Netz des Hotspots meines Handys genauso groß wie meines zu Hause.
In beiden Fällen wäre das kleinste Subnetz, das beide enthält 192.168.0.0/16. Aber das würde ja auch entstehen, wenn ich bspw. ein 172 Netz zu Hause aufbaue und das Hotel auch mit einem 172 Netz aufwartet. Da komme ich ja nie wirklich raus.

Auch hier: Das Problem muss doch grundsätzlich lösbar sein, solange die Netze local und remote nicht identisch sind.

"wird der Traffic einfach nicht hingeroutet"
Aber das passiert doch - oder was sehe ich hier nicht, das Du meinst?
Mitglied: falscher-sperrstatus
falscher-sperrstatus 28.06.2020 um 01:16:50 Uhr
Goto Top
Nein deine anfragen gehen einfach nicht raus. Das ist wie wenn du sagen würdest alles Nummern mit 1*** (1 bis 1999) gehen über Strecke x du danach aber eine niedrigere prio der Route zu 11* gibst. Klar dass die zweite Route dann einfach nicht mehr bedacht wird.
Mitglied: WhiteShad
WhiteShad 29.06.2020 aktualisiert um 01:00:19 Uhr
Goto Top
OK, Du beziehst Dich auf die "Metric" Werte.

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

Alles was mit tun0 und der Verbindung nach draußen zu tun hat, ist hoch priorisiert (0). Und wie geschrieben...
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  *
... funktioniert das auch.
Mitglied: WhiteShad
WhiteShad 29.06.2020 um 00:56:22 Uhr
Goto Top
IpTables: Der Eintrag ist essenziell:
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.8.0.0/24          anywhere

MTU:
Problem 3:
Wenn es hier ein MTU-Mismatch sein sollte, dann könnte dies auch die Ursache für Problem 1+2 sein.

Und so ist es / war es auch: Mit der zusätzlichen Zeile in der /etc/openvpn/server.conf
mssfix 1400
funktioniert es jetzt!

Details zu "mssfix" hier: https://blog.hambier.lu/post/solving-openvpn-mtu-issues#Recommendations

PS.: "Jetzt" bedeutet, dass ich das mit dem Hotspot meines Handys getestet habe, das aufgespannte Netz weicht ja von dem vom Hotel ab:
WLAN Hotel: 192.168.44.0/22
Hotspot Android Handy: 192.168.43.0/24
Leider kann ich das mit dem Hotel bis auf weiteres nicht testen - aber die nächste ähnliche Gelegenheit kommt bestimmt.

Und "Getestet" bedeutet
IO: 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 - 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 - 192.168.43.0/24-Handy - IP1 Internet IP2 - FritzBox-192.168.3.0/24 - Raspberry-VPNS & NAS
IO: Laptop Window10 - 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
Mitglied: falscher-sperrstatus
falscher-sperrstatus 29.06.2020 um 00:57:31 Uhr
Goto Top
du vergleichst hier komplett unterschiedliche Dinge, aber bitte. Ich hoffe, du machst das nicht beruflich face-smile
Mitglied: WhiteShad
WhiteShad 29.06.2020 aktualisiert um 01:12:40 Uhr
Goto Top
Ist schon spät, und ich habe aus Versehen die Windows-Routen angegeben... ist korrigiert, nun sind es die Linux Routen.

Wenn Du das nicht meintest, kann ich Dir immer noch nicht folgen.


EDIT:

"du vergleichst hier komplett unterschiedliche Dinge"

Jetzt mal bitte konkret: Was genau meinst Du?
Mitglied: Dilbert-MD
Dilbert-MD 29.06.2020 um 11:31:40 Uhr
Goto Top
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 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ß
Mitglied: WhiteShad
WhiteShad 29.06.2020 um 11:51:43 Uhr
Goto Top
Meinst Du, wenn ich ein 10er Netz habe, ist ein schlecht konfiguriertes 192.168er Netz kein Problem?
Wenn schon ähnliche Netze Probleme machen, sollte ich nicht auf ein 10er umstellen, da mein AG auch ein 10er hat.

Aber es ist doch so:
Bei einem schlecht konfigurierten Netz habe ich potenziell immer Probleme und es lag hier ja nicht an den 192.168er Netzen an sich.
Das Problem bei den 198.168er ist doch, dass es so viele davon gibt und ich eine hohe Wahrscheinlichkeit habe, auf ein Identisches zu treffen,
daher macht es Sinn auf ein anderes umzustellen, so dass die Wahrscheinlichkeit (hoffentlich) deutlich niedriger ist.

PS.: Ich werde demnächst das 192.168er Netz zu Hause umbauen. 10er oder 172er.. mal schauen.
Mitglied: falscher-sperrstatus
falscher-sperrstatus 29.06.2020 um 12:03:16 Uhr
Goto Top
Bei einem schlecht konfigurierten Netz habe ich potenziell immer Probleme und es lag hier ja nicht an den 192.168er Netzen an sich.

Das sagst du.
Mitglied: Dilbert-MD
Dilbert-MD 30.06.2020 um 00:16:22 Uhr
Goto Top
Zitat von @WhiteShad:
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.