22.06.2021, aktualisiert um 22:27:21 Uhr

3683

OpenVPN Server mit IPv4 und IPv6 - IPv4 keine Verbindung

Hallo zusammen,

ich versuche gerade einen OpenVPN Server mit einer public IPv4 und einer global scope IPv6, nach einer Anleitung zu installieren.
Hier der Link:
https://community.hetzner.com/tutorials/install-and-configure-openvpn-on ...

Habe mir dafür extra einen VPS Server bei Hetzner gemietet, da colinardo, in diesem Thread OpenWRT mit Wireguard IPv6 im LAN erwähnt hat, dass Hoster zum Teil die IPv6 Subnetze nicht richtig routen, sondern nur, die IPs die auch dem Server zugeordnet sind.

Ich habe also alles exakt wie in der Anleitung gemacht und dann auf der Seite https://ipv6-test.com/ geschaut, was rauskommt.
Leider geht nur IPv6.
Bei IPv6 sehe ich auch die zugeordnete IPv6 vom Server. Funktioniert, wie es soll.

Kann ich dann auch an Webseiten testen die only IPv4 sind.
Die gehen dann nicht. Auch Ping auf IPv4 geht nicht.

Ich habe wie gesagt, das Tutorial exakt befolgt.
Einträge in sysctl.conf und Firewall, wie im Tutorial.
Das ganze schon einmal wiederholt und davor den Server zurückgesetzt.
Server ist Debian 9.
Der Eintrag tun-ipv6 ist wohl veraltet aber ich hab mal nichts verändert.

Hier die Configs:

Server:

port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
auth SHA512
tls-auth /etc/openvpn/ta.key 0

topology subnet

server 10.8.0.0 255.255.255.0
local XY.XYY.YYY.YYY
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "redirect-gateway def1 bypass-dhcp"  
push "dhcp-option DNS 1.1.1.1"  
push "dhcp-option DNS 1.0.0.1"  

server-ipv6 XXXX:XXX:XXXX:1ff9:80::/112
tun-ipv6
push tun-ipv6
ifconfig-ipv6 XXXX:XXX:XXXX:1ff9::1 XXXX:XXX:XXXX:1ff9::2
push "route-ipv6 XXXX:XXX:XXXX:1ff9:2::/64"  
push "route-ipv6 2000::/3"  
push "dhcp-option DNS 2606:4700:4700::1111"  
push "dhcp-option DNS 2606:4700:4700::1001"  

keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
client-to-client
status /etc/openvpn/openvpn-status.log
verb 3
crl-verify /etc/openvpn/crl.pem

und der Client:

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
tun-mtu 1500
mssfix 1420
remote XY.XYY.YYY.YYY 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
auth-nocache
cipher AES-256-CBC
setenv opt block-outside-dns
key-direction 1
verb 3
<ca>
-----BEGIN CERTIFICATE-----
DATEN ENTFERNT
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
DATEN ENTFERNT
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
DATEN ENTFERNT
-----END PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
DATEN ENTFERNT
-----END OpenVPN Static key V1-----
</tls-auth>

Hier route -6 -n

root@vpn:~# route -6 -n
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
XXXX:XXX:XXXX:1ff9:80::/112    ::                         U    256 1   895 tun0
XXXX:XXX:XXXX:1ff9::/64        ::                         U    256 0     0 eth0
fe80::/64                      ::                         U    256 0     0 eth0
fe80::/64                      ::                         U    256 0     0 tun0
::/0                           fe80::1                    UG   1024 1   608 eth0
::/0                           ::                         !n   -1  1  1504 lo
::1/128                        ::                         Un   0   2     5 lo
XXXX:XXX:XXXX:1ff9::/128       ::                         Un   0   1     0 lo
XXXX:XXX:XXXX:1ff9::1/128      ::                         Un   0   1     0 lo
XXXX:XXX:XXXX:1ff9:80::/128    ::                         Un   0   1     0 lo
XXXX:XXX:XXXX:1ff9:80::1/128   ::                         Un   0   2     6 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::9400:ff:fec0:c3c8/128    ::                         Un   0   2     9 lo
fe80::c68a:504d:22ff:170f/128  ::                         Un   0   1     0 lo
ff00::/8                       ::                         U    256 0     0 eth0
ff00::/8                       ::                         U    256 1     1 tun0
::/0                           ::                         !n   -1  1  1504 lo

