Beiträge von cltrmx

cltrmx

Vielen Dank für deinen Input!

Meine Domain war eine Zusatzdomain. Umgezogen habe ich sie dadurch, dass ich im CCP die Zugehörigkeit der Domain auf das neue Hosting-Paket geändert habe. Logischerweise konnte ich dort auch erst danach passende Mailboxen anlegen.

Das Merkwürdige ist an dieser Stelle, dass der MX-Record nicht nur auf den "neuen" Server zeigt und dass ein (eigener) Mailserver auch versucht, die Mail an der korrekten IP-Adresse (des neuen Webhosting-Pakets bzw. dessen Server) abzugeben. In den Logs stehen mittlerweile einige Zustellversuche an die korrekte IP, der Server lehnt die Mail nur immer wieder ab.

Dein Gedankengang klingt schlüssig, bis auf den Punkt, dass vom Testserver versucht wird, die korrekte IP anzusprechen.

Hmm, mal schauen, ob es morgen früh funktioniert. In einem anderen Thread hier im Forum war auch schon davon die Rede, dass eine Umstellung seitens Netcup ~24h dauern kann.

cltrmx

Hallo,

ich habe gestern Abend eine Domain von einem Webhosting-Paket (Netcup) zu einem Webhosting-Paket 1000 (Netcup) umgezogen und alle Mail-Konten anschließend erneut eingerichtet. (Zusätzlich habe ich die vorher vorhandenen Mails ins neue Konto übertragen via IMAP, was hier aber eigentlich irrelevant ist.)

Auf die Konten kann ich schon brav via IMAP zugreifen und auch Emails verschicken via SMTP funktioniert bereits. Was mich aber wundert ist, dass ich seit dem Umzug gestern Abend keine Email (mit dem neuen Webhosting) empfangen kann. Mir ist klar, dass die DNS-Änderungen weltweit bis zu 48h brauchen bis sie bekannt sind, allerdings sind diese Änderungen u.A. schon bei Netcup, Google und den Telekom-DNS-Servern angekommen.

Versuche ich eine Mail mit einem externen Mailserver zuzustellen, so erkennt dieser korrekterweise die neuen MX-Records, der Mailserver des (neuen) Webhostings nimmt die Mails aber noch nicht an:

454 4.7.1 <ziel-adresse-webhosting>: Relay access denied.

Gibt es da Erfahrungen, wie lange diese Änderung Netcup-intern braucht, bis der Server die Mails annimmt? Habe ich vielleicht einen Denk-/Konfigurationsfehler gemacht bzw. etwas vergessen oder ist das ein Fall für den Support?

Liebe Grüße

cltrmx

Zitat von ___

Wie von mir befürchtet, ist diese sinnlose und nervende 0-Euro-Rechnung für "Cloud vLAN Free" eine reguläre Rechnung.

Da spiele ich nicht mit. Die 86 Cent würden mir 40 Cent Buchungsgebühren kosten. Hoffentlich kann das riesige Guthaben mit der am 1.9. anstehenden Rechnung für den VPS 20 verrechnet werden.

Darf ich fragen bei welcher Bank für eine Buchung 40 Cent verlangt werden?

cltrmx

Zitat von whoami0501

Ich habe es vorhin bereits mit ihm getestet, wenn ich von seinem Server lade dann komme ich auf meine vollen 6 MB/s.

Das muss irgendwo zwischen seinem ISP und Anexia/Netcup klemmen.

Ah okay, ich wollte nur anbieten auch mal über eine Gigabit-Leitung zu testen.

cltrmx

Zitat von Stivi

Habe in Docker mal einen nginx Server mit http aufgesetzt, mit dem gleichen Ergebnis, nur maximal 5 MB/s, bin langsam echt überfragt woran es noch liegen kann...

Magst du mal eine Datei 'öffentlich' zur Verfügung stellen? Ich habe selbst einen RS500 und komme definitiv auf höhere Geschwindigkeiten als 5 MiB/s. Wenn du möchtest, kann ich den Download mal von einem extrernen Server aus versuchen (höhere Bandbreite).

