staging.inyokaproject.org

Hallo zusammen, ich habe meinen Openvpn_Server (mit pivpn) auf Dual-Stack umgestellt, um ipv6 leaks zu vermeiden. Getunnelt wird durch einen ipv4-Tunnel. Mit dem Handy klappts und mit Windoof auch, nur mit meinem Ubunturechner habe ich Probleme. Die Verbindung lässt sich mitlerweile aufbauen. Leider habe ich ein ipv6 Leak. Über Ideen wäre ich sehr dankbar.

CCD-Datei:

ifconfig-push 10.125.175.2 255.255.255.0
ifconfig-ipv6-push 2a02:3100:2590:ec01::1003/124 2a02:3100:2590:ec01::1/124
iroute-ipv6 2a02:3100:2590:ec01::1003/124

Netzwerkinfos vom Client:

ip -6 addr show tun0
34: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    inet6 fe80::dd31:17aa:c4fa:f430/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
max@ugly-unicorn:~$ ip -6 route show
2a02:3100:1951:ca00::/64 dev wlx3498b53584d6 proto ra metric 600 pref medium
2a02:3100:1951:ca00::/64 via fe80::d624:ddff:fe1e:6170 dev wlx3498b53584d6 proto ra metric 605 pref medium
2a02:3100:1951:ca00::/56 via fe80::d624:ddff:fe1e:6170 dev wlx3498b53584d6 proto ra metric 600 pref medium
2a02:3100:2590:ec00::/64 dev wlx3498b53584d6 proto ra metric 600 pref medium
2a02:3100:2590:ec00::/56 via fe80::d624:ddff:fe1e:6170 dev wlx3498b53584d6 proto ra metric 600 pref medium
fd84:9c99:3e08::/64 dev wlx3498b53584d6 proto ra metric 600 pref medium
fd84:9c99:3e08::/64 via fe80::d624:ddff:fe1e:6170 dev wlx3498b53584d6 proto ra metric 605 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev wlx3498b53584d6 proto kernel metric 1024 pref medium
default via fe80::d624:ddff:fe1e:6170 dev wlx3498b53584d6 proto ra metric 600 pref medium

VPN-Log:

Sep 13 02:23:31 ugly-unicorn nm-openvpn[12179]: event_wait : Interrupted system call (fd=-1,code=4)
Sep 13 02:23:31 ugly-unicorn nm-openvpn[12179]: SIGTERM[hard,] received, process exiting
Sep 13 02:23:32 ugly-unicorn NetworkManager[1180]: <info>  [1757723012.7025] vpn[0x578a181e5fc0,17fde95d-fadd-4991-bb8c-8b1520c77bc9,"Max_Laptop"]: starting openvpn
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: OpenVPN 2.6.14 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: library versions: OpenSSL 3.0.13 30 Jan 2024, LZO 2.10
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: DCO version: N/A
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: TCP/UDP: Preserving recently used remote address: [AF_INET]93.128.184.84:1194
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: UDPv4 link local: (not bound)
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: UDPv4 link remote: [AF_INET]93.128.184.84:1194
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: [clumsy-camel_67c1b959-7d87-48c4-a94c-298162db268e] Peer Connection Initiated with [AF_INET]93.128.184.84:1194
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:2: block-outside-dns (2.6.14)
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: TUN/TAP device tun0 opened
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: /usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 12707 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_64 --tun -- tun0 1500 0 10.125.175.2 255.255.255.0 init
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: UID set to nm-openvpn
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: GID set to nm-openvpn
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: Capabilities retained: CAP_NET_ADMIN
Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: Initialization Sequence Completed

Danke schon mal.

Wie sieht bei Windows die Routingtabelle aus?

Was ist damit?

Sep 13 02:23:32 ugly-unicorn nm-openvpn[12713]: WARNING: You have specified redirect-gateway and redirect-private at the same time (or the same option multiple times). This is not well supported and may lead to unexpected results