und route -n

root@vpn:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.1.1      0.0.0.0         UG    0      0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.31.1.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0

Was mir auffällt, ist dass die public IPv4 keine route Eintrag hat.

Grüße
FISI

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 771712423

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

Ausgedruckt am: 21.11.2024 um 16:11 Uhr

7 Kommentare

Neuester Kommentar

Den OpenVPN Merkzettel hast du Schritt für Schritt abgearbeitet ?
Merkzettel: VPN Installation mit OpenVPN
Du solltest die Protokolldefinitionen auch dediziert mit "udp4" bezeichnen bei Dual Stack.
Überflüssige Kommandos wie deine "sndbuf / rcvbuf" solltest du entfernen bzw. auf dem Default belassen. Gilt auch für den Client mit seinen tunnel mtu und mss Werten die sind eh die Default Werte und kannst du deshalb auch weglassen.
Hilfreich wie immer in solchen Fällen ist das Server und Client Log beim Aufbau der v4 Verbindung.
Hast du zudem auch beachtet das du NAT/Masquerading (IP Adress Translation) am Server machen musst denn dein internes VPN Client IP Netz ist ein RFC 1918 privates IP Netz was im Internet nicht geroutet wird. -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Zum NAT machst du leider keinerlei Angaben.

Hallo aqui,

Zitat von @aqui:
Hast du zudem auch beachtet das du NAT/Masquerading (IP Adress Translation) am Server machen musst denn dein internes VPN Client IP Netz ist ein RFC 1918 privates IP Netz was im Internet nicht geroutet wird. -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Zum NAT machst du leider keinerlei Angaben.

Doch mache ich. Sogar FETT -> Einträge in sysctl.conf und Firewall, wie im Tutorial.

iptables -t nat -A POSTROUTING -o eth0 -s 10.8.0.0/24 -j MASQUERADE
#Note: If you use tcp protocol you must change -p udp to -p tcp and --ddport 1194 to --ddport 443
iptables -A INPUT -i eth0 -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

#Note: If you use tcp protocol you must change -p udp to -p tcp and --ddport 1194 to --ddport 443
ip6tables -A INPUT -i eth0 -p udp --dport 1194 -j ACCEPT
ip6tables -A INPUT -i tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o eth0 -s 2a01:4f8:c2c:5fc7:80::/112 -m state --state NEW -j ACCEPT

Die IPv6 Adresse ist, wie man sehen kann eine Hetzner global scope IPv6, weil es eine Anleitung bei Hetzner ist. Die IPs habe ich natürlich angepasst und gefühlt hundert mal korrigiert.
Habe den Server auch zurückgesetzt, Pause gemacht und neu aufgesetzt, da ich nicht weiß, mit welchen Parametern/Befehlen auf dem dem Debian Server, die Fehler ersichtlich werden.

Wenn ihr mir sagen könnt, was ich posten soll, dann mache ich das natürlich.

iptables-save > /etc/iptables.rules
ip6tables-save > /etc/ip6tables.rules

Ich mache den Aufbau der Verbindung mit proto udp, weil ich ja schon wie bei Wireguard ein Tunnel mit IPv4 und IPv6 möchte.
Nur IPv4 oder Ipv4 und Ipv6 mit "lokalen" IPv6 Adressen ist ja insofern kein Problem, weil es dafür schon fertige und funktionierende Anleitungen gibt.

Gerade bei Wireguard ist es wohl übliche auch die IPv6 auf eine global scope IPv6 vom Server zu NATen, wenn ich das richtig verstehe. Die Anleitungen wo einfach die local scope mit einer global scope ersetzt wird, funktioniert halt nicht so.

