Netzwerke in Docker: bridge, host, overlay

Container leben nicht allein – sie müssen miteinander reden, müssen vom Internet erreichbar sein, müssen sich gleichzeitig voreinander schützen. Docker bringt ein eigenes Netzwerk-Subsystem mit, das auf Linux-Kernel-Features (Netzwerk-Namespaces, virtuelle Bridges, iptables-NAT) aufbaut. Es kennt mehrere Netzwerk-Treiber – bridge, host, none, overlay, macvlan – die jeweils für ein bestimmtes Szenario gemacht sind. Wer den richtigen Treiber wählt, baut sichere Multi-Container-Anwendungen mit klarem Trennungskonzept. Wer den falschen wählt, schießt sich Sicherheitslöcher in den Server oder produziert Netzwerk-Probleme, die nur schwer zu debuggen sind.

Die Analogie: Stell dir den Container-Host als Bürogebäude vor. Das bridge-Netzwerk ist wie ein internes Telefonnetz – nur Mitarbeiter im selben Stockwerk können sich anrufen, und nach außen geht es nur über die zentrale Vermittlung (NAT). Das host-Netzwerk ist, wenn ein Mitarbeiter direkt am Empfangstresen sitzt – er teilt die externen Anschlussnummern mit der Empfangsdame, kein Schutz dazwischen. Das overlay-Netzwerk ist wie ein internes Telefonsystem über mehrere Bürogebäude hinweg – verbunden durch ein VPN.

1) Die Netzwerk-Treiber visuell

Schau dir die drei wichtigsten Netzwerk-Treiber als Topologie an. Klick durch und sieh, wie der Datenfluss zwischen Container, Host und Außenwelt aussieht:

Docker-Netzwerk-Topologien

Faustregel: bridge ist Standard und reicht für 95 % der Fälle (Single-Host-Setups, Multi-Container-Apps). host nur, wenn Performance kritisch ist (z. B. Network-Monitoring-Container, der Pakete am Interface mitliest). overlay für Multi-Host-Cluster (Swarm, Kubernetes). none für komplett isolierte Container ohne jede Netzwerk-Verbindung.

2) Default Bridge vs. Custom Bridge – ein wichtiger Unterschied

Wenn du docker run nginx aufrufst, landet der Container auf der Default-Bridge (docker0). Das funktioniert, hat aber eine entscheidende Einschränkung: Container auf der Default-Bridge können sich nicht per Namen erreichen, nur per IP. Container A weiß nicht, dass Container B die IP 172.17.0.3 hat – er müsste sie auf irgendeinem Weg erfahren.

Auf einer Custom Bridge ist das ganz anders: Docker stellt ein eingebautes DNS bereit. Container können sich gegenseitig per Container-Namen oder per Alias ansprechen. Das ist die Grundlage für moderne Multi-Container-Setups:

Default Bridge vs. Custom Bridge – DNS-Demo

# Default Bridge: kein DNS zwischen Containern $ docker run -d --name web nginx $ docker run -d --name api node app.js $ docker exec api ping web ping: bad address 'web' # Custom Bridge erstellen $ docker network create app-net f8a2c1e4d5b7a9c0... # Container mit Custom Bridge $ docker run -d --name web --network app-net nginx $ docker run -d --name api --network app-net node app.js $ docker exec api ping web PING web (172.18.0.2): 56 data bytes 64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.082 ms ← DNS funktioniert! Name → IP automatisch aufgelöst # Auch curl per Name funktioniert $ docker exec api curl http://web <!DOCTYPE html> <html> <head><title>Welcome to nginx!</title>...

Regel: Immer Custom Bridges anlegen für produktive Multi-Container-Setups. Der Default-Bridge ist Legacy-Verhalten von früher und sollte nur für Schnelltests verwendet werden. Mit Docker Compose wird automatisch eine Custom Bridge pro Stack angelegt.

3) Port-Mapping – wie ein Container von außen erreichbar wird

Container auf der Bridge sind von außen nicht direkt erreichbar – sie haben nur private IPs. Wenn der Webserver auf Port 80 im Container lauscht, kommt niemand vom Internet dran. Dafür gibt es Port-Mapping: Mit -p HOST:CONTAINER bei docker run wird ein Port auf der Host-IP auf einen Container-Port weitergeleitet (per iptables-NAT):

