Docker containers die plotseling 192.168.0.0.0/16 gebruiken in plaats van 172.17.0.0/16: diensten die verloren gaan.

Ik heb een ISPConfig server met Docker toepassingen. Zij gebruiken de host Postfix mail transfer agent (MTA) om post naar de buitenwereld te brengen. Voordat ik de functie send mail gebruik heb ik een controle of Postfix toegankelijk is. Dit werkt prima. Maar plotseling werd er geen post meer verstuurd. Het logbestand bevatte foutmeldingen zoals:

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')}

Relais toegang geweigerd? Waarom? Toen herinnerde ik me dat Postfix een mynetworks instelling heeft in het bestand:

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

Dit leidde me naar de IP-adressen die door Docker aan de containers zijn toegewezen:

systemctl status docker

met resultaat:

● 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

De Docker containers gebruikten plotseling het 192 subnet in plaats van het 172 subnet. Ik begrijp (nog steeds) niet waarom dit is gebeurd, maar het moest worden opgelost. Na wat zoeken heb ik de oplossing voor het probleem gevonden. Van onderstaande link:

.... door het ontwerp hebben we een netwerk bereik voor brugnetwerken.
"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"
Wanneer we een netwerk creëren, controleren we alleen of er sprake is van een overlappend netwerk binnen een door de docker aangemaakt netwerk. We hebben standaard adrespool ondersteuning voor bridge netwerk toegevoegd. U kunt het configureren via daemon.jason bestand of input param tijdens het starten van Docker Daemon. Op die manier kunt u subnet kiezen dat u wilt dat dockerD aanmaakt (standaard gateway of netwerk).

Ik heb de standaard adrespools voor mijn Docker netwerken gespecificeerd door het bestand aan te maken (het was er niet):

/etc/docker/daemon.json

met de inhoud:

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

Daarna heb ik Docker opnieuw opgestart:

systemctl restart docker

De containers hadden nog 192 subnet IP adressen. Daarna deed ik dat voor de Docker toepassingen:

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

Nu hadden ze weer 172 subnet IP adressen en de mail kwam er weer uit! Om er zeker van te zijn, heb ik ook de server opnieuw opgestart en ik was blij om te zien dat alles in orde was.

Enkele commando's om te testen

U kunt deze methode gebruiken, zie ook onderstaande link, om te controleren of het juiste netwerk is aangemaakt:

docker network create foo
docker network inspect foo | grep Subnet

Enkele andere commando's die ik daarbij heb gebruikt:

route -n

docker inspect <container> 

docker network ls

docker network inspect <network>

Samenvatting

Ik weet nog steeds niet wat de oorzaak van dit probleem is, maar gelukkig kun je een subnet opgeven voor het standaard netwerk. Dit moet echt meer benadrukt worden wanneer je Docker gaat gebruiken! U kunt ook standaard subnetten opgeven in docker-compose maar ik heb dit niet getest. Hoe dan ook opgelost.

Links / credits

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