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?
Beiträge von morki
-
-
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
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:
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
-
Hallo Frank,
ja. Ping aufs Defaultgateway geht raus
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
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 * * *
-
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:
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
PING google.de(fra15s10-in-x03.1e100.net (2a00:1450:4001:811::2003)) 56 data bytes
ip6 -a ergibt nun
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
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
::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
-
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:
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
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
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.