uGreen - UGOS - Docker Netzwerk Probleme

[nitje]

uGreen - UGOS - Docker Netzwerk Probleme

Ich hatte zum Beispiel Problem das mein UniFi L2TP VPN auf das NAS2 gekommen ist und auf NAS1 nicht(nicht gleich erst später).
Außerdem gab es Probleme mit einigen Containern die Lokal angesprochen wurden über Nginx-Proxy-Manager.

Kurz erklärt und nur als Beispiel, ich habe Domain "britney.DuckDNS.org" dort ist "192.168.1.x" hinterlegt, also intern von meinem Netzwerk der NPM hat diese als Wildcard "*.britney.DuckDNS.org" hinterlegt. Dadurch kann ich intern auf "pairdrop.britney.DuckDNS.org" Container von PairDrop aufrufen.
Jetzt gingen einige manche eher weniger aber was großes Problem war über L2TP VPN meisstens nicht (oftmals liegt es aber auch am Container selber).

Dadurch wurde "192.168.200.2 dev br-aceda2577286 src 192.168.192.1" erstellt und meine NAS-IP ist nicht "192.168.192.1" und ich habe halt Firewall Regeln und Gateway Schutz die nicht zugelassen werden.

In der UGOS Docker App auf Netzwerk gehen und dort darf nur bei macvlan als Beispiel "192.168.1.x" stehen und die Container bei "172.20.x.x" wenn jetzt Netzwerke auftauchen wie "192.168.192.1" müssen die Container/Projekte gelöscht werden und der unten stehende fix erst angewendet werden und anschließend neu Erstellt werde.




In UGOS AppStore Docker Deaktivieren und wenn alles fertig ist wieder Aktvieren.

Du musst deine vorhandene daemon.json nur ergänzen, nicht ersetzen. data-root und containerd-snapshotter bleiben unverändert.
so setzen:
{
  "data-root": "/volume1/@docker",
  "features": {
    "containerd-snapshotter": false
  },
  "default-address-pools": [
    {
      "base": "172.20.0.0/14",
      "size": 24
    }
  ]
}

Damit darf Docker für automatisch angelegte Netzwerke nur noch aus 172.20.0.0/14 einzelne /24-Netze vergeben, also beispielsweise:
172.20.0.0/24
172.20.1.0/24
172.20.2.0/24
...
172.23.255.0/24

192.168.x.x wird dann nicht mehr automatisch für neue Docker-Netze benutzt. Docker unterstützt default-address-pools genau für solche Fälle, um Kollisionen mit vorhandenen LAN-/VPN-Netzen zu vermeiden.
Wichtig: Das ändert bestehende Docker-Netze nicht. Es gilt erst, wenn ein neues Netzwerk erzeugt wird. Falls noch problematische 192.168.x.x-Docker-Netze existieren, müssten diese anschließend gezielt gelöscht und von Compose neu erzeugt werden.
Vor dem Neustart kannst du die JSON-Datei prüfen:
cat /etc/docker/daemon.json

Sehr sinnvoll:
dockerd --validate --config-file=/etc/docker/daemon.json

Bei korrekter Datei sollte sinngemäß kommen:
configuration OK

Dann Docker neu starten. Auf normalem Debian:
sudo systemctl restart docker

Danach zum Test ein neues Netzwerk erzeugen:
docker network create test-netz

und kontrollieren:
docker network inspect test-netz \
  --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'

Es sollte dann beispielsweise kommen:
172.20.0.0/24

Anschließend:
docker network rm test-netz

Eine Sache würde ich aber vorher auf deinem NAS prüfen: ob 172.20.0.0/14 bei dir schon anderweitig verwendet wird:
ip route | grep -E '172\.2[0-3]\.'

und:
docker network inspect $(docker network ls -q) \
  --format '{{.Name}} {{range .IPAM.Config}}{{.Subnet}} {{end}}'

Falls dort bereits viele 172.20–172.23-Netze vorhanden sind, können wir stattdessen einen anderen konfliktfreien privaten Bereich fest reservieren. Das wäre besser, als jetzt eine neue Überschneidung einzubauen.

Hinweis in meinen Test habe ich 172.17.x.x verwendet aber es wurde 172.16.x.x genutzt was mir egal ist solange nicht wieder so ein mix ist, es waren mehr als ein 192.x.x.x Bereich, was Natürchlich auch durch einfaches Kopieren und Einfügen bei Compose dateien passieren kann wenn man nicht liest was drin steht.