Ipv6-Probleme

    Hallo zusammen,

    ich betreibe auf einem vServer eine Debian 11-Instanz um einige Docker-Anwendungen und ein Wireguard-VPN zu betreiben. Im Rahmen der Installation fiel mir auf, dass es offensichtlich ein Problem mit der Ipv6-Konnektivität bei mir gibt.

    Ich habe eine statische Ipv6 in der /etc/network/interfaces.d/50-cloud-init.cfg konfiguriert. Dies sieht bei mir so aus:

    Spoiler anzeigen

    auto lo

    iface lo inet loopback

    auto eth0

    iface eth0 inet static

    address 46.38.xx.xx/21

    gateway 46.38.232.1

    iface eth0 inet6 static

    address 2a03:4000:x:xx::1/64

    gateway fe80::1

    ein ip a bringt folgende Ausgabe

    Spoiler anzeigen

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    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 ea:b6:8b:xx:xx:54 brd ff:ff:ff:ff:ff:ff

    altname enp0s3

    altname ens3

    inet 46.38.xx.xx/21 brd 46.38.239.255 scope global eth0

    valid_lft forever preferred_lft forever

    inet6 2a03:4000:xx:xx::1/64 scope global

    valid_lft forever preferred_lft forever

    inet6 fe80::e8b6:xx:xx:xx/64 scope link

    valid_lft forever preferred_lft forever

    Ein ping6 google.de bringt

    Spoiler anzeigen

    PING google.de(fra16s53-in-x03.1e100.net (2a00:1450:4001:813::2003)) 56 data bytes

    64 bytes from fra16s53-in-x03.1e100.net (2a00:1450:4001:813::2003): icmp_seq=1 ttl=119 time=3.63 ms

    64 bytes from fra16s53-in-x03.1e100.net (2a00:1450:4001:813::2003): icmp_seq=2 ttl=119 time=3.68 ms

    64 bytes from fra16s53-in-x03.1e100.net (2a00:1450:4001:813::2003): icmp_seq=3 ttl=119 time=3.66 ms

    64 bytes from fra16s53-in-x03.1e100.net (2a00:1450:4001:813::2003): icmp_seq=4 ttl=119 time=3.71 ms

    Soweit so gut. Nun das eigentliche Problem: Nach einer gewissen Laufzeit wobei diese zwischen wenigen Minuten und einigen Stunden liegen kann scheint sich mein Ipv6 komplett zu verabschieden. Es ist kein Ping6 mehr möglich. Ist dieses Problem bekannt oder habe ich einen Konfiurationsfehler ( was ich für wahrscheinlicher halte ;-)) in meinen Einstellungen?

    Bereits jetzt ein Dank für die Unterstützung.

    Zuerst: Ich würde das lieber nicht in der Datei 50-cloud-init.cfg hinterlegen. Besser wäre es wahrscheinlich, die Datei umzubenennen. Womöglich muss Cloud-Init danach auch noch deaktiviert werden. (Mit den Standardimages von netcup habe ich keine Erfahrung, ich installiere immer über ISO.)

    Muss nicht daran liegen, aber hast Du die empfohlene sysctl-Konfiguration irgendwo hinterlegt? (accept_ra=0 & autoconf=0)

    Siehe Codeblock bei /etc/sysctl.d/50-IPv6.conf: https://www.netcup-wiki.de/wiki/Zus%C3%A4…figurieren#IPv6

    Ansonsten: Was ergeben die nachfolgenden Befehle, wenn es wieder nicht funktioniert?

    Code
    ip -6 a
