Docker-Container dauerhaft per IPv6 verfügbar machen

  • Hallo.

    Auf meinem RS1000 G8 (OS: Debian 10) möchte ich gerne einige Docker-Container direkt per IPv6 erreichbar machen. Ich nutze das mit dem Server "mitgelieferte" /64-Subnetz und habe keine zusätzlichen IPv6-Subnetze gebucht. Hierzu habe ich in Docker IPv6 aktiviert, ein neues Docker-Netzwerk mit /80-Subnetz zugewiesen und für einen Teil dieses Netzes den ndppd NDP-Proxy eingerichtet.

    Wenn ich nun einen Container starte, ist dieser initial nicht von außen erreichbar - Pings von außen liefern einen Timeout. Sobald ich innerhalb des Containers einen externen Host anpinge, gehen die ersten paar Pakete verloren. Nach dieser "Initialisierung" ist der Container im Internet per IPv6 erreichbar, empfängt die ICMP-Replys und antwortet fortan auch auf Ping-Anfragen von außen.


    Das Problem ist nur, dass der Container nach einigen Minuten ohne Traffic nicht mehr erreichbar ist und die "Initialisierungsphase" erneut durchgeführt werden muss. Vermutlich gibt es in den Netcup-Routern einen Timeout, ab dem die dynamisch angelegte Route wieder gelöscht wird.


    Gibt es eine Möglichkeit, ndppd oder einen anderen Dienst so zu konfigurieren, dass die Route aufrecht erhalten bleibt? Die "Haupt-IPv6-Adresse" des Servers, die auf eth0 eingerichtet ist, bleibt ja auch dauerhaft erreichbar. Aktuell ist IPv6 in Containern auf meinem Netcup-Server nicht praktikabel nutzbar. Der Netcup-Kundensupport verweist mich auf das Forum, da es sich hierbei um ein Softwareproblem handeln soll.


    Ich bilde mir ein, mich in Netzwerkfragen nicht ganz ungeschickt anzustellen, allerdings komme ich hier auch nach langem Herumprobieren nicht weiter. Bisher hatte ich nur mit Servern mit statisch gerouteten v6-Subnetzen zu tun. Ich möchte äußerst ungern auf IPv6-DNAT zurückgreifen - genau vor der NAT-Hölle sollte uns v6 ja ursprünglich befreien :)


    Es wäre sehr nett, wenn mir hier jemand den entscheidenden Tipp geben würde.


    Anbei einige Configs:


    /etc/sysctl.conf (ohne kommentierte Zeilen)

    Code
    net.ipv4.ip_forward=1
    net.ipv6.conf.all.forwarding=1
    net.ipv6.conf.eth0.proxy_ndp=1


    /etc/docker/daemon.json

    Code
    {
            "ipv6": true,
            "fixed-cidr-v6": "2a03:4000:xxxx:xxxx:d0::/80"
    }


    /etc/ndppd.conf

    Statt auto habe ich hier auch schon static versucht, das hat allerdings keinen Unterschied gemacht.


    Code
    proxy eth0 {
            keepalive yes
            timeout 2000
    
            rule 2a03:4000:xxxx:xxxx:d1:abcd:abcd::/112 {
                    auto
            }
    
    }


    Routingtabelle

    ip -6 route

    Code
    root@srv:~# ip -6 route
    ::1 dev lo proto kernel metric 256 pref medium
    2a03:4000:xx:xxxx:d0::/80 dev docker0 proto kernel metric 256 pref medium
    2a03:4000:xx:xxxx:d1::/80 dev br-93e8ac56cbbf proto kernel metric 256 pref medium
    2a03:4000:xx:xxxx::/64 dev eth0 proto kernel metric 256 pref medium
    fe80::/64 dev eth0 proto kernel metric 256 pref medium
    fe80::/64 dev docker0 proto kernel metric 256 pref medium
    fe80::/64 dev br-93e8ac56cbbf proto kernel metric 256 pref medium
    default via fe80::1 dev eth0 metric 1024 onlink pref medium



    docker network inspect static


    Testlauf: Anlegen eines Docker-Containers und ping google.de

  • Das Problem ist nur, dass der Container nach einigen Minuten ohne Traffic nicht mehr erreichbar ist und die "Initialisierungsphase" erneut durchgeführt werden muss. Vermutlich gibt es in den Netcup-Routern einen Timeout, ab dem die dynamisch angelegte Route wieder gelöscht wird.

    Ja, gibt es siehe folgendes:

    Theoretisch ja, die Einträge in den Netcup Routern verlieren nach einer gewissen Zeit ihre Gültigkeit - Adressen die nicht genutzt werden tauchen in den Routing Tabellen nämlich nicht auf.


    Wenn du dir ein zusätzliches IPv6 Netz kaufst, ist das nicht so - diese Netze werden direkt geroutet.

  • Bekanntes Problem. Habe das Äquivalent in LXC. Netcup arbeitet angeblich an einem Fix.

    Ja, gibt es siehe folgendes:

    Dazu habe ich Netcup um Stellungnahme gebeten, jedoch weigert man sich beharrlich darauf einzugehen. Wirft alles in allem kein gutes Bild auf den Support und die Technik.


    Schöne Grüße

  • Ok. Vielen Dank. Dann hoffen wir mal das Beste. Es kann ja wohl nicht sein, dass man ein zusätzliches IPv6-Subnetz buchen muss, nur um IPv6 sinnvoll nutzen zu können.


    Ich habe gerade einmal für mehrere Stunden aus einem Container heraus alle 15 Sekunden lang einen Ping zu Google abgesetzt. Selbst hier trat ein Packet-Loss von 26% auf. Als Workaround funktioniert dauerhaftes Pingen also auch nicht.


    Was ich noch nicht verstehe: Warum bleibt dann die IPv6-Adresse auf eth0 dauerhaft erreichbar? Auch für diese Adresse werden ja Neighbor Advertisements benötigt, um erreichbar zu bleiben. Liegt das daran, dass "zufällig" hin und wieder mal v6-Traffic auftritt und die Adresse dadurch erreichbar bleibt? Oder werden die Routen für manche IPs doch statisch behalten?

  • Ich habe gerade einmal für mehrere Stunden aus einem Container heraus alle 15 Sekunden lang einen Ping zu Google abgesetzt. Selbst hier trat ein Packet-Loss von 26% auf. Als Workaround funktioniert dauerhaftes Pingen also auch nicht.

    Ich habe eine Hand voll IRC Bouncer von unterschiedlichen IPs in einen gemeinsamen Channel geworfen. Da kann man schön das Kommen und Gehen verfolgen...

    Die "Pingerei" setze ich selbst ein und mildert das Ganze etwas ab, ist aber kein Allheilmittel.


    Schöne Grüße

  • Das ist ja ein spannender Beitrag!

    Ich hatte das gleiche Problem, mir wurde gesagt ich bräuchte für IPV6 in Docker ein separates Subnetz. Das zahle ich nun brav seit drei Jahren. Gerade bin ich am überlegen, ob ich auf einen RS G9 wechseln soll, aber wenn ich das hier lese...