justinh999
Experte
Hallo,
Ich versuche aktuell zwei Netztwerke per OpenVpn zu verbinden.
Ich nutzte dazu Tap (also eine Bridge) weil ich auch Layer 2 Verkehr zwischen beiden ermöglichen will.
In meinem heimatnetztwerk(Netztwerk A) läuft also jetzt ein OpenVpn Server mit folgender Config:
Die entsprechende Clientkonfiguaration dazu, sieht dann so aus:
Wie ich oben im Spoiler bereits geschrieben habe, funktioniert die ganze Verbindung (mit Anpassung des Default Gateways) unter Windows und Android einwandfrei. Unter Debian hingegen kann ich keine VPN-Verbindung aufbauen, da anscheinend die Route (damit der Verkehr an 192.168.188.0/23 übers VPN geleitet wird) nicht hinzugefügt werden kann, weil das System plötzlich keine Netzwerkverbindung mehr hat (Network is unreachable) bzw. 192.168.188.1, über die die Route gehen soll, nicht erreichbar ist.
Ich habe das sowohl mit meinem Raspberry Pi mit Pi OS, der in Netzwerk A steht, als auch mit einem Debian-Server, der in Netzwerk B steht (zum Zeitpunkt des Versuchs war ich selbst in Netzwerk A), probiert. Beide haben denselben Fehler, obwohl 192.168.188.0/23 für den Pi erreichbar sein muss, da er physisch per LAN mit diesem Netzwerk verbunden ist.
Ich habe auch schon überlegt demm tap0 Interface manuell eine IP Adresse festzulegen (wie bei Windows) aber dass tap0 Interface existiert anscheinend nur, wenn OpenVPN läuft.
Weiß eventuell jemand von euch, was hier dass Problem sein könnte?
Ich bedanke mich schonmal im Vorauß für eure Hilfe.
Ergänzung:
Ich habe jetzt den Pi nochmal aus dem Netzwerk A gelöscht und den Router so gezwungen, ihm eine neue IP-Adresse zu geben. Jetzt funktioniert es innerhalb des Netzwerks. Das macht zwar eigentlich keinen Sinn, weil der Pi vorher über seine vorher vergebene IP auch erreichbar war, aber zumindest besteht das Problem jetzt nur noch aus allen externen Netzwerken.
Ergänzung #2 31.10.2024 20:45
Ich denke ich habe einige neue Wissenswerte Infos.
Dass Tap0 Interface was von OpenVPN erstellt wird ist erstmal down.
ich kann dass ganze via sudo ip link set tap0 auch up setzten aber dass alleine bringt mir nichts.
Wenn ich dann aber dhclient tap0 ausführe (dauert teilweise fast 20 Sekunden) bekommt dass Interface plötzlich eine IP zugewießen und es werden 2 neue IP Routen erstellt die auf Netztwerk A führen:
Gut in diesem Fall wird alles übers Netztwerk A geleitet aber die entsprechende Route zu entfernen ist ja kein Hexenwerk.
Wenn ich jetzt nocheinmal versuche die 192.168.188.1 (private IPV4 Adresse des VPN Servers ) anzupingen erhalte ich ein von der 192.168.188.251(die IP Adresse des tap Interfaces) Destination Host Unreachable zurück(wenn ich die Adresse ohne VPN anpinge bekomme ich gar nichts zurück).
Prinzipiel scheint aber Vekehr übers VPN zu laufen, dass tap0 bekommt seine IP Adresse über den DHCP Server von Netzterk A (192.168.188.1) aber dann macht es keinen Sinn warum ich den DHCP Servr nicht anpingen kann.
Ich versuche aktuell zwei Netztwerke per OpenVpn zu verbinden.
Ich nutzte dazu Tap (also eine Bridge) weil ich auch Layer 2 Verkehr zwischen beiden ermöglichen will.
In meinem heimatnetztwerk(Netztwerk A) läuft also jetzt ein OpenVpn Server mit folgender Config:
Code:
proto udp
dev tap0
#Helperline for rc.openvpn to add tap0 to lan bridge and use LAN IP
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
tls-auth /tmp/flash/openvpn/static.key 0
port 1194
push "route-gateway 192.168.188.1"
push "route 192.168.188.0 255.255.254.0"
max-clients 5
mode server
push "route 192.168.188.1"
tun-mtu 1500
mssfix
verb 3
cipher AES-256-GCM
keepalive 10 20
user openvpn
group openvpn
persist-tun
persist-key
Code:
remote 9rad0ryy9u3at0x0.myfritz.net
proto udp
dev tap
tls-client
remote-cert-tls server
ca "C:\\projekts\\EasyRSA-3.2.1\\pki\\ca.crt"
cert "C:\\projekts\\EasyRSA-3.2.1\\pki\\issued\\justins_pc.crt"
key "C:\\projekts\\EasyRSA-3.2.1\\pki\\private\\justins_pc.key"
tls-auth "C:\\projekts\\openvpnstatic.key" 1
tun-mtu 1500
mssfix
nobind
pull
cipher AES-256-GCM
data-ciphers AES-256-GCM
verb 3Von meinen Android-Geräten kann ich mithilfe dieser Konfiguration und der App "VPN Client Pro" eine Verbindung herstellen(der ofiziele OpenVPN Android Client kann kein Bridging(tap)), und es funktioniert alles einwandfrei. Das einzige Problem ist, dass die App behauptet, den gesamten Datenverkehr von 0.0.0.0/0 zu 192.168.188.1 umzuleiten, was nicht stimmt. Tatsächlich läuft jeder Verkehr, der nicht nach 192.168.188.1/23 geht, über den normalen Netzwerkadapter.
Von Windows 11 mit der offiziellen OpenVPN GUI (also OpenVPN 2) funktioniert zunächst gar nichts. Laut Client-Log kann ich zwar erfolgreich eine Verbindung herstellen, aber sobald die Verbindung steht, kann ich nichts mehr machen. Ich kann weder Netzwerk A (z.B. mit einem Ping) erreichen noch ins Internet. Ich bin dann also offline.
Das Problem kann ich lösen, indem ich dem TAP-Netzwerkadapter, den OpenVPN erstellt, eine manuelle IP zuweise (dies kann dieselbe sein, die von OpenVPN per DHCP automatisch zugewiesen wird) und einfach kein Gateway festlege. Dann kann ich sowohl mein Heimnetzwerk als auch alles andere erreichen. Der Standardgateway für diesen Netzwerkadapter wird dann auf 192.168.188.1 gesetzt (was in der Server-Konfiguration auch als Push-Route festgelegt ist).
Selbst wenn Windows versuchen sollte, über diesen Adapter ins Internet zu gehen (über diesen Adapter soll eigentlich nur Verkehr zu 192.168.188/23 laufen, wie in der Server-Konfiguration als Push-Route festgelegt), sollte es funktionieren, da durch den VPN-Tunnel 192.168.188.1 eine erreichbare IP sein sollte (was sie in diesem Fall auch nicht ist).
Eine andere Vermutung von mir war, dass Windows eventuell gar keinen Verkehr über den TAP-Adapter (und damit übers VPN) leiten versucht, sondern stattdessen über den normalen Netzwerkadapter, über den es auch ohne die Netzwerkverbindung geht. Diese Vermutung konnte ich widerlegen, indem ich in meinem Heimnetzwerk (Netzwerk A) (dieser PC steht sowieso zu 100% immer im Netztwerk A und ich hatte ihn nur für den VPN-Versuch ins Mobilfunknetz getan) mit Windows versucht habe, eine VPN-Verbindung aufzubauen. Dort kann man das gleiche Phänomen wie oben beobachten, obwohl in diesem Fall über alle Adapter (sowohl der TAP- als auch der WLAN-Adapter) die 192.168.188.1 erreichbar sein muss.
Von Windows 11 mit der offiziellen OpenVPN GUI (also OpenVPN 2) funktioniert zunächst gar nichts. Laut Client-Log kann ich zwar erfolgreich eine Verbindung herstellen, aber sobald die Verbindung steht, kann ich nichts mehr machen. Ich kann weder Netzwerk A (z.B. mit einem Ping) erreichen noch ins Internet. Ich bin dann also offline.
Das Problem kann ich lösen, indem ich dem TAP-Netzwerkadapter, den OpenVPN erstellt, eine manuelle IP zuweise (dies kann dieselbe sein, die von OpenVPN per DHCP automatisch zugewiesen wird) und einfach kein Gateway festlege. Dann kann ich sowohl mein Heimnetzwerk als auch alles andere erreichen. Der Standardgateway für diesen Netzwerkadapter wird dann auf 192.168.188.1 gesetzt (was in der Server-Konfiguration auch als Push-Route festgelegt ist).
Selbst wenn Windows versuchen sollte, über diesen Adapter ins Internet zu gehen (über diesen Adapter soll eigentlich nur Verkehr zu 192.168.188/23 laufen, wie in der Server-Konfiguration als Push-Route festgelegt), sollte es funktionieren, da durch den VPN-Tunnel 192.168.188.1 eine erreichbare IP sein sollte (was sie in diesem Fall auch nicht ist).
Eine andere Vermutung von mir war, dass Windows eventuell gar keinen Verkehr über den TAP-Adapter (und damit übers VPN) leiten versucht, sondern stattdessen über den normalen Netzwerkadapter, über den es auch ohne die Netzwerkverbindung geht. Diese Vermutung konnte ich widerlegen, indem ich in meinem Heimnetzwerk (Netzwerk A) (dieser PC steht sowieso zu 100% immer im Netztwerk A und ich hatte ihn nur für den VPN-Versuch ins Mobilfunknetz getan) mit Windows versucht habe, eine VPN-Verbindung aufzubauen. Dort kann man das gleiche Phänomen wie oben beobachten, obwohl in diesem Fall über alle Adapter (sowohl der TAP- als auch der WLAN-Adapter) die 192.168.188.1 erreichbar sein muss.
Code:
Note: dev-type not tun, disabling data channel offload.
OpenVPN 2.6.12 [git:v2.6.12/038a94bae57a446c] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Jul 18 2024
Windows version 10.0 (Windows 10 or greater), amd64 executable
library versions: OpenSSL 3.3.1 4 Jun 2024, LZO 2.10
DCO version: 1.2.1
MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Need hold release from management interface, waiting...
MANAGEMENT: Client connected from [AF_INET]127.0.0.1:56177
MANAGEMENT: CMD 'state on'
MANAGEMENT: CMD 'log on all'
MANAGEMENT: CMD 'echo on all'
MANAGEMENT: CMD 'bytecount 5'
MANAGEMENT: CMD 'state'
MANAGEMENT: CMD 'hold off'
MANAGEMENT: CMD 'hold release'
MANAGEMENT: CMD 'password [...]'
WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
MANAGEMENT: >STATE:1730377107,RESOLVE,,,,,,
TCP/UDP: Preserving recently used remote address: [AF_INET][öffentliche ipv4 OpenVPn Server]:1194
Socket Buffers: R=[65536->65536] S=[65536->65536]
UDPv4 link local: (not bound)
UDPv4 link remote: [AF_INET][öffentliche ipv4 OpenVPn Server]:1194
MANAGEMENT: >STATE:1730377107,WAIT,,,,,,
MANAGEMENT: >STATE:1730377107,AUTH,,,,,,
TLS: Initial packet from [AF_INET][öffentliche ipv4 OpenVPn Server]:1194, sid=13f0a75d 2dde8053
VERIFY OK: depth=1, CN=Hahns Fritzbox unten
VERIFY KU OK
Validating certificate extended key usage
++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
VERIFY EKU OK
VERIFY OK: depth=0, CN=fritzbox_unten
Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 521 bits ECsecp521r1
[fritzbox_unten] Peer Connection Initiated with [AF_INET][öffentliche ipv4 OpenVPn Server]:1194
TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
TLS: tls_multi_process: initial untrusted session promoted to trusted
MANAGEMENT: >STATE:1730377109,GET_CONFIG,,,,,,
SENT CONTROL [fritzbox_unten]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.188.1,route 192.168.188.0 255.255.254.0,route 192.168.188.1,ping 10,ping-restart 20,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500'
OPTIONS IMPORT: route options modified
OPTIONS IMPORT: route-related options modified
OPTIONS IMPORT: tun-mtu set to 1500
interactive service msg_channel=792
ROUTE_GATEWAY 192.168.100.145/255.255.255.0 I=27 HWADDR=ae:fb:97:b6:02:7e
open_tun
tap-windows6 device [OpenVPN TAP-Windows6] opened
TAP-Windows Driver Version 9.27
Successful ARP Flush on interface [57] {E34D521A-A981-4F29-8529-3DB79F6628E2}
MANAGEMENT: >STATE:1730377109,ASSIGN_IP,,,,,,
Data Channel: cipher 'AES-256-GCM', peer-id: 0
Timers: ping 10, ping-restart 20
Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
TEST ROUTES: 0/0 succeeded len=-1 ret=1 a=0 u/d=up
WARNING: OpenVPN was configured to add an IPv4 route. However, no IPv4 has been configured for OpenVPN TAP-Windows6, therefore the route installation may fail or may not work as expected.
MANAGEMENT: >STATE:1730377114,ADD_ROUTES,,,,,,
C:\WINDOWS\system32\route.exe ADD 192.168.188.0 MASK 255.255.254.0 192.168.188.1
Route addition via service failed because route exists
C:\WINDOWS\system32\route.exe ADD 192.168.188.1 MASK 255.255.255.255 192.168.188.1
Route addition via service succeeded
Initialization Sequence Completed
MANAGEMENT: >STATE:1730377114,CONNECTED,SUCCESS,,[öffentliche ipv4 OpenVPn Server],1194,,
Code:
VpnClientPro-google-api27-release-1.01.92 (30010192)
Connecting request by user
OpenVPN 2.5.8 android-arm64-v8a [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct 12 2024
library versions: OpenSSL 3.0.15 3 Sep 2024, LZO 2.10
Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
TCP/UDP: Preserving recently used remote address: [AF_INET][öffentliche IPV4 openVPN Server]:1194
Socket Buffers: R=[229376->229376] S=[229376->229376]
UDPv4 link local: (not bound)
UDPv4 link remote: [AF_INET][öffentliche IPV4 openVPN Server]:1194
TLS: Initial packet from [AF_INET][öffentliche IPV4 openVPN Server]:1194, sid=8f6a75d5 10c3db2a
VERIFY OK: depth=1, CN=Hahns Fritzbox unten
VERIFY OK: nsCertType=SERVER
VERIFY OK: depth=0, CN=fritzbox_unten
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'
Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, peer certificate: 2048 bit RSA, signature: RSA-SHA256
[fritzbox_unten] Peer Connection Initiated with [AF_INET][öffentliche IPV4 openVPN Server]:1194
PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.188.1,route 192.168.188.0 255.255.254.0,route 192.168.188.1,peer-id 0,cipher AES-256-GCM'
OPTIONS IMPORT: route options modified
OPTIONS IMPORT: route-related options modified
OPTIONS IMPORT: peer-id set
OPTIONS IMPORT: adjusting link_mtu to 1656
OPTIONS IMPORT: data channel crypto options modified
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
WARNING: OpenVPN was configured to add an IPv4 route. However, no IPv4 has been configured for (null), therefore the route installation may fail or may not work as expected.
DHCP client started
TUN/TAP device opened
Initialization Sequence Completed
set DHCP server "192.168.188.1"
set lease time "864000"
add address "192.168.188.249/23"
add route "0.0.0.0/1 via 192.168.188.1"
add route "128.0.0.0/1 via 192.168.188.1"
add dns "192.168.188.1"
add search domain "fritz.box"
DHCP client completed
TapEmulator startedWie ich oben im Spoiler bereits geschrieben habe, funktioniert die ganze Verbindung (mit Anpassung des Default Gateways) unter Windows und Android einwandfrei. Unter Debian hingegen kann ich keine VPN-Verbindung aufbauen, da anscheinend die Route (damit der Verkehr an 192.168.188.0/23 übers VPN geleitet wird) nicht hinzugefügt werden kann, weil das System plötzlich keine Netzwerkverbindung mehr hat (Network is unreachable) bzw. 192.168.188.1, über die die Route gehen soll, nicht erreichbar ist.
Ich habe das sowohl mit meinem Raspberry Pi mit Pi OS, der in Netzwerk A steht, als auch mit einem Debian-Server, der in Netzwerk B steht (zum Zeitpunkt des Versuchs war ich selbst in Netzwerk A), probiert. Beide haben denselben Fehler, obwohl 192.168.188.0/23 für den Pi erreichbar sein muss, da er physisch per LAN mit diesem Netzwerk verbunden ist.
Ich habe auch schon überlegt demm tap0 Interface manuell eine IP Adresse festzulegen (wie bei Windows) aber dass tap0 Interface existiert anscheinend nur, wenn OpenVPN läuft.
Code:
Note: dev-type not tun, disabling data channel offload.
WARNING: file '/home/Justin/keys/justins_pc.key' is group or others accessible
WARNING: file '/home/Justin/keys/openvpnstatic.key' is group or others accessible
OpenVPN 2.6.3 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
library versions: OpenSSL 3.0.14 4 Jun 2024, LZO 2.10
DCO version: N/A
Enter Private Key Password: ************
WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
TCP/UDP: Preserving recently used remote address: [AF_INET][öffentliche ipv4 OpenVPn Server]:1194
Socket Buffers: R=[212992->212992] S=[212992->212992]
UDPv4 link local: (not bound)
UDPv4 link remote: [AF_INET][öffentliche ipv4 OpenVPn Server]:1194
TLS: Initial packet from [AF_INET][öffentliche ipv4 OpenVPn Server]:1194, sid=6206bba4 8f747933
VERIFY OK: depth=1, CN=Hahns Fritzbox unten
VERIFY KU OK
Validating certificate extended key usage
++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
VERIFY EKU OK
VERIFY OK: depth=0, CN=fritzbox_unten
Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, peer certificate: 2048 bit RSA, signature: RSA-SHA256
[fritzbox_unten] Peer Connection Initiated with [AF_INET][öffentliche ipv4 OpenVPn Server]:1194
TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
TLS: tls_multi_process: initial untrusted session promoted to trusted
PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.188.1,route 192.168.188.0 255.255.254.0,route 192.168.188.1,ping 10,ping-restart 20,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500'
OPTIONS IMPORT: route options modified
OPTIONS IMPORT: route-related options modified
OPTIONS IMPORT: tun-mtu set to 1500
net_route_v4_best_gw query: dst 0.0.0.0
net_route_v4_best_gw result: via 192.168.100.145 dev wlan0
ROUTE_GATEWAY 192.168.100.145/255.255.255.0 IFACE=wlan0 HWADDR=2c:cf:67:1c:b6:f1
TUN/TAP device tap0 opened
WARNING: OpenVPN was configured to add an IPv4 route. However, no IPv4 has been configured for tap0, therefore the route installation may fail or may not work as expected.
net_route_v4_add: 192.168.188.0/23 via 192.168.188.1 dev [NULL] table 0 metric -1
sitnl_send: rtnl: generic error (-101): Network is unreachable
ERROR: Linux route add command failed
net_route_v4_add: 192.168.188.1/32 via 192.168.188.1 dev [NULL] table 0 metric -1
sitnl_send: rtnl: generic error (-101): Network is unreachable
ERROR: Linux route add command failed
Initialization Sequence Completed
Data Channel: cipher 'AES-256-GCM', peer-id: 0
Timers: ping 10, ping-restart 20
Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt#
// 19 Sekunden später
[fritzbox_unten] Inactivity timeout (--ping-restart), restarting
Closing TUN/TAP interface
SIGUSR1[soft,ping-restart] received, process restarting
Restart pause, 1 second(s)6+3Ich bedanke mich schonmal im Vorauß für eure Hilfe.
Ergänzung:
Ich habe jetzt den Pi nochmal aus dem Netzwerk A gelöscht und den Router so gezwungen, ihm eine neue IP-Adresse zu geben. Jetzt funktioniert es innerhalb des Netzwerks. Das macht zwar eigentlich keinen Sinn, weil der Pi vorher über seine vorher vergebene IP auch erreichbar war, aber zumindest besteht das Problem jetzt nur noch aus allen externen Netzwerken.
Ergänzung #2 31.10.2024 20:45
Ich denke ich habe einige neue Wissenswerte Infos.
Dass Tap0 Interface was von OpenVPN erstellt wird ist erstmal down.
Code:
46: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 36:91:16:cc:20:3b brd ff:ff:ff:ff:ff:ffWenn ich dann aber dhclient tap0 ausführe (dauert teilweise fast 20 Sekunden) bekommt dass Interface plötzlich eine IP zugewießen und es werden 2 neue IP Routen erstellt die auf Netztwerk A führen:
Code:
44: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether 36:91:16:cc:20:3b brd ff:ff:ff:ff:ff:ff
inet 192.168.188.251/23 brd 192.168.189.255 scope global dynamic tap0
valid_lft 863995sec preferred_lft 863995sec
inet6 fe80::3491:16ff:fecc:203b/64 scope link
valid_lft forever preferred_lft forever
Code:
default via 192.168.188.1 dev tap0
default via 10.0.0.1 dev enp0s6 proto dhcp src 10.0.0.190 metric 100
10.0.0.0/24 dev enp0s6 proto kernel scope link src 10.0.0.190 metric 100
169.254.0.0/16 dev enp0s6 proto dhcp scope link src 10.0.0.190 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.19.0.0/16 dev br-b7df6763798b proto kernel scope link src 172.19.0.1
172.20.0.0/16 dev br-57193fb660f3 proto kernel scope link src 172.20.0.1
172.26.0.0/16 dev br-1dcc58df9ccf proto kernel scope link src 172.26.0.1
172.30.32.0/23 dev hassio proto kernel scope link src 172.30.32.1
192.168.188.0/23 dev tap0 proto kernel scope link src 192.168.188.251Wenn ich jetzt nocheinmal versuche die 192.168.188.1 (private IPV4 Adresse des VPN Servers ) anzupingen erhalte ich ein von der 192.168.188.251(die IP Adresse des tap Interfaces) Destination Host Unreachable zurück(wenn ich die Adresse ohne VPN anpinge bekomme ich gar nichts zurück).
Prinzipiel scheint aber Vekehr übers VPN zu laufen, dass tap0 bekommt seine IP Adresse über den DHCP Server von Netzterk A (192.168.188.1) aber dann macht es keinen Sinn warum ich den DHCP Servr nicht anpingen kann.
Zuletzt bearbeitet: