Verbindung über IPv6 nicht möglich

    Hallo zusammen,


    Ich bin leider mittlerweile etwas verzweifelt. Ich versuche schon seit längerem eine IPv6 Verbindung einzurichten, schaffe es aber einfach nicht! X(


    Als Produkt habe ich einen VPS 500 G10s

    Installiert wurde dieser damals über das Ubuntu Image von Netcup.

    Auf dem Server läuft Docker mit Mailcow als E-Mailserver.

    Das ganze funktioniert auch schon seit mehr als einem Jahr problemlos, halt nur mit einer IPv4 Adresse.


    Im SCP habe ich unter Netzwerk - > IPv6 eine v6 Adresse und DNS Namen konfiguriert, hier als 2a03:4000:xxxx:xxxx::2 und mail.domain.com gekennzeichnet.


    Das Problem äußert sich recht einfach:

    Code: # ping -6 google.de
    PING google.de(fra16s51-in-x03.1e100.net (2a00:1450:4001:811::2003)) 56 data bytes
From mail.scuruba.de (2a03:4000:4d:f5e::2) icmp_seq=1 Destination unreachable: Address unreachable
From mail.scuruba.de (2a03:4000:4d:f5e::2) icmp_seq=2 Destination unreachable: Address unreachable
From mail.scuruba.de (2a03:4000:4d:f5e::2) icmp_seq=3 Destination unreachable: Address unreachable


--- google.de ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3074ms


    Oder auch:

    Code: # ping -6 -I eth0 google.de
    PING google.de(fra15s10-in-x03.1e100.net (2a00:1450:4001:811::2003)) from 2a03:4000:xxxx:xxxx::2 eth0: 56 data bytes
From mail.scuruba.de (2a03:4000:xxxx:xxxx::2) icmp_seq=1 Destination unreachable: Address unreachable
From mail.scuruba.de (2a03:4000:xxxx:xxxx::2) icmp_seq=2 Destination unreachable: Address unreachable
From mail.scuruba.de (2a03:4000:xxxx:xxxx::2) icmp_seq=3 Destination unreachable: Address unreachable

    Und auch von außen ist er somit natürlich nicht erreichbar.


    Konfiguriert habe ich die Adresse über Netplan, so wie es auch im Image war:




    Ich habe den Server auch schon einige male neu gestartet und auch komplett heruntergefahren und gestartet, wie es wohl Probleme bei manchen schon behoben hat.

    Ich hatte auch die Vermutung, dass das Docker-Gateway mit der selben Adresse (fe80::1) ein Problem ist, mein eth0-Gateway ist aber global und das docker0 nur link. Ich hatte es auch so verstanden beim recherchieren, dass das Gateway normal ist und keine Probleme machen sollte. Ich hatte vorsichtshalber aber einmal einen ping mit Gateway (-I eth0) gemacht, was auch nicht funktioniert hatte.


    Ich hoffe mir kann hier jemand weiterhelfen.


    Grüße

    Vongwegen

    Hier noch ein Befehl, der Post war aber zu lang:


    Was passiert mit der Original-IP vom Server? Also mit der Standard-Konfiguration nach der Installation des Images? Was ist mit der Firewall?


    Willst du NAT für IPv6 machen? Würde ich nicht empfehlen. Verpasse dem Docker Container besser eine öffentliche IPv6, vorzugsweise aus einem zusätzlichen /64 um der Problematik des geswitchten ersten /64 aus dem Lieferumfang aus dem Weg zu gehen.


    Falls doch NAT: hast du die entsprechenden Firewall Regeln eingeführt?

    Zitat von frank_m

    Was passiert mit der Original-IP vom Server? Also mit der Standard-Konfiguration nach der Installation des Images? Was ist mit der Firewall?


    Willst du NAT für IPv6 machen? Würde ich nicht empfehlen. Verpasse dem Docker Container besser eine öffentliche IPv6, vorzugsweise aus einem zusätzlichen /64 um der Problematik des geswitchten ersren /64 aus dem Lieferumfang aus dem Weg zu gehen.


    Falls doch NAT: hast du die entsprechenden Firewall Regeln eingeführt?

    Hallo Frank,

    ich weiß gerade nicht was du mit der Original IP meinst... die Einträge in SCP waren leer.

    Mit NAT oder nicht hatte ich mich nicht wirklich beschäftigt bis jetzt, da es ja nicht einmal auf dem Server selbst funktioniert. Aber ich kann ihm natürlich Docker noch eine IP zuweisen, hört sich am besten an.

    Was ich noch vergessen hatte zu erwähnen: Ich hatte auch den Support schon kontaktiert, dieser war aber wenig hilfreich. Sie wollten nur wissen ob ich das Rettungssystem starten kann und dann noch ob ich eine IPv6 dort konfigurieren kann. Dort hat es funktioniert. Danach war das Thema für sie erledigt.

    Zitat von Vongwegen

    ich weiß gerade nicht was du mit der Original IP meinst

    Der Server hat im Auslieferungszustand eine IPv6 Adresse, die sich aus deinem Prefix und der EUI-64 Interface ID des Servers zusammensetzt. Die ist z.B. auch das Routing Ziel für zusätzliche IPv6 Netze und damit die "Standard-Adresse" in der netcup Welt für diesen Server. Die solltest du auf jeden Fall testen.

    Zitat von Vongwegen

    Aber ich kann ihm natürlich Docker noch eine IP zuweisen, hört sich am besten an.

    Denk an die Verbindungsunterbrechungen aufgrund von NDP, wenn du dem Docker Container eine Adresse aus deinem mitgelieferten /64 zuweist.


    Zitat von Vongwegen

    Sie wollten nur wissen ob ich das Rettungssystem starten kann und dann noch ob ich eine IPv6 dort konfigurieren kann. Dort hat es funktioniert. Danach war das Thema für sie erledigt.

    Ich glaube auch nicht, dass das ein Problem der Infrastruktur ist. Wenn die Adresse und die Routen richtig eingerichtet sind (also passt das Prefix?), dann kommt natürlich als erstes die Firewall ins Spiel, denn die ist im Rescue Image nicht aktiv.

    Zitat von Vongwegen

    ich weiß gerade nicht was du mit der Original IP meinst... die Einträge in SCP waren leer.

    Zitat von Vongwegen

    Installiert wurde dieser damals über das Ubuntu Image von Netcup.

    Bei Installation eines netcup-ubuntu-Images ist immer schon eine ipv6 in der Netzwerk-Konfiguration (ab Ubuntu 20 in netplan, vorher in network/interfaces) eingetragen und aktiviert.


    (Die rDNS-Einträge Im SCP sind ja für das Funktionieren der ipv6 belanglos)

    Ich habe mir jetzt einmal einen neuen Server geholt um dort die Konfiguration nachzuvollziehen.
    Dementsprechend habe ich jetzt auch die Original IP wiederhergestellt, diese hatte ich wohl überschrieben ....

    Trotzdem hatte es erst einmal nicht funktioniert, daher habe ich jetzt mal kurze die FW deaktiviert für einen ping. Schon hast es funktioniert, jedenfalls bis zu einem reboot.

    Das hatte ich schon einmal vor einiger Zeit bei der Fehlersuche gemacht, hatte damals aber nichts genutzt. Muss wohl ein klassischer Doppelfehler gewesen sein.
    Ich muss mir jetzt noch mal anschauen was bei NFTables nicht stimmt in der Konfiguration. Vielleicht schaffe ich es diese Woche noch, bin zir Zeit etwas eingespannt.

    Danke schon mal für eure Tipps, das hat mich schon weitergebracht. Updates dann die Tage

    icmpv6 und das Zusammenspiel mit der Firewall wäre wohl ein sinnvoller Startpunkt. icmpv6 ist eine deutlich komplexere Geschichte als bei v4. Die Blockierung aller icmpv6 verbindungen bleibt halt nicht so straflos wie bei ipv4. Wenn du für einen IPv6 Ping schon die FW aufmachen musst dann hast du wohl noch einiges freizugeben bis es reibungslos funktioniert.

    Zitat von tab

    wohl noch einiges freizugeben bis es reibungslos funktioniert.

    Zwar iptables, sollte aber in nftables übersetzbar sein :)

    Bei mir hat jetzt die Zeile ausgereicht:

    Code
          ip6 nexthdr icmpv6 icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, echo-request, parameter-problem, echo-reply, nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, ind-neighbor-solicit, ind-neighbor-advert } accept

    Somit scheint jetzt alles zu funktionieren. :) Ping von außen und innen gehen nun.

    Zitat von H6G

    Zwar iptables, sollte aber in nftables übersetzbar sein :)

    Die könnte man mit iptables-translate übersetzen lassen und einfügen, danke!