angle-uparrow-clockwisearrow-counterclockwisearrow-down-uparrow-leftatcalendarcard-listchatcheckenvelopefolderhouseinfo-circlepencilpeoplepersonperson-fillperson-plusphoneplusquestion-circlesearchtagtrashx

Docker Container plötzlich mit 192.168.0.0.0/16 statt 172.17.0.0.0/16: verlorene Dienste

Meine Docker -Anwendungen konnten plötzlich keine E-Mails über den Host Postfix MTA senden. Ich habe dies behoben, indem ich einen Docker Standard-Adresspool angegeben habe, aber es ist besser, dies vor der Bereitstellung zu tun.

27 November 2019
In Docker
post main image
https://unsplash.com/@mmintel

Ich habe einen ISPConfig Server mit Docker Anwendungen. Sie verwenden den Host Postfix Mail Transfer Agent (MTA), um E-Mails an die Außenwelt zuzustellen. Vor der Nutzung der Sende-Mail-Funktion habe ich geprüft, ob Postfix erreichbar ist. Das funktioniert einwandfrei. Aber plötzlich wurde keine Post verschickt. Die Protokolldatei enthielt Fehlermeldungen wie:

2019-11-26 17:31:56,758 ERROR MailMessage - send_mail: self.error_message = sending message, e = {'joe@example.com': (554, b'5.7.1 <joe@example.com>: Relay access denied')}
2019-11-26 17:31:56,759 ERROR MailSend - send during send, errors = send - sending message, e = {'joe@example.com': (554, b'5.7.1 <joe@example.com>: Relay access denied')}
2019-11-26 17:31:56,759 ERROR AddonContactForm - send_contact_form: mail_sender.get_errors() = send - sending message, e = {'joe@example.com': (554, b'5.7.1 <joe@example.com>: Relay access denied')}

Relaiszugriff verweigert? Warum? Dann erinnerte ich mich daran, dass Postfix eine mynetworks Einstellung in der Datei hat:

mynetworks  = 127.0.0.0/8 [::1]/128  172.16.0.0/12

Dies führte mich zu den IP-Adressen, die Docker den Containern zugewiesen hat:

systemctl status docker

mit Ergebnis:

● docker.service -  Docker  Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-10-16 21:26:07 CEST; 1 months 11 days ago
     Docs: https://docs.docker.com
 Main PID: 765 (dockerd)
    Tasks: 28
   Memory: 53.7M
       CPU: 39min 54.387s
   CGroup: /system.slice/docker.service
           ├─  765 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
           ├─ 9784 /usr/bin/docker-proxy  -proto tcp -host-ip 0.0.0.0 -host-port 8001 -container-ip 192.168.32.2 -container-port 8001
           └─18316 /usr/bin/docker-proxy  -proto tcp -host-ip 0.0.0.0 -host-port 8000 -container-ip 192.168.176.2 -container-port 8000

Die Docker -Container verwendeten plötzlich das 192-Subnetz anstelle des 172-Subnetzes. Ich verstehe (immer noch) nicht, warum das passiert ist, aber es musste gelöst werden. Nach einiger Suche habe ich die Lösung für das Problem gefunden. Vom untenstehenden Link:

..... haben wir folgende Netzwerkreichweite für Brückennetze.
"172.17.0.0/16", "172.18.0.0/16", "172.19.0.0/16", "172.20.0.0/14", "172.24.0.0/14" "172.28.0.0/14", "192.168.0.0/16"
Wenn wir ein Netzwerk erstellen, prüfen wir, ob das Netzwerk überlappend ist, nur innerhalb von im Docker erstellten Netzwerken. Wir haben die Unterstützung des Standard-Adresspools für das Bridge-Netzwerk hinzugefügt. Sie können es über die Datei daemon.jason oder Input-Param konfigurieren, während Sie Docker Daemon starten. Auf diese Weise können Sie ein Subnetz auswählen, das dockerD erstellen soll ( Standardgateway oder Netzwerk).

Ich habe die Standard-Adresspools für meine Docker -Netzwerke beim Erstellen der Datei angegeben (sie war nicht vorhanden):

/etc/docker/daemon.json

mit dem Inhalt:

{
	"default-address-pools":
	[
		{"base":"172.17.0.0/16","size":24}
	]
}

Dann habe ich Docker neu gestartet:

systemctl restart docker

Die Container hatten noch 192 Subnetz-IP-Adressen. Dann habe ich es für die Docker Anwendungen getan:

docker-compose  .... down
docker-compose  .... up -d

Jetzt hatten sie wieder 172 Subnetz-IP-Adressen und die Mail kam wieder raus! Um sicher zu gehen, habe ich auch den Server neu gestartet und war froh zu sehen, dass alles in Ordnung war.

Einige Befehle zum Testen

Mit dieser Methode, siehe auch Link unten, können Sie überprüfen, ob das richtige Netzwerk erstellt wurde:

docker network create foo
docker network inspect foo | grep Subnet

Einige andere Befehle, die ich im Prozess verwendet habe:

route -n

docker inspect <container> 

docker network ls

docker network inspect <network>

Zusammenfassung

Ich weiß immer noch nicht, was dieses Problem verursacht hat, aber glücklicherweise können Sie ein Subnetz für das Standardnetzwerk angeben. Dies sollte bei der Verwendung von Docker unbedingt stärker betont werden! Sie können auch Standard-Subnetze in docker-compose angeben, aber ich habe dies nicht getestet. Jedenfalls gelöst.

Links / Impressum

Allow user to specify default address pools for docker networks #29376
https://github.com/moby/moby/pull/29376

Configuring Docker to not use the 172.17.0.0 range
https://serverfault.com/questions/916941/configuring-docker-to-not-use-the-172-17-0-0-range

Docker (compose?) suddenly creates bridge using 192.168.16.0/20 range #37823
https://github.com/moby/moby/issues/37823

How does compose chooses subnet for default network? #4336
https://github.com/docker/compose/issues/4336

networks
https://docs.docker.com/compose/compose-file/#networks

Mehr erfahren

Docker

Einen Kommentar hinterlassen

Kommentieren Sie anonym oder melden Sie sich zum Kommentieren an.

Kommentare

Eine Antwort hinterlassen

Antworten Sie anonym oder melden Sie sich an, um zu antworten.