ip -6 n
ip -6 r

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Hi KB 19,

    vielen Dank für Deine Hilfe! Ja im Nachhinein betrachtet hätte ich wohl aus diversen Gründen besser ein ISO wählen sollen. Jetzt ist es dafür leider zu spät, da der Server komplett aufgesetzt ist und ich ihn zunächst so nutzen muss.

    /etc/sysctl.d/50-IPv6.conf sieht so aus:

    Spoiler anzeigen

    net.ipv6.conf.default.accept_ra=0

    net.ipv6.conf.default.autoconf=0

    net.ipv6.conf.all.accept_ra=0

    net.ipv6.conf.all.autoconf=0

    net.ipv6.conf.eth0.accept_ra=0

    net.ipv6.conf.eth0.autoconf=0

    net.ipv6.conf.eth1.accept_ra=0

    net.ipv6.conf.eth1.autoconf=0

    net.ipv6.conf.eth2.accept_ra=0

    net.ipv6.conf.eth2.autoconf=0

    net.ipv6.conf.eth3.accept_ra=0

    net.ipv6.conf.eth3.autoconf=0

    net.ipv6.conf.eth4.accept_ra=0

    net.ipv6.conf.eth4.autoconf=0

    net.ipv6.conf.eth5.accept_ra=0

    net.ipv6.conf.eth5.autoconf=0

    net.ipv6.conf.eth6.accept_ra=0

    net.ipv6.conf.eth6.autoconf=0

    net.ipv6.conf.eth7.accept_ra=0

    net.ipv6.conf.eth7.autoconf=0

    net.ipv6.conf.eth8.accept_ra=0

    net.ipv6.conf.eth8.autoconf=0

    net.ipv6.conf.eth9.accept_ra=0

    net.ipv6.conf.eth9.autoconf=0

    Nach kurzer funktionierender V6 ergibt ein Ping6 nun wieder:

    ping6 google.de

    Spoiler anzeigen

    PING google.de(fra15s10-in-x03.1e100.net (2a00:1450:4001:811::2003)) 56 data bytes

    ip6 -a ergibt nun

    Spoiler anzeigen

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000

    inet6 ::1/128 scope host

    valid_lft forever preferred_lft forever

    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000

    inet6 2a03:xx:xx:xx::1/64 scope global

    valid_lft forever preferred_lft forever

    inet6 fe80::xx:xx:xx:xx/64 scope link

    valid_lft forever preferred_lft forever

    ip6 -n

    Spoiler anzeigen

    fe80::7 dev eth0 lladdr 00:00:5e:00:02:12 router STALE

    fe80::4 dev eth0 lladdr 00:00:5e:00:02:0a router STALE

    fe80::xxx:xxx:xxx:ff4 dev eth0 lladdr 2c:6b:f5:a0:77:c0 router STALE

    fe80::xxx:xxx:xxx:424c dev eth0 lladdr 10:0e:7e:26:f1:c0 router STALE

    fe80::1 dev eth0 lladdr 00:00:5e:00:02:03 router STALE

    2a03:xxx:xx::3 dev eth0 FAILED

    fe80::5 dev eth0 lladdr 00:00:5e:00:02:0b router STALE

    fe80::2 dev eth0 lladdr 00:00:5e:00:02:04 router STALE

    fe80::6 dev eth0 lladdr 00:00:5e:00:02:11 router STALE

    fe80::xxx:xxx:xxx dev eth0 lladdr fe:b6:8b:98:b7:54 STALE

    fe80::3 dev eth0 lladdr 00:00:5e:00:02:05 router STALE

    ip6 -r

    Spoiler anzeigen

    ::1 dev lo proto kernel metric 256 pref medium

    2a03:xx:2:xx::/64 dev eth0 proto kernel metric 256 pref medium

    fd9e:xx:xx:xx::/64 dev wg0 proto kernel metric 256 pref medium

    fe80::/64 dev eth0 proto kernel metric 256 pref medium

    fe80::/64 dev br-0012eeaf195b proto kernel metric 256 pref medium

    fe80::/64 dev veth0605698 proto kernel metric 256 pref medium

    fe80::/64 dev br-ce9f2bf13ced proto kernel metric 256 pref medium

    fe80::/64 dev veth4167e4f proto kernel metric 256 pref medium

    fe80::/64 dev docker0 proto kernel metric 256 pref medium

    fe80::/64 dev vethe2d81f3 proto kernel metric 256 pref medium

    fe80::/64 dev vethc2f26ab proto kernel metric 256 pref medium

    fe80::/64 dev br-769260a8898d proto kernel metric 256 pref medium

    fe80::/64 dev veth0bbb0e9 proto kernel metric 256 pref medium

    fe80::/64 dev br-121b58fad8bd proto kernel metric 256 pref medium

    fe80::/64 dev veth4048f4f proto kernel metric 256 pref medium

    default via fe80::1 dev eth0 metric 1024 onlink pref medium

    Ich muss gestehen dass ich leider keinerlei Ahnung habe, woran es liegen könnte 8o

    Einmal editiert, zuletzt von morki (13. Juni 2022 um 08:18)

    Hallo Frank,

    ja. Ping aufs Defaultgateway geht raus

    Spoiler anzeigen

    PING fe80::1(fe80::1) 56 data bytes

    64 bytes from fe80::1%eth0: icmp_seq=1 ttl=64 time=49.7 ms

    64 bytes from fe80::1%eth0: icmp_seq=2 ttl=64 time=0.481 ms

    64 bytes from fe80::1%eth0: icmp_seq=3 ttl=64 time=1.91 ms

    64 bytes from fe80::1%eth0: icmp_seq=4 ttl=64 time=0.411 ms

    Traceroute6

    Spoiler anzeigen

    traceroute6 google.de

    traceroute to google.de (2a00:1450:4001:813::2003), 30 hops max, 80 byte packets

    1 * * *

    2 * * *

    3 * * *

    4 * * *

    5 * * *

    6 * * *

    7 * * *

    8 * * *

    9 * * *

    10 * * *

    11 * * *

    12 * * *

    13 * * *

    14 * * *

    15 * * *

    16 * * *

    17 * * *

    18 * * *

    19 * * *

    20 * * *

    21 * * *

    22 * * *

    23 * * *

    24 * * *

    25 * * *

    26 * * *

    27 * * *

    28 * * *

    29 * * *

    30 * * *


    Daran habe ich tatsächlich auch schon gedacht. Zumal es ja erst läuft und erst nach einer gewissen Zeit nicht mehr.

    Ein Deaktivieren von UFW bringt aber leider auch nix

    Spoiler anzeigen

    root@server:/home/marcel# sudo ufw disable

    Firewall stopped and disabled on system startup

    root@server:/# ping6 google.de

    PING google.de(fra16s53-in-x03.1e100.net (2a00:1450:4001:813::2003)) 56 data bytes

    Und Iptables:

    Spoiler anzeigen

    root@server:~# sudo iptables -X

    root@server:~# sudo iptables -P INPUT ACCEPT

    root@server:~# sudo iptables -P OUTPUT ACCEPT

    root@server:~# sudo iptables -P FORWARD ACCEPT

    root@server:~# sudo iptables -L

    Chain INPUT (policy ACCEPT)

    target prot opt source destination

    Chain FORWARD (policy ACCEPT)

    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)

    target prot opt source destination

    root@server:~# ping6 google.de

    PING google.de(fra16s53-in-x03.1e100.net (2a00:1450:4001:813::2003)) 56 data bytes

    ^C

    --- google.de ping statistics ---

    3 packets transmitted, 0 received, 100% packet loss, time 2041ms

    Was kann ich noch tun um zu testen ob es an einem Filter o.ä. liegt ? Hast Du eine Idee?


    Gruss

    Einmal editiert, zuletzt von morki (13. Juni 2022 um 12:08)

    Leider habe ich bisher noch immer das Problem nicht finden können. Testhalber habe ich mal neu aufgesetzt. Sowohl mit eigener ISO als auch mit den Netcup-Images tritt der Fehler immer wieder auf. Exakt nach 20 Minuten wird mir IPV6 abgedreht und die Routen gehen offensichtlich verloren. Die statische IP-Konfiguration habe ich wie im Wiki beschrieben vorgenommen und trotzdem kommt es zu dem o.a. Problem. Gibt es hier noch jemanden, der ähnliche Probleme festgestellt hat und kann eine Lösung anbieten?

    Probliere es mal mit folgender leicht geänderten Konfiguration.

    Code
    auto eth0
iface eth0 inet static
    address 46.38.xx.xx/22
    gateway 46.38.232.1

iface eth0 inet6 static
    address 2a03:4000:x:xx::10/64
    gateway fe80::1

    Folgenden Befehl über die Console danach eingeben:

    Code
    systemctl restart networking
    Zitat von frank_m

    Komisch, das sieht so aus, als ob deine Pakete deinen VPS gar nicht verlassen.

    Spielt dir da vielleicht eine Firewall einen Streich?

    Können sie ja nicht, wenn sie kein Gateway haben. ;)


    Zitat von morki

    Exakt nach 20 Minuten wird mir IPV6 abgedreht und die Routen gehen offensichtlich verloren.

    Ursprünglich ist das ein Problem mit den accept ra.

    Hast du nach der Erstellung der sysctl.d Datei einen Neustart gemacht?

    Btw. iptables für IPv6 benutzt das ip6tables Kommando - da wirst du bei iptables nichts sehen.