Docker bridge networks - kaputte IP tables

UCS - Univention Corporate Server
, , ,
#1

Hallo,

ich habe hier einen UCS 4.4-1 errata223 DC Master Server und bin mit docker-compose über das Problem gestolpert, dass iptables irgendwann kaputt sind. Wahrscheinlich betrifft das auch die Guacamole App (siehe Guacamole Network Bridge Problem - Bypass Solution).

Ich habe folgendes docker-compose.yml:

version: '2'
services:
  acmedns:
    build:
      context: .
      dockerfile: Dockerfile
    image: joohoi/acme-dns:latest
    restart: always
    ports:
      - "1153:53"
      - "1153:53/udp"
      - "8053:80"
    volumes:
      - ./config:/etc/acme-dns:ro
      - ./data:/var/lib/acme-dns

Nach dem Befehl

docker-compose up -d

sehen die iptables noch OK aus:

iptables -t nat -L DOCKER -v
Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  br-55b2b36a614b any     anywhere             anywhere            
   81  5095 RETURN     all  --  docker0 any     anywhere             anywhere            
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40004 to::8080
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40002 to:172.17.0.1:80
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40001 to:172.17.0.2:443
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40000 to:172.17.0.2:80
    0     0 DNAT       tcp  --  !br-55b2b36a614b any     anywhere             anywhere             tcp dpt:8053 to:172.19.0.2:80
    0     0 DNAT       tcp  --  !br-55b2b36a614b any     anywhere             anywhere             tcp dpt:1153 to:172.19.0.2:53
    0     0 DNAT       udp  --  !br-55b2b36a614b any     anywhere             anywhere             udp dpt:1153 to:172.19.0.2:53

Der Container acmedns_acmedns_1 läuft korrekt mit der IP-Adresse 172.19.0.2 und die Portforwardings stimmen.

Ab irgendeinem Zeitpunkt (ich konnte bisher noch keinen Trigger dafür bestimmen) sehen die iptables folgendermaßen aus:

iptables -t nat -L DOCKER -v
Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
   24  1495 RETURN     all  --  docker0 any     anywhere             anywhere            
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:1880 to::1880
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:1153 to::53
    0     0 DNAT       udp  --  !docker0 any     anywhere             anywhere             udp dpt:1153 to::53
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:8053 to::80
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40004 to::8080
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40002 to:172.17.0.1:80
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40001 to:172.17.0.2:443
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40000 to:172.17.0.2:80

Der UDP-Port 1153 wird nicht mehr auf Port 53 des Docker-Containers umgebogen, sondern allgemein auf den Port 53 des Hostsystems. Das ist in diesem Fall natürlich fatal.

Die Guacamole-App habe ich auch installiert. Ich nutze sie nur derzeit nicht, weshalb mir auch eine eventuelle Fehlfunktion aktuell nicht auffällt. Aber der Port 40004 ist auch nicht mehr sauber in den Docker-Container weitergeleitet.

Noch eine Ausgabe von “docker ps -a”:

CONTAINER ID        IMAGE                                                                   COMMAND                  CREATED             STATUS                       PORTS                                                                       NAMES
9c3eecae92ba        palstek/node-red                                                        "node-red --userDi..."   8 days ago          Up 29 seconds                0.0.0.0:1880->1880/tcp                                                      nodered_node-red_1
5998c8aca09f        joohoi/acme-dns:latest                                                  "./acme-dns"             10 days ago         Up 28 seconds                443/tcp, 0.0.0.0:1153->53/tcp, 0.0.0.0:1153->53/udp, 0.0.0.0:8053->80/tcp   acmedns_acmedns_1
2807dbb019f0        docker.software-univention.de/nextcloud:15.0.8-0                        "/bin/sh -c /usr/s..."   2 months ago        Up 21 seconds                0.0.0.0:40002->80/tcp                                                       gifted_fermi
950505f0cc9a        docker.software-univention.de/guacamole-guacamole:0.9.13-univention13   "/opt/guacamole/bi..."   5 months ago        Up 29 seconds                0.0.0.0:40004->8080/tcp                                                     guacamole_guacamole_1
fc21fef849d2        docker.software-univention.de/guacamole-guacd:0.9.13-univention13       "/usr/local/sbin/g..."   5 months ago        Up 29 seconds                4822/tcp                                                                    guacamole_guacd_1
688d267f9c99        docker.software-univention.de/ucs-appbox-amd64:4.3-0                    "/sbin/init"             13 months ago       Up 20 seconds                0.0.0.0:40000->80/tcp, 0.0.0.0:40001->443/tcp                               friendly_dijkstra

Reboots helfen nicht. Danach sehen die iptables genauso kaputt aus. Wenn ich den betreffenden Docker-Container mit “docker-compose down” lösche, muss ich die betreffenden iptables-Rules händisch löschen. Im Netz habe ich leider keine weiterhelfenden Hinweise finden können.

Wann plant Univention docker/docker-compose auf aktuellere Versionsstände zu aktualisieren? Diese sind mittlerweile doch schon etwas in die Jahre gekommen.

Viele Grüße,
Daniel

#2

Eine Beobachtung kann ich hinzufügen:
Ein Reboot ist auf alle Fälle ein Trigger, welcher die IP-Tables zerstört. Das entsprechende Bridgedevice ist im Kernel angelegt, aber die IP-Tables verweisen nicht mehr auf das Bridgedevice.

#3

Das Problem kann einfach in einer frischen Umgebung reproduziert werden:

  1. UCS VM Image von univention.de geladen und fertig eingerichtet
  2. Guacamole App über Appcenter installiert
  3. Direkt nach der Installation folgende Infos über Konsole abgerufen:
