Docker Container Netzwerke konfigurieren – Tutorial

Docker Container Netzwerke richtig konfigurieren – Das ultimative Tutorial

VonContentKalle

Du willst wissen, wie du Docker Netzwerke richtig konfigurierst? Dann bist du hier genau richtig. In diesem Tutorial erkläre ich dir alle Docker Netzwerk-Typen, zeige dir Best Practices für dein Homelab und gebe dir praxisnahe Docker Compose Beispiele – inklusive Traefik als Reverse Proxy. Am Ende weißt du genau, welcher Netzwerk-Modus für deinen Anwendungsfall der richtige ist.

Warum Docker Netzwerke so wichtig sind

Viele Homelab-Betreiber starten Docker-Container einfach mit docker run und hoffen, dass alles irgendwie funktioniert. Das klappt oft – bis es nicht mehr klappt. Probleme wie „Container können nicht miteinander kommunizieren“, „Port-Konflikte“ oder „Sicherheitslücken durch falsche Netzwerk-Konfiguration“ sind häufige Stolperfallen.

Docker bietet verschiedene Netzwerk-Treiber, die für unterschiedliche Szenarien optimiert sind. Wer den richtigen Typ wählt, spart sich viel Debugging-Frust und macht seinen Stack gleichzeitig sicherer und performanter.

Die Docker Netzwerk-Typen im Überblick

1. Bridge-Netzwerk (Standard)

Das Bridge-Netzwerk ist der Standard-Modus, wenn du keinen anderen Netzwerktreiber angibst. Docker erstellt dabei eine virtuelle Bridge (docker0), über die Container miteinander kommunizieren können.

So funktioniert es:

  • Jeder Container erhält eine eigene IP-Adresse im privaten Subnetz
  • Kommunikation nach außen läuft über NAT
  • Ports müssen explizit mit -p bzw. ports: freigegeben werden

Wichtig: Das Standard-Bridge-Netzwerk (docker0) unterstützt keine DNS-basierte Container-Erkennung. Wenn Container sich gegenseitig beim Namen kennen sollen, musst du ein benutzerdefiniertes Bridge-Netzwerk erstellen.

# Benutzerdefiniertes Bridge-Netzwerk erstellen
docker network create --driver bridge mein-netzwerk

# Container in diesem Netzwerk starten
docker run --network mein-netzwerk --name webserver nginx
docker run --network mein-netzwerk --name db mariadb

Jetzt kann der Webserver den Datenbankcontainer einfach über den Namen db erreichen – kein manuelles IP-Adressen-Jonglieren mehr.

2. Host-Netzwerk

Im Host-Modus teilt sich der Container den Netzwerkstack direkt mit dem Host. Es gibt keine Netzwerk-Isolation – der Container nutzt die IP des Hosts und alle Ports sind direkt erreichbar.

docker run --network host nginx

Wann Host-Netzwerk sinnvoll ist:

  • Du brauchst maximale Netzwerk-Performance (kein NAT-Overhead)
  • Die Anwendung muss viele Ports binden (z.B. Netzwerk-Monitoring-Tools)
  • Du betreibst hochperformante Anwendungen wie Spieleserver oder Streaming-Dienste

Achtung: Host-Netzwerk bietet keine Isolation. Sicherheitsbewusste Homelab-Betreiber sollten es nur dort einsetzen, wo es wirklich nötig ist.

3. Overlay-Netzwerk

Overlay-Netzwerke werden hauptsächlich in Docker Swarm-Umgebungen eingesetzt, wenn Container auf mehreren Hosts miteinander kommunizieren sollen. Sie tunneln den Traffic über VXLAN zwischen den Hosts.

Für einen einzelnen Homelab-Server ist dieses Netzwerk meist nicht relevant, aber wenn du einen Mini-Swarm mit mehreren Nodes betreibst, ist Overlay die erste Wahl. So richtest du einen einfachen Swarm ein:

# Swarm auf dem Manager-Node initialisieren
docker swarm init --advertise-addr 192.168.1.10

# Overlay-Netzwerk für den Swarm erstellen
docker network create --driver overlay --attachable swarm-net

# Service im Overlay-Netzwerk starten
docker service create   --name webserver   --network swarm-net   --replicas 2   nginx

Der Befehl docker swarm init macht deinen aktuellen Host zum Swarm-Manager. Worker-Nodes treten mit dem ausgegebenen Join-Token bei. Alle Services im selben Overlay-Netzwerk können sich dann über den Service-Namen ansprechen – egal auf welchem physischen Node sie laufen.

4. Macvlan-Netzwerk

