Begriff
Bridge Network
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Wenn du Docker installierst, willst du nicht, dass jeder Container direkt im Internet hängt. Du willst ein privates Netzwerk für deine Container. Das Bridge Network ist der Standard ("Default"). Es ist wie ein virtueller Switch (Verteiler) innerhalb deines PCs. Alle Container, die an dieser Bridge hängen, können miteinander reden (über IP), sind aber von außen (LAN/Internet) erstmal isoliert. Der Docker-Daemon spielt den Router (NAT), damit die Container trotzdem ins Internet kommen (z. B. Updates laden), aber das Internet nicht in den Container.
Merksatz: Der Standard-Netzwerktreiber in Docker, der ein privates, internes Netzwerk auf dem Host erstellt, über das Container untereinander kommunizieren können, während sie per NAT Zugriff nach außen erhalten.
Jeder Container landet automatisch im Netzwerk bridge.
Man sieht es mit: docker network ls.
Aber Achtung: Im "Default Bridge" Network funktioniert DNS nicht gut (man kann Container nicht per Namen anpingen).
Best Practice: Erstelle ein User-Defined Bridge Network.
docker network create mein-netz
docker run --network mein-netz --name db mysql
docker run --network mein-netz --name app my-app
Jetzt kann die App einfach ping db machen. Docker löst "db" automatisch in die richtige IP auf.
Keine harten IP-Adressen nötig!
Praxisroutine
In der Praxis lernst du Bridge Network, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.
Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.
1. vEth Pairs & Linux Bridge
Auf Kernel-Ebene erstellt Docker für jeden Container ein vEth Pair (Virtual Ethernet).
Ein Ende steckt im Container (eth0), das andere Ende steckt im Host (veth123abc).
Alle Host-Enden werden in einen virtuellen Switch (Linux Bridge docker0) gesteckt.
Wenn Paket A zu B will:
Container A -> eth0 -> vethA -> Bridge (Switching) -> vethB -> eth0 -> Container B.
Das passiert alles im Kernel auf Layer 2 (Data Link). Sehr schnell.
2. NAT & Port Forwarding
Wie kommt der Container ins Internet?
Über Masquerading (NAT).
Die Bridge routet Pakete an das Host-Interface (eth0 vom PC).
iptables ändert die Absender-IP (Source NAT) auf die Host-IP.
Rückweg: Wenn ich docker run -p 8080:80 mache, erstellt Docker eine DNAT Regel (Destination NAT).
"Alles was auf Host Port 8080 ankommt, weiterleiten an Container IP:80".
Achtung: docker-proxy Prozess läuft im User-Space als Fallback, aber iptables macht die Hauptarbeit.
3. Isolation & Security
Container im gleichen Bridge-Netzwerk vertrauen sich oft blind ("Alle Ports offen"). Wenn ein Hacker den Web-Container übernimmt, kann er die Datenbank scannen (Lateral Movement). In Kubernetes nutzt man deshalb Network Policies, um Bridges einzuschränken ("Web darf nur DB Port 5432 sprechen").
Anatomie der iptables Rules
Wenn du Docker startest, übernimmt es Teile deiner Linux Firewall (iptables / nftables).
Ein tiefes Verständnis der DOCKER-USER Chain ist wichtig, um nicht versehentlich Ports freizulegen.
Eine Standard-Bridge verbietet per Default Traffic von außen und nutzt MASQUERADE für den Outbound-Traffic der Container.
Wenn du docker run -p 8080:80 machst, fügt Docker in der PREROUTING-Table eine DNAT-Regel hinzu.
Vorsicht: Docker umgeht oft die Standard UFW (Uncomplicated Firewall) von Ubuntu! Wenn du in UFW Port 8080 verbietest, Docker aber auf 8080 bindet (-p 8080:80), bleibt der Port von außen oftmals trügerischerweise offen, da Dockers iptables-Regeln vor den UFW-Regeln greifen.
MAC Address Flapping und Switch-Verwirrung
Docker nutzt intern virtuelle Interfaces (veth123). Da die Bridge "switching" betreibt, sieht der physische Switch beim Rechenzentrum (z.B. Hetzner) manchmal verschiedene MAC-Adressen von derselben Netzwerkkartenschnittstelle kommen.
Manche RZ-Switches klassifizieren das als "MAC Spoofing" oder "Arp Poisoning" und schalten den Switchport ab – der Server ist komplett offline.
Das war der Grund, warum Hetzner lange Zeit Docker-Installationen mit spezifischen Bridge-Setups restriktiv behandelte, bevor Workarounds implementiert wurden.
Hairpin NAT (NAT Reflection)
Kann ein Container seine eigene Host-IP ansprechen?
Angenommen, Container A (172.17.0.2) ist auf Host 1.2.3.4 an Port 80 gebunden.
Nun ruft Container A selbst curl http://1.2.3.4:80 auf.
Das Paket verlässt die Bridge, erreicht das externe Interface, muss dort die DNAT-Regel "bemerken" und scharf wenden (Hairpin), um zurück in die Bridge zu Container A zu fließen.
Docker muss dafür spezielles Hairpin-NAT aktivieren, was in komplexen Setups (oder wenn man an sysctl.conf dreht) oft zerbricht. Ohne Hairpining können Microservices sich nicht über die externe Public-URL finden.
Quick-Check
Unterschied zu Host Network?
Beim Host Network (--network host) bekommt der Container keine eigene IP. Er nutzt direkt die IP des Hosts. Schneller (kein NAT), aber Port-Konflikte (nur ein Container kann Port 80 haben). Bridge ist sicherer und flexibler.Kann ich Bridges verbinden?
Nicht direkt. Du musst Routing einrichten. Oder einfacher: Hänge einen Container in zwei Netzwerke (docker network connect netz2 container1).Macvlan?
Eine Alternative zur Bridge. Der Container bekommt eine echte MAC-Adresse und wirkt wie ein physisches Gerät im LAN. Nützlich für Legacy-Apps, die Layer-2-Sichtbarkeit brauchen.