Ich versuche aber ein System aufzubauen, wo die globalen IPv6 funktionieren und dafür habe ich bis jetzt noch keine funktionierende Anleitung für Wireguard oder OpenVPN.

Es ist leider auch nicht so, dass man einfach, z.B. bei Wireguard, eine IPv6 dazuschreibt.

Siehe den verlinkten letzten Thread zu Wireguard. Es funktioniert halt nicht so einfach, wie du zum Teil hinschreibst.

Zum NAT machst du leider keinerlei Angaben.

Doch mache ich, ich schreibe doch dass ich die Anleitung von Hetzner 1 zu 1 übernommen habe und dass IPv6 mit global scope Adresse super funktioniert aber eben IPv4 nicht.

Ich mache das auch nicht weil ich es produktiv benötige, sondern weil ich das lernen will.
Für ein produktiv System würde ich ein bewährtes und funktionierendes Wireguard Setting nehmen, wo IPv4 und IPv6 localscope mit NAT funktioniert.

Hier das Verbindungs Log mit funktionierendem IPv6 und nicht funktionierendem IPv4.
Die public IPv4 und global scope IPv6 sind "ausgeXt"

2021-06-23 08:29:50 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.  
2021-06-23 08:29:50 OpenVPN 2.5.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 21 2021
2021-06-23 08:29:50 Windows version 10.0 (Windows 10 or greater) 64bit
2021-06-23 08:29:50 library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10
Enter Management Password:
2021-06-23 08:29:50 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25342
2021-06-23 08:29:50 Need hold release from management interface, waiting...
2021-06-23 08:29:50 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25342
2021-06-23 08:29:51 MANAGEMENT: CMD 'state on'  
2021-06-23 08:29:51 MANAGEMENT: CMD 'log all on'  
2021-06-23 08:29:51 MANAGEMENT: CMD 'echo all on'  
2021-06-23 08:29:51 MANAGEMENT: CMD 'bytecount 5'  
2021-06-23 08:29:51 MANAGEMENT: CMD 'hold off'  
2021-06-23 08:29:51 MANAGEMENT: CMD 'hold release'  
2021-06-23 08:29:51 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication  
2021-06-23 08:29:51 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication  
2021-06-23 08:29:51 TCP/UDP: Preserving recently used remote address: [AF_INET]XX.XXX.XXX.178:1194
2021-06-23 08:29:51 Socket Buffers: R=[65536->65536] S=[65536->65536]
2021-06-23 08:29:51 UDP link local: (not bound)
2021-06-23 08:29:51 UDP link remote: [AF_INET]XX.XXX.XXX.178:1194
2021-06-23 08:29:51 MANAGEMENT: >STATE:1624429791,WAIT,,,,,,
2021-06-23 08:29:51 MANAGEMENT: >STATE:1624429791,AUTH,,,,,,
2021-06-23 08:29:51 TLS: Initial packet from [AF_INET]XX.XXX.XXX.178:1194, sid=be1084f0 cd01963e
2021-06-23 08:29:51 VERIFY OK: depth=1, CN=ChangeMe
2021-06-23 08:29:51 VERIFY KU OK
2021-06-23 08:29:51 Validating certificate extended key usage
2021-06-23 08:29:51 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2021-06-23 08:29:51 VERIFY EKU OK
2021-06-23 08:29:51 VERIFY OK: depth=0, CN=server
2021-06-23 08:29:51 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2021-06-23 08:29:51 [server] Peer Connection Initiated with [AF_INET]XX.XXX.XXX.178:1194
2021-06-23 08:29:52 MANAGEMENT: >STATE:1624429792,GET_CONFIG,,,,,,
2021-06-23 08:29:52 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)  
2021-06-23 08:29:52 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,tun-ipv6,route-ipv6 XXXX:XXX:XXXX:1ff9:2::/64,route-ipv6 2000::/3,dhcp-option DNS 2606:4700:4700::1111,dhcp-option DNS 2606:4700:4700::1001,tun-ipv6,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 XXXX:XXX:XXXX:1ff9:80::1000/112 XXXX:XXX:XXXX:1ff9:80::1,ifconfig 10.8.0.2 255.255.255.0,peer-id 1,cipher AES-256-GCM'  
2021-06-23 08:29:52 OPTIONS IMPORT: timers and/or timeouts modified
2021-06-23 08:29:52 OPTIONS IMPORT: --ifconfig/up options modified
2021-06-23 08:29:52 OPTIONS IMPORT: route options modified
2021-06-23 08:29:52 OPTIONS IMPORT: route-related options modified
2021-06-23 08:29:52 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2021-06-23 08:29:52 OPTIONS IMPORT: peer-id set
2021-06-23 08:29:52 OPTIONS IMPORT: adjusting link_mtu to 1624
2021-06-23 08:29:52 OPTIONS IMPORT: data channel crypto options modified
2021-06-23 08:29:52 Data Channel: using negotiated cipher 'AES-256-GCM'  
2021-06-23 08:29:52 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
2021-06-23 08:29:52 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key  
2021-06-23 08:29:52 interactive service msg_channel=556
2021-06-23 08:29:52 ROUTE_GATEWAY 10.1.0.1/255.255.0.0 I=8 HWADDR=c8:5b:76:74:49:79
2021-06-23 08:29:52 GDG6: remote_host_ipv6=n/a
2021-06-23 08:29:52 NOTE: GetBestInterfaceEx returned error: Element nicht gefunden.   (code=1168)
2021-06-23 08:29:52 ROUTE6: default_gateway=UNDEF
2021-06-23 08:29:52 open_tun
2021-06-23 08:29:52 tap-windows6 device [LAN-Verbindung 2] opened
2021-06-23 08:29:52 TAP-Windows Driver Version 9.24 
2021-06-23 08:29:52 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.2/255.255.255.0 [SUCCEEDED]
2021-06-23 08:29:52 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.2/255.255.255.0 on interface {3394A824-BD74-4C3B-8E14-E7A6DD9D2BF1} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
2021-06-23 08:29:52 Successful ARP Flush on interface [15] {3394A824-BD74-4C3B-8E14-E7A6DD9D2BF1}
2021-06-23 08:29:52 MANAGEMENT: >STATE:1624429792,ASSIGN_IP,,10.8.0.2,,,,,XXXX:XXX:XXXX:1ff9:80::1000
2021-06-23 08:29:52 IPv4 MTU set to 1500 on interface 15 using service
2021-06-23 08:29:52 INET6 address service: add XXXX:XXX:XXXX:1ff9:80::1000/128
2021-06-23 08:29:52 add_route_ipv6(XXXX:XXX:XXXX:1ff9:80::/112 -> XXXX:XXX:XXXX:1ff9:80::1000 metric 0) dev LAN-Verbindung 2
2021-06-23 08:29:52 IPv6 route addition via service succeeded
2021-06-23 08:29:53 IPv6 dns servers set using service
2021-06-23 08:29:53 IPv6 MTU set to 1500 on interface 15 using service
2021-06-23 08:29:53 Blocking outside dns using service succeeded.
2021-06-23 08:29:58 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
2021-06-23 08:29:58 C:\WINDOWS\system32\route.exe ADD XX.XXX.XXX.178 MASK 255.255.255.255 10.1.0.1
2021-06-23 08:29:58 Route addition via service succeeded
2021-06-23 08:29:58 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.8.0.1
2021-06-23 08:29:58 Route addition via service succeeded
2021-06-23 08:29:58 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.8.0.1
2021-06-23 08:29:58 Route addition via service succeeded
2021-06-23 08:29:58 add_route_ipv6(XXXX:XXX:XXXX:1ff9::/64 -> XXXX:XXX:XXXX:1ff9:80::1 metric -1) dev LAN-Verbindung 2
2021-06-23 08:29:58 IPv6 route addition via service succeeded
2021-06-23 08:29:58 add_route_ipv6(2000::/3 -> XXXX:XXX:XXXX:1ff9:80::1 metric -1) dev LAN-Verbindung 2
2021-06-23 08:29:58 IPv6 route addition via service succeeded
2021-06-23 08:29:58 Initialization Sequence Completed
2021-06-23 08:29:58 MANAGEMENT: >STATE:1624429798,CONNECTED,SUCCESS,10.8.0.2,XX.XXX.XXX.178,1194,,,XXXX:XXX:XXXX:1ff9:80::1000