Macvlan ist das interessanteste Netzwerk-Modell für Homelabs: Jeder Container erhält eine eigene MAC-Adresse und eine IP-Adresse direkt aus deinem Heimnetzwerk. Für deinen Router sieht der Container aus wie ein eigenes physisches Gerät.

# Macvlan-Netzwerk erstellen (Subnetz anpassen!)
docker network create -d macvlan   --subnet=192.168.1.0/24   --gateway=192.168.1.1   -o parent=eth0   heimnetz-macvlan

# Container mit eigener IP starten
docker run --network heimnetz-macvlan   --ip 192.168.1.100   pihole/pihole

Wann Macvlan sinnvoll ist:

  • Der Container soll eine eigene IP im Heimnetzwerk haben (z.B. Pi-hole, Home Assistant)
  • Du willst keine Port-Weiterleitung konfigurieren
  • Die Anwendung muss direkt im LAN erreichbar sein

Bekannte Einschränkung und Lösung: Container im Macvlan-Netzwerk können standardmäßig nicht mit dem Host kommunizieren. Das klingt zunächst unpraktisch, lässt sich aber mit einem zusätzlichen Macvlan-Interface auf dem Host lösen:

# Macvlan-Interface auf dem Host erstellen
ip link add macvlan-host link eth0 type macvlan mode bridge
ip addr add 192.168.1.200/32 dev macvlan-host
ip link set macvlan-host up

# Route zum Container-Subnetz hinzufügen
ip route add 192.168.1.100/32 dev macvlan-host

Damit kann der Host über 192.168.1.200 mit den Macvlan-Containern kommunizieren. Um dieses Interface nach einem Neustart wiederherzustellen, kannst du es als systemd-Netzwerk-Unit oder in /etc/network/interfaces dauerhaft einrichten.

Docker Compose Netzwerke richtig konfigurieren

In der Praxis nutzt du Docker Netzwerke fast immer über Docker Compose. Hier ein typisches Beispiel für einen Stack mit Datenbank-Backend:

version: "3.9"

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # Kein Internetzugang!

services:
  webapp:
    image: myapp:latest
    networks:
      - frontend
      - backend
    ports:
      - "8080:80"

  database:
    image: mariadb:11
    networks:
      - backend
    environment:
      MYSQL_ROOT_PASSWORD: secret
      MYSQL_DATABASE: appdb

  redis:
    image: redis:7-alpine
    networks:
      - backend

Dieses Setup trennt sauber zwischen dem Frontend-Netzwerk (erreichbar von außen) und dem Backend-Netzwerk (nur intern). Die Datenbank und Redis sind nie direkt aus dem Internet erreichbar – nur die Webapp kann sie ansprechen.

Sicherheit: Container-Isolation richtig umsetzen

Gute Netzwerk-Segmentierung ist eines der wichtigsten Sicherheitsfeatures in Docker. Hier die wichtigsten Regeln:

  • Minimales Netzwerk-Exposure: Gib nur die Ports frei, die wirklich von außen erreichbar sein müssen
  • internal: true nutzen: Interne Netzwerke haben keinen Zugang zum Internet – perfekt für Datenbanken
  • Niemals alles in einem Netzwerk: Trenne kritische Dienste (Datenbanken, Secrets-Manager) in eigene Netzwerke
  • Kein Default-Bridge für Produktions-Stacks: Immer benutzerdefinierte Netzwerke anlegen

Traefik als Reverse Proxy einbinden

Für ein gut strukturiertes Homelab mit mehreren Diensten ist Traefik der ideale Reverse Proxy. Er erkennt Container automatisch über Docker-Labels und übernimmt SSL-Zertifikate via Let’s Encrypt.

Das Netzwerk-Konzept: Alle Dienste, die über Traefik erreichbar sein sollen, hängen im selben Netzwerk (traefik-proxy). Traefik horcht auf Port 80/443 des Hosts.

# Erst das Traefik-Netzwerk erstellen (einmalig)
docker network create traefik-proxy

traefik/docker-compose.yml:

version: "3.9"

networks:
  traefik-proxy:
    external: true

services:
  traefik:
    image: traefik:v3
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.letsencrypt.acme.email=deine@email.de"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
    ports:
      - "80:80"
      - "443:443"
    networks:
      - traefik-proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt

Sicherheitstipp: exposedbydefault=false ist kein optionaler Komfort, sondern ein wichtiges Sicherheitsmerkmal. Ohne diese Einstellung würde Traefik alle laufenden Container automatisch nach außen exponieren – auch solche, die du nur intern nutzen möchtest. Mit exposedbydefault=false wird nur das veröffentlicht, was du explizit mit traefik.enable=true freischaltest. So verhinderst du, dass versehentlich interne Admin-Oberflächen (z.B. Portainer, Grafana) ohne Authentifizierung öffentlich erreichbar werden.