Port-Mapping: Host → Container

-p 8080:80
Host:8080 → Container:80

-p 80:80
Host:80 → Container:80

-p 127.0.0.1:80:80
Nur localhost (intern)

-p 80:80/udp
UDP statt TCP

-p 80
Random Host-Port

-P (großes P)
Alle EXPOSE-Ports random mappen

Wichtige Falle: Container-zu-Container-Kommunikation braucht kein Port-Mapping. Wenn der API-Container den DB-Container auf Port 5432 anruft, geht das direkt über die Bridge – nicht über die Host-Schnittstelle. -p ist nur für die Außenwelt nötig. Eine zweite Falle: Wenn du nur -p 80:80 nutzt, hört der Container auf allen Host-Interfaces – auch dem öffentlichen. Wenn das nicht beabsichtigt ist, immer -p 127.0.0.1:80:80 verwenden.

4) Container-Netzwerk inspizieren – Diagnose-Befehle

Wenn ein Container nicht erreichbar ist oder zwei Container sich nicht verstehen, hilft eine systematische Netzwerk-Diagnose. Die wichtigsten Befehle:

Netzwerk-Diagnose im Container-Alltag

# Alle Netzwerke auflisten $ docker network ls NETWORK ID NAME DRIVER SCOPE b3c4d5e6f7a8 bridge bridge local a1b2c3d4e5f6 host host local f8a2c1e4d5b7 app-net bridge local 9c8d7e6f5a4b none null local # Details eines Netzwerks (incl. aller Container) $ docker network inspect app-net [{ "Name": "app-net", "Driver": "bridge", "IPAM": { "Config": [{"Subnet": "172.18.0.0/16", "Gateway": "172.18.0.1"}] }, "Containers": { "a3f8b2c1": {"Name": "web", "IPv4Address": "172.18.0.2/16"}, "7c9d2a1b": {"Name": "api", "IPv4Address": "172.18.0.3/16"}, "2e4f6a1c": {"Name": "db", "IPv4Address": "172.18.0.4/16"} } }] # Im Container Netzwerk-Tools nutzen $ docker exec api ip addr eth0: 172.18.0.3/16 lo: 127.0.0.1/8 $ docker exec api ping -c 2 db PING db (172.18.0.4): 56 data bytes 64 bytes from 172.18.0.4: seq=0 ttl=64 time=0.142 ms 2 packets transmitted, 2 received, 0% packet loss $ docker exec api nslookup db Server: 127.0.0.11 # Docker DNS Address: 127.0.0.11:53 Name: db Address: 172.18.0.4 # Container an zusätzliches Netzwerk anschließen $ docker network connect another-net api # Vom Netzwerk trennen $ docker network disconnect another-net api

Bei Netzwerk-Problemen ist die Reihenfolge: 1) docker network ls – ist das Netzwerk da? 2) docker network inspect – ist der Container drin? 3) docker exec ping – pingt der eine den anderen? 4) docker exec curl – antwortet der Service? 5) Logs prüfen. Diese fünf Schritte lösen 90 % aller Container-Netzwerk-Probleme. Weiterführend: Systematische Netzwerk-Fehlersuche.

5) Mehrere Netzwerke – Isolation einplanen

Eine wichtige Best Practice: Container nur an die Netzwerke anschließen, die sie wirklich brauchen. Wenn die Datenbank nur vom Backend angesprochen werden soll, muss sie nicht im selben Netzwerk wie der Webserver hängen. Typisches Setup für eine 3-Schichten-Anwendung:

Netzwerk	Container	Erreichbar von
frontend	nginx (Web)	Außenwelt (via Port-Mapping), backend-Netzwerk
backend	api, nginx	nur intern, db-Netzwerk
db	postgres, api	nur intern, keine externe Erreichbarkeit

Mit diesem Setup kann der Webserver die API erreichen (beide im backend-Netzwerk), die API kann die DB erreichen (beide im db-Netzwerk), aber der Webserver kann nicht direkt mit der DB sprechen. Das ist ein elementares Sicherheitskonzept (Stichwort Netzwerksegmentierung), das in Container-Welten genauso wichtig ist wie in klassischen Netzwerken.