Hier die Daten aus Windows 10 mit der OpenVPN Verbindung:
Ich bekomme eine IPv6 mit der alles wunderbar funktioniert.
IPv4 10.8.0.2 aus dem 10.8.0.0 Netz. Ping auf Server IPv4 10.8.0.1 funktioniert.

C:\Users\user>ipconfig
Windows-IP-Konfiguration
Unbekannter Adapter LAN-Verbindung 2:
   Verbindungsspezifisches DNS-Suffix:
   IPv6-Adresse. . . . . . . . . . . : XXXX:XXX:XXXX:1ff9:80::1000    <- global scope IPv6
   Verbindungslokale IPv6-Adresse  . : fe80::b416:1d02:e772:eeb3%15
   IPv4-Adresse  . . . . . . . . . . : 10.8.0.2
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . :

Ping IPv4 OpenVPN IP

C:\Users\user>ping 10.8.0.1
Ping wird ausgeführt für 10.8.0.1 mit 32 Bytes Daten:
Antwort von 10.8.0.1: Bytes=32 Zeit=60ms TTL=64
Antwort von 10.8.0.1: Bytes=32 Zeit=55ms TTL=64

Ping auf public IPv4 von OpenVPN Server funktioniet auch:

C:\Users\user>ping XX.XXX.XXX.178

