Docker Netzwerk

[rednag]

Ich habe die letzte Zeit etwas mit Docker gespielt und einiges ausprobiert.
Nun ist mir aber ein Detail aufgefallen welches mich vorher nicht beschäftigt hat.
Und zwar geht es um die Netzgröße. Die UGRENN erstellt für einzelne Container ein /16 Netz(!) im Bereich 172.x.x.x
Da passen 65534 Clients rein!! Wenn die Netze bei einer wachsenden Anzahl von Containern nicht ausreichen wird bei 192.x.x.x weitergemacht. Das ist pure Verschwendung und eine potenzielle Störquelle da viele Fritz!Boxen in dem Bereich agieren.

Wie einem Thread entnommen kann man die verwendeten Netze in

/etc/docker/daemon.json

definieren.

"bip": "172.17.0.1/24",
 "default-address-pools": [
    {
      "base": "172.30.0.0/16",
      "size": 24
    },
    {
      "base": "172.31.0.0/16",
      "size": 24
    }
  ],

Die Datei gibt es bei UGREEN zwar, ist aber nicht sehr aussagekräftig.



Und der Versuch den Bereich dort nach dem Beispiel manuell zu vergeben scheitert damit, daß Docker nicht mehr startet.
Hier scheint UGREEN von den Standards abzuweichen. Irgendwo müssen die zu verwendeten Netze ja im System vorgegeben sein. Ich denke nicht, daß die ausgewürfelt werden.


Hat jemand eine UGREEN im Besitz, nutzt Docker und kann das Verhalten verifizieren?
Es wäre interessant das Thema weiterzuverfolgen.

 

[*alx*]

Poste doch mal deine Datei und die Fehlermeldung. UGreen wird nicht Docker anpassen. Docker hat ja auch Default Werte und die stehen dann nicht in der config. Wahrscheinlich hast du da eher was fehlerhaftes drin...

 

[rednag]

Der Inhalt der Datei ist oben rechts zu sehen.... data-root
Und die Fehlermeldung war recht allgemein gehalten ohne einen spezifischen Fehler zu melden. Docker could not start....
Hast du eine UGREEN und Docker am laufen? Falls ja, wie sieht das bei dir mit den Netzen aus?

 

[Fusion]

Fritzboxen nutzen aber 192.168.178.0/24. Da ist viel Platz, selbst mit den "verschwenderischen" /16 oder /20 Netzen.
Man kann auch einfach selber Netze definieren und diese in Containern oder Stacks verwenden und eben /20 oder /24 Netze wählen.
Dabei ist man auch nicht eingeschränkt auf die Standardmäßig verwendeten 172.17.0.0/16 bis 172.28.0.0/16. Kann auch 10.0.0.0/8 oder sonst wo in den privaten Ranges unterwegs sein, solange sich nichts überschneidet.

Gibt also viel mehr mögliche Netze als man jemals Container auf einem Host laufen lassen könnte.

 

[rednag]

Meine erste Idee war, daß ich für jeden Container manuell ein Netz vorgebe, bin mir aber nicht sicher, wie ich die Container nachträglich in das Netz bekomme. Ich finde die automatische Zuweisung von /16 aber nicht richtig. Es wäre interessant in welcher Konfigurationsdatei dies definiert wird.

 

[*alx*]

In dem Bild fehlt aber dein kompletter Inhalt für die Netze? Und falls der Codeblock dein Inhalt war, dann ist klar dass es nicht geht. Ist kein gültiges JSON.

Hast du eine UGREEN und Docker am laufen? Falls ja, wie sieht das bei dir mit den Netzen aus?

Ich habe keine UGreen, aber die werden auch Docker nicht anpassen. Wie schön geschriebene sind die Netze die dir falsch vorkommen defaults von Docker selber. Und defaults muss man nicht konfigurieren.

Ohne richtigen Inhalt was nicht gehen soll bin ich hier raus. Keine Lust zu raten was du falsch gemacht haben könntest. Auf meiner Debian VM funktioniert das super zu konfigurieren und das wird bei UGreen genau so gehen.

 