Uh. Das weiß ich nicht. Der Laptop befindet sich in Tanzania. Da habe ich gerade nur eingeschränkten Zugriff. 🙄

Das ist ein heißer Tipp, danke.

Die Option hatte ich in meinem verzeifelten Versuch alles durch den Tunnel zu routen in die Client-Conf. hinzugefügt.

push "redirect-gateway def1"
push "route-ipv6 ::/0"

Ohne klappt es zumindest aus dem Heimnetz.

Danke.

Sehe ich das richtig, dass ich jetzt ein ipv4 Leak habe? Der Traffic, der durch die VPN geht passt auch nicht zu dem erwarteten Traffic.

ip  addr show tun0
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.125.175.2/24 brd 10.125.175.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 2a02:3100:2d40:8701::1003/124 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::c84a:7504:79a0:ece2/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
max@ugly-unicorn:~$ ip  route show
default via 10.125.175.1 dev tun0 proto static metric 50 
default via 192.168.178.1 dev wlx3498b53584d6 proto dhcp src 192.168.178.24 metric 601 
10.125.175.0/24 dev tun0 proto kernel scope link src 10.125.175.2 metric 50 
77.191.142.156 via 192.168.178.1 dev wlx3498b53584d6 proto static metric 50 
192.168.178.0/24 dev wlx3498b53584d6 proto kernel scope link src 192.168.178.24 metric 601 
192.168.178.1 dev wlx3498b53584d6 proto static scope link metric 50 
max@ugly-unicorn:~$ ip -6 addr show tun0
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    inet6 2a02:3100:2d40:8701::1003/124 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::c84a:7504:79a0:ece2/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
max@ugly-unicorn:~$ ip -6 route show
::/3 via 2a02:3100:2d40:8701::1 dev tun0 proto static metric 50 pref medium
2a02:3100:2d40:8700::/64 dev wlx3498b53584d6 proto ra metric 601 pref medium
2a02:3100:2d40:8701::1000/124 dev tun0 proto kernel metric 50 pref medium
2a02:3100:2d40:8700::/56 via fe80::d624:ddff:fe1e:6170 dev wlx3498b53584d6 proto ra metric 601 pref medium
2000::/4 via 2a02:3100:2d40:8701::1 dev tun0 proto static metric 50 pref medium
fd84:9c99:3e08::/64 dev wlx3498b53584d6 proto ra metric 601 pref medium
fd84:9c99:3e08::/64 via fe80::d624:ddff:fe1e:6170 dev wlx3498b53584d6 proto ra metric 606 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev wlx3498b53584d6 proto kernel metric 1024 pref medium
default dev tun0 proto static metric 50 pref medium
default via 2a02:3100:2d40:8701::1 dev tun0 proto static metric 50 pref medium
default via fe80::d624:ddff:fe1e:6170 dev wlx3498b53584d6 proto ra metric 601 pref medium

2000::/4 via 2a02:3100:2d40:8701::1 dev tun0 proto static metric 50 pref medium
::/3 via 2a02:3100:2d40:8701::1 dev tun0 proto static metric 50 pref medium

Wasn das fürn Quatsch?

Ich habe eben mal testweise 1GB gedownloaded. Der Server zeigt mir knapp 40MB Traffic an. Irgendwas stimmt da nicht.

Du solltest halt mal auf die Fragen antworten. Traceroute wäre auch interessant.

gazrilla92 schrieb:

Sehe ich das richtig, dass ich jetzt ein ipv4 Leak habe? Der Traffic, der durch die VPN geht passt auch nicht zu dem erwarteten Traffic.

Wie sind z. Zt. die Ausgaben von:

ip -4 r g 1.1.1.1
mtr -4nr -c 1 1.1.1.1

und

ip -6 r g 2a02:2e0:3fe:1001:302::
mtr -6nr -c 1 2a02:2e0:3fe:1001:302::

?

DJKUhpisse schrieb:

Du solltest halt mal auf die Fragen antworten. Traceroute wäre auch interessant.

