Zug-WLAN funktioniert nicht? Docker könnte schuld sein

Vor einiger Zeit war ich mit dem ICE der Deutschen Bahn unterwegs und wollte das Bord-WLAN nutzen. Das die Internetverbindung nicht funktioniert, kommt bekanntlich ab und zu vor. Ich konnte allerdings nicht einmal das Captive Portal¹ erreichen, was schon einigermaßen selten ist.

Analyse

#

Zuvor hatte ich mit Docker gearbeitet und ein Netzwerk des Typs bridge erstellt. Bei diesem Typ bekommen mit dem Netzwerk verbundene Container sowie der Host IP-Adressen zugewiesen, unter denen sie erreichbar sind. Docker verwendet dafür standardmäßig für jedes Netzwerk einen /16-Block des IP-Adressbereich von 172.16.0.0/12², der für private Netzwerke reserviert und daher nicht Teil des globalen Internets ist.³

Das erste Adressblock 172.16.0.0/16 wird dabei nicht verwendet, da dieser häufig für lokale Netzwerke verwendet wird.⁴ Der nächste Block 172.17.0.0/16 ist der standardmäßige Adressbereich des Standard-Netzwerks bridge:

❯ docker network inspect bridge 
[
    {
        …
        "IPAM": {
            …
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "IPRange": "",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        …
    }
]

Alle weiteren Blöcke werden aufsteigend für Netzwerke verwendet, die mit docker network create erstellt werden. Das erste (hier demo genannt) erhält:

❯ docker network inspect demo 
[
    {
        …
        "IPAM": {
            …
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "IPRange": "",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        …
    }
]

Wie bereits erwähnt, wird der Block 172.16.0.0/16 übersprungen, weil er häufig für lokale Netzwerke verwendet wird. Alle anderen Bereiche sind üblicherweise ungenutzt. Eine verhängnisvolle Ausnahme stellt das Bord-WLAN des ICE dar: Dieses verwendet den Bereich 172.18.0.0/16, denselben wie das erste nutzererstellte Docker-Netzwerk:

❯ ip a
…
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1440 qdisc noqueue state UP group default qlen 1000
    link/ether 01:23:45:67:89:ab brd ff:ff:ff:ff:ff:ff
    altname wlx74d83e3e31a4
    inet 172.18.0.1/16 brd 172.18.255.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 598sec preferred_lft 598sec
    inet6 fe80::cdd8:684:4c94:dc3d/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
…
12: br-d9ec15037321: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 76:8c:41:da:45:99 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-d9ec15037321
       valid_lft forever preferred_lft forever

In Folge werden alle Pakete, die eigentlich für das Bord-WLAN bestimmt sind, vergeblich ins Docker-Netzwerk geroutet und gehen verloren.

Abhilfe

#

Für schnelle Abhilfe reicht es aus, das problematische Docker-Netzwerk mit docker network rm zu löschen und mit docker network create neu zu erstellen. Die Container müssen danach gegebenenfalls neu verbunden werden.

Dies funktioniert, weil Docker bei der (Neu-)Erstellung des Netzwerkes bereits benutzte IP-Adressbereiche überspringt. Nur kann Docker verständlicherweise bei der Erstellung nicht wissen, ob ein bestimmter IP-Adressbereich in der Zukunft vielleicht benötigt wird.

Lösung

#

Die von der Docker-Engine verwendeten IP-Adressbereiche können in /etc/docker/daemon.json⁵ konfiguriert werden. Dabei werden nutzbare Adressbreiche definiert und für jeden Bereich die Größe des Netzwerks (Anzahl Bits des Netzwerkpräfix) zugewiesen.

IPv4

#

Für IPv4 bietet es sich an, einen Teil des für private Netzwerke reservierten IP-Adressbereichs 10.0.0.0/8³ zu verwenden, beispielsweise:

{
    "default-address-pools": [
        {
            "base": "10.128.0.0/9",
            "size": 16
        }
    ]
}

Hier wird der zweite Teil des oben genannten Bereichs verwendet, der bei 10.128.0.0 beginnt. Jedes Docker-Netzwerk hat ein Präfix von /16 Bit. Somit stehen 128 Netzwerke mit jeweils 2¹⁶ = 65536 Adressen zur Verfügung.

Allerdings sollte beachtet werden, dass auch dieser IP-Adressbereich mit anderen lokalen Netzwerken (vor allem öffentlichen WLANs und Firmennetzwerke) kollidieren kann.

IPv6

#

Seit Version 27 der Docker-Engine ist IPv6 nicht mehr experimentell.⁶ Werden keine IPv6-Adressbereiche angegeben (in /etc/docker/daemon.json oder über die Kommandozeilenoption --subnet), weist Docker einen Bereich aus den Unique Local Adresses zu.⁷

Bei der Erstellung eines Netzwerkes kann angegeben werden, dass ausschließlich IPv6 verwendet werden soll:

docker network create --ipv6 --ipv4=false ipv6only

Für Compose können diese Einstellungen ebenfalls vorgenommen werden:⁸

networks:
  ipv6only:
    enable_ipv4: false
    enable_ipv6: true

Leider bestehen derzeit noch einige Einschränkungen:

• Weiterleitungen eines Host-IPv4-Ports an den Container ist anscheinend nicht möglich.⁹ Dies bedeutet, dass der Container von außerhalb nur über IPv6 erreichbar ist. Für den Betrieb eines Servers dürfte dies in den meisten Fällen ein Ausschlusskriterium sein, für die lokale Entwicklung sollte es in Ordnung sein.

• Es gibt anscheinend keine Möglichkeit, ausschließliches IPv6 als Standard für neue Netzwerke einzustellen.
• Ebenfalls ist es anscheinend nicht möglich, das vordefinierte Netzwerk bridge ausschließlich mit IPv6 zu konfigurieren.

Schlussbemerkungen

#

Keine der beteiligten Parteien hat hier einen Fehler begangen. Die Wahl des Adressbereichs 172.18.0.0/16 seitens des Bord-WLANs ist nicht zu beanstanden, dafür ist dieser schließlich vorgesehen. Auch Docker muss sich seine IP-Adressen irgendwo hernehmen, hierfür die für lokale Netzwerke vorgesehenen Bereiche heranzuziehen, ist eine sinnvolle Wahl. Auch im größeren Adressbereich 10.0.0.0/8 (der standardmäßig von Podman für diesen Zweck verwendet wird), sind Kollisionen prinzipiell möglich. Schließlich gibt es keine IPv4-Adressbereiche, die für „Host-lokale“ Netzwerke reserviert sind.

Nur der deutlich größere Adressbereich der Unique Local Addresses von IPv6 schafft eine wirkliche Lösung. Dieser wird von Docker aber nicht standardmäßig verwendet und ist immer noch mit Einschränkungen behaftet. Anscheinend ist IPv6 für Docker immer noch Neuland.