Weißt du was sie geändert haben?
Wenn es am Rettungssystem deines Servers war, muss es ja ein Problem an der Software bzw. deiner Konfiguration liegen.
Weißt du was sie geändert haben?
Wenn es am Rettungssystem deines Servers war, muss es ja ein Problem an der Software bzw. deiner Konfiguration liegen.
Ich weiß nicht genau was gemacht worden ist. Das Rettungssystem ist verwendet worden um den Sachverhalt auf 'neutralen Boden' nachzuvollziehen, also um auszuschließen dass das Problem nur innerhalb meiner VM ist.
Du kannst das einfach bei dir nachvollziehen in dem du auch das Rescue System verwendest und folgende Schritte ausführst:
1.) Check no IPv6 configured
rescue:~# ip a
2.) Ping via IPv6 should not work as not configured
rescue:~# ping6 -c3 google.de
connect: Network is unreachable
3.) Add your IPv6 Address
rescue:~# ip -6 addr add <YOUR_IPv6_ADDRESS>/64 dev eth0
4.) Check IPv6 Address added
rescue:~# ip a
5.) Add default route
rescue:~# ip -6 route add default via fe80::1 dev eth0
6.) Ping default gateway should work
rescue:~# ping6 -c3 -I eth0 fe80::1
7.) Ping Google via IPv6 address should work
rescue:~# ping6 -c3 -I eth0 2a00:1450:400a:804::1017
8.) Traceroute to Google via IPv6 address should work
rescue:~# traceroute6 2a00:1450:400a:804::1017
9.) Traceroute to Goolge via DNS should also work
rescue:~# traceroute6 google.de
Alles anzeigen
Mein konkretes Problem war, dass in Schritt 7 - 9 nicht funktionierten. In Schritt 8/9 ist mir aber aufgefallen, dass der erste Hop erfolgreich war jedoch dann der Paketfluss endete:
rescue:~# traceroute6 2a00:1450:400a:804::1017
traceroute to 2a00:1450:400a:804::1017 (2a00:1450:400a:804::1017), 30 hops max, 80 byte packets
1 2a03:4000:6:7000::3 (2a03:4000:6:7000::3) 0.181 ms 28.370 ms 28.385 ms
2 * * *
3 * * *
...
30 * * *
Ich hoffe das hilft dir weiter.
Leider nicht, das beschreibt ja nur das Problem und nicht die Lösung. Spannend zu wissen wäre was der Support geändert hat. Es kann ja nur an der Software liegen.
Ich hänge bereits an Schritt 6. Ich kann das Gateway nicht anpingen.
Naja, wie gesagt habe ich an meiner VM nichts geändert (und auch nicht Netcup).
Die Änderung, die Netcup vorgenommen hat, kann aus meiner Sicht entweder am Host (auf dem meine VM läuft) oder in der Infrastruktur gelegen haben.
Die Frage ist also, ob du das Verhalten im Rescue-System auch bei dir nachvollziehen kannst. Wenn ja würde ich den Netcup Support mit den entsprechenden Infos kontaktieren.
Ich habe dem Support geschrieben. Wenn mir soweit bekannt, werde ich die Lösung (hoffentlich) hier schreiben.
Edit: Der Support hat am Rescue-System etwas geändert. Ich kann allerdings nicht sagen was, das wurde mir nicht mitgeteilt.
Anschließend habe ich systemd-networkd deaktiviert, damit hat es einfach nicht funktioniert und wieder networking.service benutzt.
Die /etc/network/interfaces unterscheidet sich nicht von den vorhergehenden. Allerdings funktioniert es jetzt (wieder).
Der Vollständigkeit halber hier trotzdem die
auto lo eth0
iface lo inet loopback
iface lo inet6 loopback
iface eth0 inet static
address <MY_IPV4>
netmask 255.255.248.0
broadcast <IPV4_BROADCAST>
gateway <IPV4_GATEWAY>
iface eth0 inet6 static
pre-up /sbin/modprobe -q ipv6 ; /bin/true
address <MY_IPV6>
netmask 64
gateway fe80::1
Alles anzeigen
Die Zeile pre-up ist von Webmin hinzugefügt worden.
Eingehender IPv6-Verkehr funktioniert nun, Nginx, Exim4 und SSH sind darüber erreichbar.
ABER vom Server aus kann ich keine IPv6-Verbindung aufbauen. Das ist schlecht, da aptitude jetzt Updates über IPv6 laden möchte und die Verbindung nicht zustande kommt.
Eingehende ping6 werden beantwortet, wenn ich aber vom Server aus einen IPv6-Host mit ping6 anpingen möchte, bleibt auch das stecken. Klingt für mich zwar nach Firewall, ip6tables zeigt aber alle chains auf ACCEPT.
Ich hatte mal soon ähnliches Problem - ich glaub da hatte bei mir ein Eintrag fürn dns-server gefehlt.
Hast schon mal getestet, ob du IPv6 adressen direkt pingen kannst?
Was kommt den für ne Meldung ? traceroute6 ?
Ich kann auch keine IPv6-Adressen anpingen. In der /etc/resolv.conf stehen die Netcup-Server drin (z.B. 2a03:4000:8000::fce6), es ändert sich daran nichts wenn ich Google-DNS eintrage.
Mit dig -6 google.com @"2001:4860:4860::8844" bekomme ich gar keine Antwort. Es gehen also ausgehende Verbindungen nicht.
Ich bekomme eine Antwort, wenn ich den Netcup-Server frage (dig -6 google.com @"2a03:4000:8000::fce6").
Wenn des aber mit dem Netcup-dns tut, geht dein IPv6 generell schon.
Kannst du mal bitte ein "ip -6 route show" absetzen und des Ergebnis posten?
Mach doch auch mal nen traceroute6 heise.de und schau wo es "Stecken" bleibt.
Ich konnte das Problem jetzt lösen.
Zum Ersten habe ich es nochmal im Rescue-Modus versucht, dort hat es funktioniert. Ich habe manuell die Adresse zugewiesen, die Route und einen DNS, dann konnte ich heise.de anping6en.
Testweise und nur, weil mir sonst nichts mehr einfiel, hab ich zusätzlich zur xxx::1/64 noch die xxx::2/64 hinzugefügt. Danach hat das Ping6en und curl -6 funktioniert. Ich habe keine Erklärung dafür, vielleicht ja sonst jemand. Es klappt nun.
Hier noch meine /etc/systemd/network/wired.network zur Vollständigkeit:
[Match]
Name=eth0
[Network]
DHCP=none
[Address]
Address=<MY_IP4>/21
[Route]
Gateway=46.38.232.1
[Address]
Address=<MY_IP6_SUB>::2/64
[Address]
Address=<MY_IP6_SUB>::1/64
[Route]
Gateway=fe80::1
Alles anzeigen
Die Reihenfolge der Address-Blöcke ist wichtig! Die xxx::2/64 muss als erstes dran stehen.