cltrmx

Zitat von Woodz

Wenn ich während der Installation nach einem Servernamen gefragt werde, muss ich den Servernamen angeben, der mir von netcup vorgegeben wurde, oder kann ich einen x-beliebigen angeben? Letztlich wird der Servername (neben der IP) doch als Identifikationsmerkmal bei netcup genutzt, oder ist das egal? Ich würde halt gern einen anderen Namen verwenden, als diesen ellenlangen Defaultnamen aus Zahlen.

Es kann ein anderer Servername eingetragen werden.

cltrmx

Bei mir hat es <24h gedauert und ja, idR. bekommt man eine Mail nach der Freischaltung.

cltrmx

Konfiguration des Containers:

Code

[
    {
        "Id": "f80d8d2cb9883c826611e7243134071f56c87927a2c653de938d842ffa35356c",
        "Created": "2020-04-02T07:06:58.714716029Z",
        "Path": "/bin/bash",
        "Args": [],
        "State": {
            "Status": "running",
            "Running": true,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 29135,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2020-04-02T07:07:00.146770887Z",
            "FinishedAt": "0001-01-01T00:00:00Z"
        },
        "Image": "sha256:971452c943760ab769134f22db8d3381b09ea000a6c459fbfa3603bb99115f62",
        "ResolvConfPath": "/var/lib/docker/containers/f80d8d2cb9883c826611e7243134071f56c87927a2c653de938d842ffa35356c/resolv.conf",
        "HostnamePath": "/var/lib/docker/containers/f80d8d2cb9883c826611e7243134071f56c87927a2c653de938d842ffa35356c/hostname",
        "HostsPath": "/var/lib/docker/containers/f80d8d2cb9883c826611e7243134071f56c87927a2c653de938d842ffa35356c/hosts",
        "LogPath": "/var/lib/docker/containers/f80d8d2cb9883c826611e7243134071f56c87927a2c653de938d842ffa35356c/f80d8d2cb9883c826611e7243134071f56c87927a2c6$
        "Name": "/sharp_lalande",
        "RestartCount": 0,
        "Driver": "overlay2",
        "Platform": "linux",
        "MountLabel": "",
        "ProcessLabel": "",
        "AppArmorProfile": "docker-default",
        "ExecIDs": null,
        "HostConfig": {
            "Binds": null,
            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "json-file",
                "Config": {}
            },
            "NetworkMode": "default",
            "PortBindings": {},
            "RestartPolicy": {
                "Name": "no",
                "MaximumRetryCount": 0
            },
            "AutoRemove": false,
            "VolumeDriver": "",
            "VolumesFrom": null,
            "CapAdd": null,
            "CapDrop": null,
            "Capabilities": null,
            "Dns": [],
            "DnsOptions": [],
            "DnsSearch": [],
            "ExtraHosts": null,
            "GroupAdd": null,
            "IpcMode": "private",
            "Cgroup": "",
            "Links": null,
            "OomScoreAdj": 0,
            "PidMode": "",
            "Privileged": false,
            "PublishAllPorts": false,
            "ReadonlyRootfs": false,
            "SecurityOpt": null,
            "UTSMode": "",
            "UsernsMode": "",
            "ShmSize": 67108864,
            "Runtime": "runc",
            "ConsoleSize": [
                0,
                0
            ],
            "Isolation": "",
            "CpuShares": 0,
            "Memory": 0,
            "NanoCpus": 0,
            "CgroupParent": "",
            "BlkioWeight": 0,
            "BlkioWeightDevice": [],
            "BlkioDeviceReadBps": null,
            "BlkioDeviceWriteBps": null,
            "BlkioDeviceReadIOps": null,
            "BlkioDeviceWriteIOps": null,
            "CpuPeriod": 0,
            "CpuQuota": 0,
            "CpuRealtimePeriod": 0,
            "CpuRealtimeRuntime": 0,
            "CpusetCpus": "",
            "CpusetMems": "",
            "Devices": [],
            "DeviceCgroupRules": null,
            "DeviceRequests": null,
            "KernelMemory": 0,
            "KernelMemoryTCP": 0,
            "MemoryReservation": 0,
            "MemorySwap": 0,
            "MemorySwappiness": null,
            "OomKillDisable": false,
            "PidsLimit": null,
            "Ulimits": null,
            "CpuCount": 0,
            "CpuPercent": 0,
            "IOMaximumIOps": 0,
            "IOMaximumBandwidth": 0,
            "MaskedPaths": [
                "/proc/asound",
                "/proc/acpi",
                "/proc/kcore",
                "/proc/keys",
                "/proc/latency_stats",
                "/proc/timer_list",
                "/proc/timer_stats",
                "/proc/sched_debug",
                "/proc/scsi",
                "/sys/firmware"
            ],
            "ReadonlyPaths": [
                "/proc/bus",
                "/proc/fs",
                "/proc/irq",
                "/proc/sys",
                "/proc/sysrq-trigger"
            ]
        },
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/b65510b8d5ff503b2b03eb9ac02a430bc05c3b2271f1130f2fbec3173d7fc759-init/diff:/var/lib/docker/overlay2/bf$
                "MergedDir": "/var/lib/docker/overlay2/b65510b8d5ff503b2b03eb9ac02a430bc05c3b2271f1130f2fbec3173d7fc759/merged",
                "UpperDir": "/var/lib/docker/overlay2/b65510b8d5ff503b2b03eb9ac02a430bc05c3b2271f1130f2fbec3173d7fc759/diff",
                "WorkDir": "/var/lib/docker/overlay2/b65510b8d5ff503b2b03eb9ac02a430bc05c3b2271f1130f2fbec3173d7fc759/work"
            },
            "Name": "overlay2"
        },
        "Mounts": [],
        "Config": {
            "Hostname": "f80d8d2cb988",
            "Domainname": "",
            "User": "",
            "AttachStdin": true,
            "AttachStdout": true,
            "AttachStderr": true,
            "Tty": true,
            "OpenStdin": true,
            "StdinOnce": true,
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "/bin/bash"
            ],
            "Image": "debian:buster",
            "Volumes": null,
            "WorkingDir": "",
            "Entrypoint": null,
            "OnBuild": null,
            "Labels": {}
        },
        "NetworkSettings": {
            "Bridge": "",
            "SandboxID": "d0bb5b1da963e05aea7900a9427a9fb83489952cb60b6712346dbb209c99013c",
            "HairpinMode": false,
            "LinkLocalIPv6Address": "",
            "LinkLocalIPv6PrefixLen": 0,
            "Ports": {},
            "SandboxKey": "/var/run/docker/netns/d0bb5b1da963",
            "SecondaryIPAddresses": null,
            "SecondaryIPv6Addresses": null,
            "EndpointID": "fec353c04c20ad4639d382b42ff5f4159dd4515c908299ba73b45c8374753b1a",
            "Gateway": "172.17.0.1",
            "GlobalIPv6Address": "2a03:4000:6:XXXX:1:242:ac11:2",
            "GlobalIPv6PrefixLen": 80,
            "IPAddress": "172.17.0.2",
            "IPPrefixLen": 16,
            "IPv6Gateway": "2a03:4000:6:XXXX:1::1",
            "MacAddress": "02:42:ac:11:00:02",
            "Networks": {
                "bridge": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "7b9a87bc4be0e4b1548d425b978662235a84fba92acadb66c81e13cc3b9b00dd",
                    "EndpointID": "fec353c04c20ad4639d382b42ff5f4159dd4515c908299ba73b45c8374753b1a",
                    "Gateway": "172.17.0.1",
                    "IPAddress": "172.17.0.2",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "2a03:4000:6:XXXX:1::1",
                    "GlobalIPv6Address": "2a03:4000:6:XXXX:1:242:ac11:2",
                    "GlobalIPv6PrefixLen": 80,
                    "MacAddress": "02:42:ac:11:00:02",
                    "DriverOpts": null
                }
            }
        }
    }
]