[blurrrr]

und das wird bei UGreen genau so gehen.

Mit der Aussage wäre jetzt eher vorsichtig, wenn man nicht weiss, wie UGREEN das Them angeht Kommt ja nicht selten vor, dass NAS-Hersteller irgendwelche grundlegenden Dinge nach ihren Wünschen umstricken.

Wie schön geschriebene sind die Netze die dir falsch vorkommen defaults von Docker selber. Und defaults muss man nicht konfigurieren.

Als "default" finde ich das persönlich aber mal sehr deplatziert... Lasst uns mal ein bisschen "Kopfrechnen":

172.16.0.0/12 ist die Netzgrundlage (172.16.0.0-172.31.255.255). Nun werden aus diesem Netz ständig neue /16er Netze gebildet (x.x.y.y), somit kann man 16 Netze bilden: 172.16.0.0/16, 172.17.0.0/16, 172.18.0.0/16, ..... 172.31.0.0/16. Das ist jetzt nicht grade "viel". Sind die 16 Netze vorhanden (vermutlich mit "pro Netz" 1-5 Container...), ist der o.g. Adressbereich komplett ausgeschöpft.

So wie es aussieht, geht es dann in einen anderen privaten Bereich über, den die meisten Zuhause auch nutzen (192.168.0.0/16). Auch hier wird wieder um 4 Bit reduziert bei der Bildung der Subnetze. Wohin das nun führt, haben wir ja oben schon gesehen: Es sind auch hier genau 16 Netze möglich (/20 dann eben)... 192.168.0.0/20, 192.168.16.0/20, 192.168.32.0/20, ......192.168.240.0/20.

Das "Problem" was sich dadurch nun ergeben kann sind die lokalen Bridges mit ihren IP-Adressen. Dazu mal ein kleines Beispiel, welches grade bei der Nutzung von Docker auf einem NAS eine grössere Rolle spielen könnte:

VPN-Client <-> VPN-Netz (192.168.50.0/24) <-> Router/Firewall <-> LAN-Netz (192.168.100.0/24) <-> NAS (192.168.100.100) <-> Docker-Netzwerke

Das Problem ist hier, dass nach einer gewissen Anzahl Netze keinen Zugriff mehr auf das NAS via VPN bekommt, da es zu einer Netzüberschneidung kommt. Bis man den VPN-Netz-Bereich erreicht, dauert es 20 Docker-Netze:

1. Bereich: 172.16.0.0/12 = 16 Netze
2. Bereich: 192.168.0.0/16 = 16 Netze

16 (172er)
+ 1 (192.168.0.0)
+ 1 (192.168.16.0)
+ 1 (192.168.32.0)
+ 1 (192.168.48(-63).0)
------------
20 Netze

Sprich mit dem 20. Netz überschneidet sich ein Docker-Netzwerk (192.168.48.0/20) mit dem VPN-Netzwerk (192.168.50.0/24) bzw. ist das VPN-Netzwerk konkreter im Netz 192.168.48.0/20 "enthalten". Anfragen gehen aus dem VPN-Netz bis zum Docker-Host, die Antwort wird aber den Rückweg nicht finden. Der Docker-Host (oder NAS) "kennt" jetzt dummerweise besagtes Netzwerk und schickt die Antwort nicht mehr zurück zu seinem Standard-Gateway (Firewall), welches den korrekten Weg ins VPN-Netz kennen würde, sondern wird es über seine eigene Schnittstelle senden, wo die entsprechende Netzdefinition passt.

Ursache für diese ganze Problematik ist (meiner Meinung nach) dieses völlig verschwenderische Gehabe mit den Netzgrößen. IPv6... eine Sache... bei IPv4 sind derlei Netzgrößen einfach völlig überzogen, wenn man mal bedenkt, wieviele Hosts in so ein Netz passen, auch hier mal kurz ein bisschen aufgelistet - grundsätzlich kann man aber immer sagen: "-3" (Netz-ID, Broadcast, Gateway)...:

/24 = 256
/23 = 512
/22 = 1024
/21 = 2048
/20 = 4096

Also nur mal um das klarzustellen: Es werden also Netze erzeugt für "einen"(!) Container, wobei die erzeugten Netze so groß sind, dass über 4000 Container hineinpassen würden? Bei den 16er Definitionen (172er) ist es sogar noch schlimmer. Das ist schon ein wenig so, als würde man Seecontainer (der Vergleich muss nun schon sein ) dafür nutzen, um seine Dinge abzulegen: ein Seecontainer für den Schlüsselbund, ein Seecontainer für die Brieftasche, ein Seecontainer für die Kaffeetasse und natürlich auch ein Seecontainer für das Handy, usw. usw. usw. Macht irgendwie jetzt nicht allzuviel Sinn, oder wieviele Seecontainer habt ihr so bei euch im Garten stehen?

Unterhaltsam hingegen finde ich jedoch folgendes: https://docs.docker.com/engine/network/#subnet-allocation (also ist meine o.g. Annahme ist ganz korrekt bzgl. der genutzen Netz-Bereiche). Dort ist einmal die Rede davon dem "Standard"-Verhalten bzgl. der Netzbildung, aber eben auch (und das finde ich jetzt mal garnicht so unwesentlich) von der Anpassung dieser Netzbereiche und dort geht man bei einem übergeordneten /16er Netz bei der Bildung von Subnetzen auf /24er und das finde ich dann wesentlich sinnvoller (und kommt somit auch auf 256x24er Netze).

Mich würde ja schon interessieren, warum standardmässig mit solchen völlig überdimensionierten Netzen um sich geworfen wird (was meiner Meinung nach völlig unnötig und eher hinderlich ist)

Und falls der Codeblock dein Inhalt war, dann ist klar dass es nicht geht. Ist kein gültiges JSON.

Guckste mal hier: https://docs.docker.com/engine/daemon/#daemon-data-directory, da steht es exakt so (und ist default bei UGREEN so konfiguriert)

 

[*alx*]

Mit der Aussage wäre jetzt eher vorsichtig, wenn man nicht weiss, wie UGREEN das Them angeht Kommt ja nicht selten vor, dass NAS-Hersteller irgendwelche grundlegenden Dinge nach ihren Wünschen umstricken.

Das mag sein, aber ich glaube nicht, dass die sowas wie Docker groß anfassen würden und sich eventuell Probleme einhandeln, dass Container nicht richtig laufen
Da wär der Support Aufwand glaub ich einfach zu hoch.

Als "default" finde ich das persönlich aber mal sehr deplatziert... Lasst uns mal ein bisschen "Kopfrechnen":

Mag sein, aber wie du ja in der Doku gesehen hast, ist es leider so. Ich hab auf meinem Dockerhost deshalb auch Probleme gehabt, dass er kein freies Netz mehr hatte und nicht starten konnte. Deshalb habe ich bei mir folgende Config drin.

{
  "default-address-pools":[
    {"base":"172.30.0.0/16","size":28},
    {"base":"172.31.0.0/16","size":28},
    {"base":"10.10.0.0/16","size":28}
  ],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "1"
  }
}

Guckste mal hier: https://docs.docker.com/engine/daemon/#daemon-data-directory, da steht es exakt so (und ist default bei UGREEN so konfiguriert)

Ja, aber da sind keine IP Bereiche drin. Das ist auch gültiges JSON. Damit funktioniert ja Docker, aber die Netze sind nicht geändert. Mir ging es um den Codeblock

"bip": "172.17.0.1/24",
"default-address-pools": [
{ "base": "172.30.0.0/16", "size": 24 },
{ "base": "172.31.0.0/16", "size": 24 }
]

Das ist kein gültiges JSON. Deshalb wollte ich den kompletten Inhalt der Datei sehen, den er sich erstellt hat und auch die Fehlermeldung. Ansonsten kann man ja nur raten.