IPv6 nicht erreichbar

  • 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:



    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:


    Code
    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


    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.

  • Das finde ich auch seltsam, weil auch eingehende Verbindungen von außen funktionieren.
    Route:

    Code
    # ip -6 route
    <MY_IP6_SUBNET>/64 dev eth0  proto kernel  metric 256
    fe80::/64 dev eth0  proto kernel  metric 256
    default via fe80::1 dev eth0  metric 1024


    Code
    # traceroute6 heise.de
    traceroute to heise.de (2a02:2e0:3fe:1001:302::), 30 hops max, 80 byte packets
     1  2a03:4000:0:2::3 (2a03:4000:0:2::3)  0.583 ms  0.923 ms  0.508 ms
     2  * * *
    ...
    30 * * *
  • 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:


    Die Reihenfolge der Address-Blöcke ist wichtig! Die xxx::2/64 muss als erstes dran stehen.