Administrator@ucs-3795:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Univention
Description:    Univention Corporate Server 4.4-1 errata186 (Blumenthal)
Release:        4.4-1 errata186
Codename:       Blumenthal

Administrator@ucs-3795:~$ sudo iptables -t nat -L DOCKER -v                                                                    
Chain DOCKER (2 references)                                                                                                                     
 pkts bytes target     prot opt in     out     source               destination                                                                 
    2   132 RETURN     all  --  br-86c320f84dbf any     anywhere             anywhere                                                           
    0     0 RETURN     all  --  docker0 any     anywhere             anywhere                                                                     
    0     0 DNAT       tcp  --  !br-86c320f84dbf any     anywhere             anywhere             tcp dpt:40001 to:172.18.0.3:8080
Administrator@ucs-3795:~$ sudo docker ps -a
CONTAINER ID        IMAGE                                                                   COMMAND                  CREATED             STATUS              PORTS                     NAMES
72adf4194b55        docker.software-univention.de/guacamole-guacamole:0.9.13-univention13   "/opt/guacamole/bi..."   3 minutes ago       Up 3 minutes        0.0.0.0:40001->8080/tcp   guacamole_guacamole_1
efa93e6c8933        docker.software-univention.de/guacamole-guacd:0.9.13-univention13       "/usr/local/sbin/g..."   3 minutes ago       Up 3 minutes        4822/tcp                  guacamole_guacd_1
  1. Reboot
  2. Infos wiederholt abgerufen:
Administrator@ucs-3795:~$ sudo iptables -t nat -L DOCKER -v
Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  docker0 any     anywhere             anywhere            
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40001 to::8080
Administrator@ucs-3795:~$ sudo docker ps -a
[sudo] Passwort für Administrator: 
CONTAINER ID        IMAGE                                                                   COMMAND                  CREATED             STATUS              PORTS                     NAMES
72adf4194b55        docker.software-univention.de/guacamole-guacamole:0.9.13-univention13   "/opt/guacamole/bi..."   12 minutes ago      Up 49 seconds       0.0.0.0:40001->8080/tcp   guacamole_guacamole_1
efa93e6c8933        docker.software-univention.de/guacamole-guacd:0.9.13-univention13       "/usr/local/sbin/g..."   12 minutes ago      Up 49 seconds       4822/tcp                  guacamole_guacd_1

-> die IP-Tables Regeln sind nicht mehr an die Bridge br-86c320f84dbf geknüpft.
Was läuft da falsch? Es ist auf alle Fälle ein reproduzierbares Problem, welches nicht nur in meiner verwurstelten Installation auftritt. Wer kann da weiterhelfen? Sollte ich einen Bugreport anlegen?

1 Like
#4

Bin mit meinen Recherchen etwas weitergekommen. /etc/security/packetfilter.d/20_docker.sh von univention-firewall kennt quasi nur das Bridge Netzwerk docker0. Die von docker-compose angelegten Bridge Netzwerke werden leider ignoriert.

Jetzt ist mir auch klar geworden, warum 20_docker.sh diese iptables Regeln neu anlegt: Das Paket univention-firewall löscht alle Regeln und legt diese neu an. Damit müssen natürlich auch die von Docker angelegten Regeln wieder neu angelegt werden. Das klärt jetzt auch, warum direkt nach “docker-compose up” alles gut ist. Wenn dann irgendwann der Service univention-firewall neu gestartet wird (spätestens nach einem Reboot), sind die Docker-spezifischen Regeln durch 20_docker.sh neu angelegt. Leider nicht ganz sauber.

Mal schauen, ob ich 20_docker.sh irgendwie erweitern kann. Es scheint nur nicht ganz trivial, die Docker NetworkID in den Linux bridge Netzwerknamen umzukodieren.

#5

Hi,

ja, bitte einen Bug anlegen.

Danke!

/CV

#6

Ich lese oben das UCS 4.4-1 errata 186 verwendet wird. Ist Problem nach dem Update auf die aktuellste Version noch vorhanden? Es gab vor kurzem ein Update für Probleme in dem Bereich Docker+Firewall: http://errata.software-univention.de/ucs/4.4/233.html

#7

Bug-Report ist angelegt: https://forge.univention.org/bugzilla/show_bug.cgi?id=50088

#8

Auf meinem Hauptsystem ist der aktuellste Stand installiert. /etc/security/packetfilter.d/20_docker.sh tut ja weiterhin alle Regeln für docker0 und nicht für die spezifischen Bridge Netzwerke anlegen.
Nichtsdestotrotz fahre ich gerade ein Update auf dem Testsystem und teste es nochmal.

#9

Problem besteht weiterhin:

Administrator@ucs-3795:~$ sudo iptables -t nat -L -v
[sudo] Passwort für Administrator: 
Chain PREROUTING (policy ACCEPT 47 packets, 6076 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    1    48 DOCKER     all  --  any    any     anywhere             anywhere             ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 1 packets, 48 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 525 packets, 35568 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  167 10426 DOCKER     all  --  any    any     anywhere            !loopback/8           ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 525 packets, 35568 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MASQUERADE  all  --  any    !docker0  172.17.0.0/16        anywhere            

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  docker0 any     anywhere             anywhere            
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:40001 to::8080
Administrator@ucs-3795:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Univention
Description:    Univention Corporate Server 4.4-1 errata245 (Blumenthal)
Release:        4.4-1 errata245
Codename:       Blumenthal
Mastodon