Ping wird ausgeführt für XX.XXX.XXX.178 mit 32 Bytes Daten:
Antwort von XX.XXX.XXX.178: Bytes=32 Zeit=61ms TTL=46

Ping-Statistik für XX.XXX.XXX.178:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 53ms, Maximum = 61ms, Mittelwert = 55ms

Ping auf Google geht mit IPv6 aber nicht mit IPv4. Auch nicht wenn ich auf IP 8.8.8.8 pinge um DNS Probleme auszuschliessen.

C:\Users\user>ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 8.8.8.8: Bytes=32 Zeit=29ms TTL=110

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 1, Verloren = 3
    (75% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 29ms, Maximum = 29ms, Mittelwert = 29ms

Deshalb vermute ich, als Laie, dass die IPv4 Route auf dem OpenVPN Server fehlt, wie ich oben ja schon geschrieben habe.
Wenn ich einen funktionierenden OpenVPN Server mit IPv4 vergleiche, dann hat der funktionierende eine IPv4 Route mit public IP drin, die dieser nach der Hetzner Anleitung nicht hat.

route -n (IPv4) auf dem Hetzner Server. Hier sehe ich keine Route der public IPv4:

root@vpn:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.1.1      0.0.0.0         UG    0      0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.31.1.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0

Woher die 172.31.1.1 kommt kann ich auch nicht erkennen.

Allerdings ist das route -n ohne OpenVPN auch nicht anderst.

root@vpn:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.31.1.1      0.0.0.0         UG    0      0        0 eth0
172.31.1.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
root@vpn:~#

Hoffe mal nicht, dass das so ein Konstrukt ist, wie colinardo das in dem Wireguard Post von Netcup beschrieben hat.

Grüße
FISI

Deshalb vermute ich, als Laie, dass die IPv4 Route auf dem OpenVPN Server fehlt,

Das wäre ja Unsinn. Du kannst ja oben eine öffentliche IPv4 Adresse vom Server aus pingen ! Würde deine Default Route fehlen oder falsch sein dann wäre das gar ja nicht möglich. Das ist also OK bzw. ein ip route show sollte dir das auch zeigen.

Anhand deiner Outputs oben kann man ja auch sehen das der VPN Tunnel fehlerfrei zustande kommt sowohl für IPv4 als auch IPv6. OpenVPN selber ist damit auch raus als Fehlerquelle.
Vermutung ist das irgend etwas mit dem Masquerading/NAT nicht klappt, sprich das der VPN Client Traffic nicht v4 geNATet wird.
Verdächtig ist die RFC 1918 IP Adresse 172.31.1.1 auf dem Ethernet 1 Interface. Das lässt befürchten das Hetzner ggf. selber intern RFC 1918 IP Adressen nutzt und diese nochmal global NATet.
Hier wäre mal ein ip address show vom Server hilfreich. Auch ein route print von deinem OpenVPN Windows 10 Client wäre hilfreich bei aktivem Tunnel.

Die 172.31er RFC 1918 Adresse ist auf alle Fälle eine Adresse die da normal NICHT hingehört bzw. irgendwie ein Indiz ist das der Provider da intern nicht mit öffentlichen IPs arbeitet. Das solltest du nochmals genauer ansehen.
Ggf. auch mit tcpdump dir mal den VPN Traffic ansehen.

so ein Konstrukt ist, wie colinardo das in dem Wireguard Post von Netcup beschrieben hat.

Zumindestens für IPv4 kann es das ja nicht sein, denn der NAT/Masquerading Prozess im Server setzt ja alles um auf die (eigentlich) öffentliche IP Adresse des VPN Servers. Aus dem Internet sieht es also so aus als ob aller Traffic der VPN Netze dahinter nur von dieser Adresse gesendet wird. Klassisches und simples Prinzip wie es an jedem Heimnetz mit xDSL NAT Router der Fall ist.
Verdächtig ist hier das die Server Adresse eine RFC 1918 IP ist die im Internet NICHT geroutet wird. Das lässt wieder irgendein NAT "Konstrukt" beim Hoster befürchten weil der keine IPv4 Adressen mehr hat.
https://www.heise.de/newsticker/meldung/Das-war-s-mit-IPv4-Adressen-in-E ...

Hallo aqui,

danke dir für deine Info.

Die 172.31er RFC 1918 Adresse ist auf alle Fälle eine Adresse die da normal NICHT hingehört bzw. irgendwie ein Indiz ist das der Provider da intern nicht mit öffentlichen IPs arbeitet.

Dachte mir dass da was nicht stimmt.

Wenn ich dann das ganze auf nem Netcup VPS probiere, dann kommt die Geschichte die colinardo erwähnt hat, dass IPv6 bei denen nicht so einfach geroutet wird.

Bei Netcup habe ich IPv6 dazu gemietet und teste die nächsten Tage mal damit.

Hier das ip addr show vom Server:

root@vpn:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 96:00:00:c0:c3:c8 brd ff:ff:ff:ff:ff:ff
    inet 9X.XXX.XXX.178/32 brd 9X.XXX.XXX.178 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2XXX:XXX:XXXX:1ff9::1/64 scope global deprecated
       valid_lft forever preferred_lft 0sec
    inet6 fe80::9400:ff:fec0:c3c8/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 2XXX:XXX:XXXX:1ff9:80::1/112 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::eaa0:6160:cb43:f793/64 scope link flags 800
       valid_lft forever preferred_lft forever

Ich verstehe auch nicht warum die IPv6 (global scope) mit deprecated bezeichnet wird. Aber das nur am Rande.

inet6 2XXX:XXX:XXXX:1ff9::1/64 scope global deprecated

Das ist die IPv6 die statisch unter /etc/network/interfaces.d/50-cloud-init.cfg zugeordnet ist.

Interessant ist, dass dort die IPv4, die mit ip addr show angezeigt wird nicht hinterlegt ist:

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file 
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
    dns-nameservers 213.133.99.99 213.133.100.100 213.133.98.98
    post-up ifup eth0:1


auto eth0:1
iface eth0:1 inet6 static
    address 2XXX:XXX:XXXX:1ff9::1/64
    gateway fe80::1

Hier ein route print vom Windows 10 Client. Ist ein bisschen gekürzt:

Microsoft Windows [Version 10.0.19043.1052]
(c) Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\P50>route PRINT
===========================================================================
Schnittstellenliste
 15...00 ff 33 94 a8 24 ......TAP-Windows Adapter V9
 14...........................Wintun Userspace Tunnel
  8...c8 5b 76 74 49 79 ......Intel(R) Ethernet Connection (2) I219-LM
 24...00 ff 90 e5 0c 84 ......TAP-Windows Adapter V9 for OpenVPN Connect
  1...........................Software Loopback Interface 1
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0         10.1.0.1       10.1.0.107     25
          0.0.0.0        128.0.0.0         10.8.0.1         10.8.0.2    259
         10.8.0.0    255.255.255.0   Auf Verbindung          10.8.0.2    259
         10.8.0.2  255.255.255.255   Auf Verbindung          10.8.0.2    259
       10.8.0.255  255.255.255.255   Auf Verbindung          10.8.0.2    259
   9X.XXX.XXX.178  255.255.255.255         10.1.0.1       10.1.0.107    281  <- IPv4 ist Server IP
        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.2    259
        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.2    259
  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.2    259
===========================================================================
Ständige Routen:
  Keine

IPv6-Routentabelle
===========================================================================
Aktive Routen:
 If Metrik Netzwerkziel             Gateway
  1    331 ::1/128                  Auf Verbindung
 15    259 2000::/3                 fe80::8
 15    259 2XXX:XXX:XXXX:1ff9::/64  fe80::8
 15      3 2XXX:XXX:XXXX:1ff9:80::/112
                                    fe80::8
 15    259 2XXX:XXX:XXXX:1ff9:80::1000/128
                                    Auf Verbindung
  8    281 fd00::/64                Auf Verbindung
  8    281 fd00::/64                fe80::c225:6ff:fefa:8875

  8    281 fd00::d987:9605:b540:3ab9/128

  8    281 fe80::/64                Auf Verbindung

  8    281 fe80::d987:9605:b540:3ab9/128

  8    281 ff00::/8                 Auf Verbindung
===========================================================================
Ständige Routen:
  Keine

Für mich läuft das ähnlich wie mit der Wireguard IPv6 Geschichte bei Netcup.
Da wollte ich eigentlich die Übungen aus dem Buch machen und dafür lediglich auf einem PC/Laptop eine IPv4 und eine global scope IPv6 und Tage später habe ich einen zusätzlichen VPS bei Hetzner und bin immer noch am frickeln.

Grüße
FISI

Die Hostadresse inet 9X.XXX.XXX.178/32 ist ja eine öffentliche. Irritierend ist aber die Subnetzmaske mit 32 Bit. Das ist zwar nicht falsch zeigt aber das die irgendwie mit Hostrouting o.ä. arbeiten. Da kann man jetzt nur im freien Fall spekulieren wie deren Netzwerk dahinter aussieht. Das wirst du vermutlich ohne einen Anruf der Hotline nicht klären können. Das Problem liegt aber auf alle Fälle hier.
Das zeigt auch dein Client Routing Output der nur das Servernetz als Hostroute propagiert. Eigentlich sollte er das gar nicht, da du kein Push Kommando dafür gesetzt hast.
Was noch auffällt ist das die Metrik deiner Default Route über den OVPN Tunnel schlechter ist als deine lokale über das lokale LAN. Der Windows Client wird also primär immer das lokale Default Gateway verwenden anstatt der OVPN Tunneladresse. Das must du ggf. auch noch anpassen. Ein Traceroute (tracert bei Winblows) sollte dir das anhand der Routing Hops sofort zeigen.

Interessant ist, dass dort die IPv4, die mit ip addr show angezeigt wird nicht hinterlegt ist:

Das ist auch klar und du siehst sicher selber warum ! Die v4 IP des Servers kommt per DHCP dort und die v6 liegt auf einem Subinterface.

Ich verstehe auch nicht warum die IPv6 (global scope) mit deprecated bezeichnet wird.

Das kommt sehr wahrscheinlich dadurch das deine v6 Adresse mit Privacy Extensions rennt:
https://wiki.ubuntuusers.de/IPv6/Privacy_Extensions/
https://www.elektronik-kompendium.de/sites/net/1601271.htm
Dadurch verändert sie sich dynamisch um keine Rückschlüsse auf den User zuzulassen. Ist aber irgendwie komisch, denn sie ist statisch zugewiesen was das eigentlich verhindert. Ggf. solltest du die PEs mal deaktivieren im Server um zu sehen ob das dann verschwindet.

Hallo aqui,

danke für die Infos.

Ich werde wohl wieder zum Buch zurückkehren und den Wireguard mit IPv4 und IPv6 über NAT nehmen, bzw. wenn ich eine global scope Adresse benötige den Hetzner OpenVPN, dann nur für die IPv6 Übung.

Dadurch verändert sie sich dynamisch um keine Rückschlüsse auf den User zuzulassen. Ist aber irgendwie komisch, denn sie ist statisch zugewiesen was das eigentlich verhindert. Ggf. solltest du die PEs mal deaktivieren im Server um zu sehen ob das dann verschwindet.

Wenn du hier sagst, dass das komisch ist, dann ist es für komisch hoch 64 und somit ausserhalb meiner Vorstellungskraft.

Ich verstehe von der Materie vieles nur rudimentär und muss aufpassen, dass ich nicht den Faden verliere.

Aber bei diesem und dem IPv6 Wireguard Thema haben du und colinardo mir sehr geholfen.
Danke dafür.

Das Problem war, dass ich nicht erkennen konnte, wo ich nach einer Lösung suchen muss.
Wenn nun klar ist, dass das bei den 2 Euro 80 Cent VPS Servern liegt, ist mir schon sehr geholfen.
Die werden so billig wie möglich, dem Kunden zur Verfügung gestellt und somit funktioniert das Routing nicht wie in einem Tutorial dargestellt.

Ich habe jetzt ja auch noch die Möglichkeit, mit einer zugekauften IPv6 Adresse bei Netcup weiter zu testen.
Wenns Probleme gibt, rufe ich im administrator.de wieder um Hilfe.

Grüße
FISI

dann ist es für komisch hoch 64 und somit ausserhalb meiner Vorstellungskraft.

Deiner vielleicht aber nicht die eines Netzwerkers.

Aber man müsste dazu das Provider Setup kennen. Hier kann man nur im freien Fall raten was wenig zielführend ist.
Ruf die Hotline an und beschwere die das dein NAT auf die per DHCP zugewiesene /32 Server Adresse nicht klappt und was der Grund ist. Die Antwort dürfte spannend für alle Beteiligten sein...

Es dürften aber in der Tat das Setup der VPS Server sein. Das stehen die Einschränkungen sicher im Kleingedruckten.

rufe ich im administrator.de wieder um Hilfe.

Immer gerne !

Wie kann ich einen Beitrag als gelöst markieren?

gelöst Frage Netzwerke

Mehr von FISI-Lehrling

IPv6 only in Unifi UDM Pro oder Cloud Gateway UltraFISI-Lehrling - 46 Kommentare

Wireguard Server hinter SSH TunnelFISI-Lehrling - 4 Kommentare

OpenVPN Client mit zwei SubnetzenFISI-Lehrling - 6 Kommentare

CRS109-8G-1S-2HnD als PTP Bridge AP mit WLAN AuthentifizierungFISI-Lehrling - 3 Kommentare

Heiß diskutiert