Sorry, das ist mir wohl durchgerutscht.

traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  pi.hole (10.125.175.1)  2.426 ms  2.393 ms  2.372 ms
 2  fritz.box (192.168.178.1)  4.804 ms  4.793 ms  4.790 ms
 3  loopback1.0001.acln.05.ber.de.net.telefonica.de (62.52.192.37)  14.447 ms  15.160 ms  15.157 ms
 4  bundle-ether37.0002.cord.05.ber.de.net.telefonica.de (62.53.5.174)  15.146 ms  15.143 ms bundle-ether37.0001.cord.05.ber.de.net.telefonica.de (62.53.5.142)  15.139 ms
 5  bundle-ether17.0003.corx.02.ber.de.net.telefonica.de (62.53.8.118)  25.086 ms  25.083 ms bundle-ether16.0003.corx.02.ber.de.net.telefonica.de (62.53.8.114)  25.045 ms
 6  bundle-ether17.0001.corx.01.htt.de.net.telefonica.de (62.53.10.55)  25.071 ms  23.829 ms bundle-ether27.0002.corx.01.off.de.net.telefonica.de (62.53.10.87)  25.687 ms
 7  bundle-ether2.0002.cord.02.fra.de.net.telefonica.de (62.53.28.151)  25.692 ms bundle-ether2.0001.cord.02.fra.de.net.telefonica.de (62.53.28.149)  26.399 ms bundle-ether11.0002.cord.01.muc.de.net.telefonica.de (62.53.4.163)  23.855 ms
 8  bundle-ether1.0001.corp.02.fra.de.net.telefonica.de (62.53.8.187)  26.828 ms ae0-0.0001.corp.01.muc.de.net.telefonica.de (62.53.11.13)  24.428 ms bundle-ether2.0001.corp.02.fra.de.net.telefonica.de (62.53.8.189)  128.277 ms
 9  72.14.219.226 (72.14.219.226)  128.212 ms  128.216 ms *
10  * * 192.178.106.11 (192.178.106.11)  128.190 ms
11  142.251.68.125 (142.251.68.125)  128.153 ms dns.google (8.8.8.8)  128.171 ms  128.164 ms
max@ugly-unicorn:~$ traceroute -6 ipv6.google.com
traceroute to ipv6.google.com (2a00:1450:4001:803::200e), 30 hops max, 80 byte packets
 1  pi.hole (2a02:3100:1cf5:7201::1)  3.078 ms  3.074 ms  3.072 ms
 2  dynamic-2a02-3100-1cf5-7200-d624-ddff-fe1e-6170.310.pool.telefonica.de (2a02:3100:1cf5:7200:d624:ddff:fe1e:6170)  4.138 ms  4.119 ms  4.112 ms
 3  2a02:3001::120 (2a02:3001::120)  17.116 ms  17.107 ms  17.094 ms
 4  * * *
 5  * 2a00:1450:8154::1 (2a00:1450:8154::1)  27.053 ms  27.049 ms
 6  2a00:1450:814d::1 (2a00:1450:814d::1)  27.041 ms 2a00:1450:814f::1 (2a00:1450:814f::1)  25.154 ms 2a00:1450:80d9::1 (2a00:1450:80d9::1)  26.652 ms
 7  2001:4860:0:1::4176 (2001:4860:0:1::4176)  24.973 ms * 2001:4860:0:1::509c (2001:4860:0:1::509c)  24.964 ms
 8  2001:4860:0:1::8698 (2001:4860:0:1::8698)  27.584 ms * 2001:4860:0:1::8656 (2001:4860:0:1::8656)  29.038 ms
 9  fra07s30-in-x200e.1e100.net (2a00:1450:4001:803::200e)  24.464 ms 2001:4860::c:4003:364f (2001:4860::c:4003:364f)  25.429 ms fra24s02-in-x0e.1e100.net (2a00:1450:4001:803::200e)  24.454 ms

lubux schrieb:

Wie sind z. Zt. die Ausgaben von:

