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)
/etc/docker/daemon.json
/etc/ndppd.conf
Statt auto habe ich hier auch schon static versucht, das hat allerdings keinen Unterschied gemacht.
Routingtabelle
ip -6 route
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
"Name": "static",
"Id": "93e8ac56cbbfc8907db3782f.....",
"Created": "2020-05-03T14:25:01.964894767+02:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": true,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.31.1.0/24",
"Gateway": "172.31.1.1"
},
{
"Subnet": "2a03:4000:xx:xxxx:d1::/80",
"Gateway": "2a03:4000:xx:xxxx:d1::1"
}
]
},
[...]
Display More
Testlauf: Anlegen eines Docker-Containers und ping google.de
root@srv3:~# docker run --rm --net=static --ip6 "2a03:4000:xx:xxxx:d1:abcd:abcd:20" -it alpine sh
/ # ping -i 0.5 google.de
PING google.de (2a00:1450:4001:80b::2003): 56 data bytes
64 bytes from 2a00:1450:4001:80b::2003: seq=29 ttl=56 time=929.237 ms
64 bytes from 2a00:1450:4001:80b::2003: seq=31 ttl=56 time=3.971 ms
64 bytes from 2a00:1450:4001:80b::2003: seq=32 ttl=56 time=3.966 ms
64 bytes from 2a00:1450:4001:80b::2003: seq=33 ttl=56 time=3.883 ms
^C
--- google.de ping statistics ---
34 packets transmitted, 4 packets received, 88% packet loss
round-trip min/avg/max = 3.883/235.264/929.237 ms
// Ab jetzt ist der Server auch von außen erreichbar
Display More