Netcup RS und Docker IPv6

cltrmx · 30. März 2020

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

Vielleicht kann mir ja jemand noch ein paar Denkanstöße geben oder sieht etwas, was ich schlicht übersehen habe! Vielen Dank .

[1] https://forum.netcup.de/admini…6-problem-auf-vps-system/

[2] https://forum.netcup.de/admini…2-docker-extern-nur-ipv6/

[3] https://forum.netcup.de/admini…ocker-container/?pageNo=1

[4] https://www.netcup-wiki.de/wik…dresse_konfigurieren#IPv6

Liebe Grüße
Max

H6G · 30. März 2020

Vermutlich klemmt da die Firewall ip6tables -S

cltrmx · 31. März 2020

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

christianr · 31. März 2020

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?

H6G · 31. März 2020

Zitat von christianr

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

Das Neighbor Discovery ist nicht so ganz ohne. Und er schreibt auch nirgens, dass dieses Problem etwas mit Netcup zu tun haben soll.

Zitat von christianr

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

Hast du seinen Beitrag gelesen, oder nur die Überschrift?

christianr · 31. März 2020

Doch das tut er

Zitat von cltrmx

... Dabei bin ich auf die Problematik mit Docker und IPv6 sowie Netcup gestoßen ...

Ich habe meinem Beitrag lange (!) vor deinem Beitrag mit einem Edit versehen, wo ich darauf hingewiesen habe, dass ich den Eintrag überlesen habe.

Jedoch frage ich mich was du mich hier so dumm von der Seite anmachst in beiden Dingen? Ist dir langweilig?

Denn Dein Beitrag mit der Vermutung es läge an der Firewall, kann durch lesen des ersten Posts ausgeschloßen werden....

H6G · 31. März 2020

Zitat von christianr

Ich habe meinem Beitrag lange (!) vor deinem Beitrag mit einem Edit versehen

Zwischen deinem Beitrag und meinem Beitrag liegen fünf Minuten. Wo willst du da lange vor meinem Beitrag einen Edit plaziert haben?

Meinst du ich drücke 60 Sekunden, bevor ich einen Antwort abschicke auf F5?

Zitat von christianr

Jedoch frage ich mich was du mich hier so dumm von der Seite anmachst in beiden Dingen? Ist dir langweilig?

Klar mache ich dich Dumm von der Seite an - dass du mit deinen Beiträgen zeigst, dass du keine Ahnung hast - lassen wir dabei mal außen vor.

Zitat von christianr

Denn Dein Beitrag mit der Vermutung es läge an der Firewall, kann durch lesen des ersten Posts ausgeschloßen werden....

Das musst du mir mal näher erklären. Ich kann da nur sehen, dass die Input und Output Chain einwandfrei funktionieren, es aber Probleme in der Forward Chain geben könnte.

Beschäftige dich bitte damit, wie Netcup IPv6 Netze routet und wie dort das Neighbor Discovery und IMCPv6 mit reinspielt.

Dann würdest du sehen, dass die Netze nicht einfach anliegen und deshalb bei Netcup VMs extra Einträge vorgenommen werden müssen.

christianr · 1. April 2020

Schau mal, wenn du nichts Sinnvolles beizutragen hast, lass es doch einfach sein. Vor Leuten wie Dir mache ich im echten Leben nur einen großen Bogen. Ich habe weder das Bedürfnis zu streiten, noch habe ich Zeit dazu.

Ich wollte cltrmx lediglich helfen und bin mir ziemlich sicher, dass es an einem Docker Konfigurationsfehler liegt.

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.

cltrmx · 1. April 2020

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?

Alles anzeigen

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!

H6G · 1. April 2020

Zitat von cltrmx

des Wireguard-Containers

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.

christianr · 1. April 2020

Dadurch, dass er Wireguard mit ipv4 bereits am Laufen hat, wird er dies wohl wissen und auch getan haben.

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

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.

cltrmx · 2. April 2020

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 · 2. April 2020

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.)

Netcup RS und Docker IPv6

Ähnliche Themen

Docker / Mailcow / Nginx-Proxy / letsencrypt

Tags