ip -4 r g 1.1.1.1
mtr -4nr -c 1 1.1.1.1

und

ip -6 r g 2a02:2e0:3fe:1001:302::
mtr -6nr -c 1 2a02:2e0:3fe:1001:302::

?

p -4 r g 1.1.1.1
1.1.1.1 via 10.125.175.1 dev tun0 src 10.125.175.2 uid 1000 
    cache 
max@ugly-unicorn:~$ mtr -4nr -c 1 1.1.1.1
Start: 2025-09-13T17:25:50+0200
HOST: ugly-unicorn                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.125.175.1               0.0%     1    2.8   2.8   2.8   2.8   0.0
  2.|-- 192.168.178.1              0.0%     1    3.6   3.6   3.6   3.6   0.0
  3.|-- 62.52.192.37               0.0%     1   15.6  15.6  15.6  15.6   0.0
  4.|-- 62.53.5.174                0.0%     1   18.1  18.1  18.1  18.1   0.0
  5.|-- 62.53.8.118                0.0%     1   16.1  16.1  16.1  16.1   0.0
  6.|-- 62.53.25.242               0.0%     1   15.9  15.9  15.9  15.9   0.0
  7.|-- 62.53.0.184                0.0%     1   16.9  16.9  16.9  16.9   0.0
  8.|-- 162.158.112.6              0.0%     1   36.3  36.3  36.3  36.3   0.0
  9.|-- 1.1.1.1                    0.0%     1   14.0  14.0  14.0  14.0   0.0
max@ugly-unicorn:~$ ip -6 r g 2a02:2e0:3fe:1001:302::
2a02:2e0:3fe:1001:302:: from :: via 2a02:3100:1cf5:7201::1 dev tun0 proto static src 2a02:3100:1cf5:7201::1003 metric 50 pref medium
max@ugly-unicorn:~$ mtr -6nr -c 1 2a02:2e0:3fe:1001:302::
Start: 2025-09-13T17:26:53+0200
HOST: ugly-unicorn                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a02:3100:1cf5:7201::1     0.0%     1    3.4   3.4   3.4   3.4   0.0
  2.|-- 2a02:3100:1cf5:7200:d624:  0.0%     1    3.5   3.5   3.5   3.5   0.0
  3.|-- 2a02:3001::120             0.0%     1  137.3 137.3 137.3 137.3   0.0
  4.|-- 2001:7f8::1a95:0:2         0.0%     1   47.5  47.5  47.5  47.5   0.0
  5.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  6.|-- 2a02:2e0:12:15::115        0.0%     1  194.1 194.1 194.1 194.1   0.0
  7.|-- 2a02:2e0:3fe:0:c::1        0.0%     1  117.7 117.7 117.7 117.7   0.0
  8.|-- 2a02:2e0:3fe:1001:302::    0.0%     1   26.0  26.0  26.0  26.0   0.0

Sieht doch jetzt gut aus, oder?

In welchem konkreten Fall geht der Traffic nicht durch den Tunnel?

Wenn ich streame, oder Dinge im Internet downloade ist der Traffic auf dem Server viel zu gering. So ein YouTube Video z.B von 5minb verursacht Traffic von 500kb bis 1MBbauf dem Server. Das kann nicht sein.

Ok, dann schau mit

ss -tup

, von welcher IP die Verbindung aufgebaut wird. Es muss die vom Tunnel sein.

In dem Fall wäre dann auch die Routingtabelle interessant.

gazrilla92 schrieb:

Wenn ich streame, oder Dinge im Internet downloade ist der Traffic auf dem Server viel zu gering.

Du könntest mit z. B. tcpdump (zu richtigen Zeitpunkt und mit dem geeigneten Filter) am zuständigen Interface schauen, ob dort der Download-Traffic (anhand der src- und dst-IP) statt findet. Z. B.:

sudo tcpdump -c 100 -vvveni tun0 tcp

Wenn Du die src-IP kennst, kannst Du den Filter verbessern/optimieren/ergänzen.