Mehrere Netzwerke – Setup mit klarer Trennung

# Drei isolierte Netzwerke anlegen $ docker network create frontend docker network create backend docker network create db # Nginx ist in frontend UND backend $ docker run -d --name web --network frontend -p 80:80 nginx docker network connect backend web # API ist in backend UND db $ docker run -d --name api --network backend myapp/api docker network connect db api # Postgres NUR im db-Netzwerk $ docker run -d --name postgres --network db \ -e POSTGRES_PASSWORD=secret postgres:16 # Probier: Webserver kann Postgres NICHT erreichen $ docker exec web ping postgres ping: bad address 'postgres' ← korrekt isoliert!

Diese Architektur ist Standard für moderne Microservices-Setups. Mit Docker Compose lassen sich solche Netzwerk-Konstrukte deklarativ in einer YAML-Datei festhalten – kommt in der nächsten Lektion.

6) macvlan – Container als eigenständiger Host im LAN

Der macvlan-Treiber ist ein Sonderfall: Er gibt dem Container eine eigene MAC-Adresse auf dem Host-Interface, sodass er im LAN aussieht wie ein eigenständiger physischer Host. Vorteil: Andere Geräte im Netzwerk können direkt mit dem Container reden, ohne Port-Mapping oder NAT. Nachteil: Setup-Aufwand, nicht in allen Netzwerken erlaubt (manche Switches blockieren mehrere MACs pro Port).

Anwendungsfall: Legacy-Anwendungen, die auf einem bestimmten Subnet erwarten und nicht hinter einem NAT laufen können. Auch beliebt: Heimnetzwerke, in denen ein Pi-hole-Container eine eigene IP im LAN bekommen soll. Für die meisten Anwendungen ist macvlan aber overkill – bridge mit Port-Mapping reicht.

7) Service Discovery und Reverse Proxies

In Multi-Container-Anwendungen mit vielen Microservices wird die Frage „wer redet mit wem?" schnell komplex. Die wichtigsten Muster:

Service Discovery via DNS: Wie oben gezeigt – Container reden sich per Namen an. Funktioniert in Custom Bridges und in Overlay-Netzwerken automatisch.
Reverse Proxy: Ein nginx- oder Traefik-Container an der Front nimmt eingehende Requests an, leitet sie an interne Services weiter. Vorteil: nur ein Container ist von außen erreichbar, alles andere bleibt im internen Netzwerk.
Service Mesh: Tools wie Istio oder Linkerd erweitern die Container-Kommunikation um TLS, Authentication, Retry-Logic, Tracing. Komplex aber mächtig – in großen Microservices-Setups Standard.

Ein typischer Setup: Traefik horcht auf Port 80/443 des Hosts, übernimmt TLS-Termination (HTTPS), routet je nach Host-Header an die richtigen Backend-Container. Alle Backend-Container haben keine direkten Port-Mappings – nur Traefik ist außen sichtbar. Das ist Best Practice für produktive Container-Setups.

Zusammenfassung

Docker bietet mehrere Netzwerk-Treiber: bridge (Standard, virtuelle Bridge, jeder Container eigene private IP, nach außen NAT, eingehend per -p); host (kein eigener Network-Namespace, Container am Host-Interface, maximale Performance, keine Isolation); overlay (über mehrere Hosts via VXLAN, für Swarm/K8s); none (komplett isoliert); macvlan (eigene MAC im LAN). Default-Bridge vs. Custom-Bridge: Default kennt kein DNS zwischen Containern, Custom Bridge schon → immer Custom anlegen. Port-Mapping mit -p HOST:CONTAINER macht Container von außen erreichbar; Container untereinander brauchen kein Mapping. Best Practice: mehrere isolierte Netzwerke (frontend/backend/db) für klare Segmentierung. Diagnose: docker network ls/inspect, docker exec ping/nslookup/curl. Service Discovery via Docker-DNS (automatisch in Custom Bridges); für komplexe Setups Reverse Proxy (Traefik, nginx) oder Service Mesh (Istio, Linkerd).