Alles anzeigen

(Separater Post, weil zu lang.)

cltrmx

Zitat von H6G

Wireguard Container? Wireguard ist ein Kernelmodul, wie möchtest du das im Container nutzen? Oder willst du die Userspace Implementierung nutzen?

Du musst vorher Wireguard (je nach Kernelversion) erst auf dem Host installieren.

Es gibt Docker Container für Wireguard, die eine Verwendung erlauben, sofern der Host das entsprechende Kernelmodul geladen hat (z.B. dieser https://github.com/cmulk/wireguard-docker). Wie geschrieben, die IPv4-Variante funktioniert mit diesem Container bereits. Wie gesagt, um Wireguard und IPv6 kümmere ich mich aktuell noch gar nicht, weil IPv6 -> Internet aus keinem Container aktuell funktioniert. (Das ist nur das Ziel!)

Zitat

cltrmx kannst du vom container auch raus pingen? (was ja die eigentliche frage ist - du hast nur einen ping innerhalb des netzwerkes gepostet)

Genau das funktioniert noch nicht. Container -> Container funktioniert, Container -> Host funktioniert, Host -> Container funktioniert, Host -> Internet funktioniert aber Container -> Internet funktioniert nicht.

Code

root@8b2d80ebe680:/# ping6 google.com
PING google.com(fra15s29-in-x0e.1e100.net (2a00:1450:4001:806::200e)) 56 data bytes

Zitat

Die Frage wie das Docker Netzwerk und die Container konfiguriert wurden ist noch offen. Ist das Netzwerk als extern angelegt und bzw die/der Container? etc. pp.

Ich verwende zum Testen die default-Bridge von Docker (siehe hier: https://docs.docker.com/network). Die Container-Konfiguration müsste aus meinem letzten Post hervorgehen (zum Testen quasi keine, der Container wird mit der default-Bridge verbunden.)

Zitat

bridge: The default network driver. If you don’t specify a driver, this is the type of network you are creating. Bridge networks are usually used when your applications run in standalone containers that need to communicate.

Konfiguration des Netzwerks:

Code

root@watson:~# docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id": "7b9a87bc4be0e4b1548d425b978662235a84fba92acadb66c81e13cc3b9b00dd",
        "Created": "2020-03-30T11:14:39.271243378+02:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": true,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                },
                {
                    "Subnet": "2a03:4000:6:XXXX:1::/80",
                    "Gateway": "2a03:4000:6:XXXX:1::1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

Alles anzeigen

cltrmx

Hallo ihr zwei,

ich antworte einfach mal auf alle Fragen gemeinsam!

Zitat

Ich verstehe nicht ganz in wie weit das Problem etwas mit Netcup zu tun haben soll.

Wenn du eine ipv6 Adresse hast und darüber erreichbar bist, passt doch schonmal alles seitens Netcup.

Wenn du des Weiteren auch vom Server raus kommunizieren kannst, dann passt es mit den OS Einstellungen ebenfalls. Demnach muss es an deinen Docker Containern liegen und für mich wäre dann der nächste logische Schritt innerhalb eines Containers die ipv6 Kommunikation zu testen und dementsprechend zu handeln.

Hast du ipv6 im Docker Daemon aktiviert und ein ipv6 Netzwerk erstellt?

Edit: hast ja deinen Docker Eintrag gepostet hab ich erst jetzt gesehen. Daemon neugestartet danach?

Persönlich gehe ich eher davon aus, dass das ein Problem meiner Konfiguration ist! Seitens Netcup sollte alles funktionieren. Das Forum ist doch aber auch für allgemeine Anfragen gedacht oder habe ich das falsch verstanden?

Die Container können untereinander und auch mit dem Host über IPv6 kommunizieren, wie oben beschrieben. Ja, IPv6 ist im Docker Daemon aktiviert, es existiert ein IPv6 fähiges Netzwerk (default Bridge für Testzwecke) und ich habe den Daemon und den Host anschließend neu gestartet.

Zitat

Doch das tut er

Da gebe ich dir Recht. Ich habe in einem anderen Beitrag (oben in meinem ersten Post verlinkt) gelesen, dass bei Netcup das Neighbor Discovery ein klein wenig anders läuft, als man standardmäßig vermuten könnte. Deswegen dachte ich Abhilfe durch ndppd zu schaffen.

Zitat

Die Kommunikation des Host Systems ist laut cltrmx möglich und anhand von seiner Fragestellung war ich mir sicher, dass er nicht manuell in den iptables Änderungen vorgenommen hat und Docker schreibt diese je nach Konfiguration selbst (wie man bei den ipv4 sehen kann).

Insofern an cltrmx die Frage:

Wie hast du das ipv6 Netzwerk von Docker erstellt und wie sind deine Container konfiguriert.

Korrekt, ich habe keine Änderungen in den iptables per Hand vorgenommen. Docker scheint bei mir keinerlei Einträge für IPv6 geschrieben zu haben. Wie kann ich dies denn aktivieren?

Das IPv6-Netzwerk, welches ich zum Testen verwende, habe ich nicht per Hand erstellt (es ist das default Bridge Netzwerk). Untereinander können die Container kommunizieren. Ich habe noch keine Container speziell konfiguriert - Zum Testen habe ich mir z.B. einen Debian Container erstellt.

Code

root@host:~# docker run -it debian:buster /bin/bash                                                                                                       
root@be5002334b7e:/# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000                                                                 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
88: eth0@if89: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default                                                              
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a03:4000:6:XXXX:1:242:ac11:2/80 scope global nodad
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:2/64 scope link
       valid_lft forever preferred_lft forever
root@be5002334b7e:/# ping 2a03:4000:6:XXXX:1:242:ac11:3 # IPv6 eines anderen Containers
PING 2a03:4000:6:XXXX:1:242:ac11:3(2a03:4000:6:XXXX:1:242:ac11:3) 56 data bytes
64 bytes from 2a03:4000:6:XXXX:1:242:ac11:3: icmp_seq=1 ttl=64 time=0.150 ms
64 bytes from 2a03:4000:6:XXXX:1:242:ac11:3: icmp_seq=2 ttl=64 time=0.105 ms
64 bytes from 2a03:4000:6:XXXX:1:242:ac11:3: icmp_seq=3 ttl=64 time=0.238 ms
64 bytes from 2a03:4000:6:XXXX:1:242:ac11:3: icmp_seq=4 ttl=64 time=0.118 ms
^C
--- 2a03:4000:6:XXXX:1:242:ac11:3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 72ms
rtt min/avg/max/mdev = 0.105/0.152/0.238/0.054 ms
root@be5002334b7e:/#

Alles anzeigen

Bevor ich mich an die spezielle Konfiguration des Wireguard-Containers mache, wollte ich eben erst einen möglichst sinnvollen Container haben, mit dem ich über IPv6 mit externen Hosts kommunizieren kann. (Der ursprüngliche Sinn meines Vorhabens war es ja, Wireguard mit IPv6 zu ermöglichen.)

Danke euch beiden für eure Hilfe, H6G und christianr!

cltrmx

Zitat von H6G

Vermutlich klemmt da die Firewall ip6tables -S

Die Ausgabe lautet:

Code

root@host:~# ip6tables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Bei der IPv4 Variante von iptables sind deutlich mehr Einträge spezifisch für Docker enthalten:

Code

root@host:~# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o br-282a787ff486 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-282a787ff486 -j DOCKER
-A FORWARD -i br-282a787ff486 ! -o br-282a787ff486 -j ACCEPT
-A FORWARD -i br-282a787ff486 -o br-282a787ff486 -j ACCEPT
-A FORWARD -o br-0f04f4d1e655 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-0f04f4d1e655 -j DOCKER
-A FORWARD -i br-0f04f4d1e655 ! -o br-0f04f4d1e655 -j ACCEPT
-A FORWARD -i br-0f04f4d1e655 -o br-0f04f4d1e655 -j ACCEPT
-A FORWARD -o br-f191e0cef97f -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-f191e0cef97f -j DOCKER
-A FORWARD -i br-f191e0cef97f ! -o br-f191e0cef97f -j ACCEPT
-A FORWARD -i br-f191e0cef97f -o br-f191e0cef97f -j ACCEPT
-A FORWARD -o br-ce46b9800f18 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-ce46b9800f18 -j DOCKER
-A FORWARD -i br-ce46b9800f18 ! -o br-ce46b9800f18 -j ACCEPT
-A FORWARD -i br-ce46b9800f18 -o br-ce46b9800f18 -j ACCEPT
-A FORWARD -o br-bc85515a51b0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-bc85515a51b0 -j DOCKER
-A FORWARD -i br-bc85515a51b0 ! -o br-bc85515a51b0 -j ACCEPT
-A FORWARD -i br-bc85515a51b0 -o br-bc85515a51b0 -j ACCEPT
-A FORWARD -o br-38e988deab59 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-38e988deab59 -j DOCKER
-A FORWARD -i br-38e988deab59 ! -o br-38e988deab59 -j ACCEPT
-A FORWARD -i br-38e988deab59 -o br-38e988deab59 -j ACCEPT
-A DOCKER -d 172.26.0.2/32 ! -i br-282a787ff486 -o br-282a787ff486 -p udp -m udp --dport 51820 -j ACCEPT
-A DOCKER -d 172.21.0.4/32 ! -i br-f191e0cef97f -o br-f191e0cef97f -p tcp -m tcp --dport 443 -j ACCEPT
-A DOCKER -d 172.21.0.4/32 ! -i br-f191e0cef97f -o br-f191e0cef97f -p tcp -m tcp --dport 80 -j ACCEPT
-A DOCKER -d 172.20.0.3/32 ! -i br-0f04f4d1e655 -o br-0f04f4d1e655 -p udp -m udp --dport 10000 -j ACCEPT
-A DOCKER -d 172.20.0.3/32 ! -i br-0f04f4d1e655 -o br-0f04f4d1e655 -p tcp -m tcp --dport 4443 -j ACCEPT
-A DOCKER -d 172.21.0.7/32 ! -i br-f191e0cef97f -o br-f191e0cef97f -p udp -m udp --dport 1194 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-282a787ff486 ! -o br-282a787ff486 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-0f04f4d1e655 ! -o br-0f04f4d1e655 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-f191e0cef97f ! -o br-f191e0cef97f -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-ce46b9800f18 ! -o br-ce46b9800f18 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-bc85515a51b0 ! -o br-bc85515a51b0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-38e988deab59 ! -o br-38e988deab59 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-282a787ff486 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-0f04f4d1e655 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-f191e0cef97f -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-ce46b9800f18 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-bc85515a51b0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-38e988deab59 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN

Alles anzeigen

cltrmx

Hallo zusammen,

ich habe auf meinem RS 500 SAS G7 bereits mehrere Docker-Container laufen, welche wunderbar über IPv4 und IPv6 von außerhalb erreichbar sind, wenn die entsprechenden Ports auf den Host gemappt wurden. Leider funktioniert es noch nicht korrekt, dass Container eine IPv6-Adresse zugewiesen bekommen und über diese auch mit externen Hosts kommunizieren können.

Nun möchte ich innerhalb eines Containers Wireguard laufen lassen, wobei ich gerne auch IPv6 verwenden möchte. (Wireguard mit IPv4 funktioniert schon problemlos). Dabei bin ich auf die Problematik mit Docker und IPv6 sowie Netcup gestoßen und habe mich bereits durch diverse Threads gelesen [1],[2],[3]. Auf dem Root-Server habe ich IPv6 eingerichtet anhand des Wiki-Eintrags [4] und kann den Server von außerhalb erreichen, als auch Verbindungen vom Server zu z.B. Google aufbauen. Weiterhin habe ich nach [3] noch ndppd installiert, da dies in einem anderen Thread empfohlen wurde.

Meine Konfiguration sieht bisher so aus:
/etc/network/interfaces

Code

# /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens3

# IPv4 Netcup static
iface ens3 inet static
        address 37.120.178.XXX
        gateway 37.120.176.1
        netmask 255.255.252.0
        dns-nameservers 46.38.225.230 46.38.252.230 

# IPv6 Netcup static
iface ens3 inet6 static
        address 2a03:4000:6:XXXX::1
        netmask 64
        gateway fe80::1
        dns-nameservers 2a03:4000:0:1::e1e6 2a03:4000:8000::fce6

Alles anzeigen

/etc/docker/daemon.json

Code

{
  "ipv6": true,
  "fixed-cidr-v6": "2a03:4000:6:XXXX:1::/80"
}

/etc/ndppd.conf (Alternative Konfiguration als Kommentar noch enthalten.)

Code

#proxy ens3 {
#       rule 2a03:4000:6:XXXX:1::/80 {
#               auto
#       }
#}

route-ttl 30000
proxy ens3 {
        router yes
        timeout 500
        ttl 30000
        rule 2a03:4000:6:XXXX::1/64 {
                static
        }
}

Alles anzeigen

/etc/sysctl.conf

Code

net.ipv4.ip_forward = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1

# Netcup wiki: https://www.netcup-wiki.de/wiki/Zus%C3%A4tzliche_IP_Adresse_konfigurieren#IPv6
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.ens3.accept_ra = 0
net.ipv6.conf.ens3.autoconf = 0

Alles anzeigen

Der aktuelle Status ist so, dass jeder neu erzeugte Docker-Container eine IPv6-Adresse aus dem Adressbereich zugeordnet bekommt, allerdings nicht zu externen Hosts pingen kann. Pingen zwischen Root-Server und Containern funkioniert allerdings:

Code

root@4b78b4347d3e:/# ping6 <RS> # Container zu Root-Server
PING <RS>(<RS> (2a03:4000:6:XXXX::1)) 56 data bytes
64 bytes from <RS> (2a03:4000:6:XXXX::1): icmp_seq=1 ttl=64 time=0.186 ms
64 bytes from <RS> (2a03:4000:6:XXXX::1): icmp_seq=2 ttl=64 time=0.082 ms
64 bytes from <RS> (2a03:4000:6:XXXX::1): icmp_seq=3 ttl=64 time=0.106 ms
64 bytes from <RS> (2a03:4000:6:XXXX::1): icmp_seq=4 ttl=64 time=0.079 ms
^C
--- <RS> ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 45ms
rtt min/avg/max/mdev = 0.079/0.113/0.186/0.043 ms

Code

root@watson:~# ping6 2a03:4000:6:XXXX:1:242:ac11:2 # Root-Server zu Container
PING 2a03:4000:6:XXXX:1:242:ac11:2(2a03:4000:6:XXXX:1:242:ac11:2) 56 data bytes
64 bytes from 2a03:4000:6:XXXX:1:242:ac11:2: icmp_seq=1 ttl=64 time=0.125 ms
64 bytes from 2a03:4000:6:XXXX:1:242:ac11:2: icmp_seq=2 ttl=64 time=0.167 ms
64 bytes from 2a03:4000:6:XXXX:1:242:ac11:2: icmp_seq=3 ttl=64 time=0.262 ms
64 bytes from 2a03:4000:6:XXXX:1:242:ac11:2: icmp_seq=4 ttl=64 time=0.123 ms
^C
--- 2a03:4000:6:XXXX:1:242:ac11:2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 76ms
rtt min/avg/max/mdev = 0.123/0.169/0.262/0.057 ms