Ein Dienst einbinden (z.B. Nextcloud):

version: "3.9"

networks:
  traefik-proxy:
    external: true
  nextcloud-intern:
    driver: bridge
    internal: true

services:
  nextcloud:
    image: nextcloud:latest
    networks:
      - traefik-proxy
      - nextcloud-intern
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.nextcloud.rule=Host(`cloud.meinserver.de`)"
      - "traefik.http.routers.nextcloud.entrypoints=websecure"
      - "traefik.http.routers.nextcloud.tls.certresolver=letsencrypt"

  nextcloud-db:
    image: mariadb:11
    networks:
      - nextcloud-intern
    environment:
      MYSQL_ROOT_PASSWORD: sicherespasswort

Das Ergebnis: Nextcloud ist über https://cloud.meinserver.de erreichbar, die Datenbank ist vollständig isoliert und hat keinen eigenen Internetzugang.

Troubleshooting: Häufige Fehler bei Docker Netzwerken

Selbst mit gutem Setup gibt es Situationen, in denen Container sich nicht finden oder Verbindungen unerwartet fehlschlagen. Diese Fehler sind die häufigsten:

Container finden sich nicht gegenseitig

Symptom: curl http://db:3306 schlägt fehl, obwohl beide Container laufen. Ursache ist fast immer, dass beide Container in verschiedenen Netzwerken sind oder du das Standard-Bridge-Netzwerk verwendest, das kein DNS unterstützt.

Lösung: Stelle sicher, dass beide Container im selben benutzerdefinierten Netzwerk sind. Mit docker network inspect mein-netzwerk kannst du prüfen, welche Container verbunden sind.

# Netzwerk-Verbindungen prüfen
docker network inspect mein-netzwerk

# Container nachträglich zum Netzwerk hinzufügen
docker network connect mein-netzwerk bestehender-container

Port-Konflikte beim Starten

Wenn du Bind for 0.0.0.0:80 failed: port is already allocated siehst, läuft bereits ein Prozess auf diesem Port – entweder ein anderer Container oder ein Dienst auf dem Host (Apache, Nginx). Mit ss -tlnp | grep :80 findest du schnell heraus, wer den Port belegt. Entweder stoppst du den Konflikt-Prozess oder du änderst den Port-Mapping in deiner Compose-Datei.

Macvlan: Host kann Container nicht erreichen

Das ist das bekannteste Macvlan-Problem. Ohne das oben gezeigte Macvlan-Host-Interface ist der Host für seine eigenen Container unsichtbar. Prüfe mit ping 192.168.1.100 vom Host aus, ob die Verbindung besteht. Fehlt sie, liegt es fast immer am fehlenden Host-Interface. Die oben gezeigte ip link-Lösung behebt das zuverlässig.

Container hat keinen Internetzugriff

Wenn du ein Netzwerk mit internal: true verwendest, ist kein Internetzugriff gewollt – das ist korrekt. Bei ungewolltem Ausfall prüfe zunächst die DNS-Auflösung im Container mit docker exec container-name nslookup google.com und dann die iptables-Regeln auf dem Host (iptables -t nat -L -n). Docker verwaltet diese Regeln automatisch, aber manche Security-Tools (ufw, firewalld) können sie überschreiben.

Netzwerk-Typen auf einen Blick

Netzwerk-Typ Isolation Performance Bester Use Case
Bridge (custom) Gut Mittel Standard für die meisten Apps
Host Keine Sehr gut Performance-kritische Dienste
Overlay Gut Mittel Multi-Host / Docker Swarm
Macvlan Sehr gut Sehr gut Eigene LAN-IP benötigt

Fazit: Docker Netzwerk konfigurieren leicht gemacht

Mit dem richtigen Netzwerk-Setup machst du deinen Docker-Stack sicherer, skalierbarer und einfacher zu warten. Die wichtigsten Punkte zum Mitnehmen:

  • Nutze immer benutzerdefinierte Bridge-Netzwerke statt dem Standard-Bridge-Netzwerk
  • Trenne Frontend und Backend mit mehreren Netzwerken pro Stack
  • Verwende internal: true für Datenbanken und andere interne Dienste
  • Macvlan lohnt sich, wenn Container eine eigene LAN-IP brauchen (Pi-hole, Home Assistant)
  • Traefik mit exposedbydefault=false schützt dich vor versehentlich öffentlichen Diensten
  • Bei Problemen: docker network inspect und docker exec sind deine besten Debugging-Werkzeuge

Hast du Fragen zu deinem spezifischen Setup? Schreib’s in die Kommentare – ich helfe gerne!

Ähnliche Beiträge