Docker-Container-Verkehr verschlüsseln: Sicher ohne VLANs

Es ist zwei Uhr morgens. Du hast Ollama in Docker eingerichtet, Open WebUI spricht mit dem Modell und Caddy liefert nach außen ein gültiges Zertifikat aus. Der Browser zeigt das grüne Schloss. Alles sicher. Oder?

Nicht unbedingt: Ein Reverse-Proxy schützt zunächst die Verbindung vom Browser bis zum Proxy. Dahinter können Docker-Dienste weiterhin per HTTP miteinander sprechen. Das betrifft lokale LLMs ebenso wie Nextcloud, Paperless-ngx oder eigene APIs.

Dann fällt dein Blick auf den Docker-Netzwerk-Traffic. Zwischen Caddy und Ollama, zwischen Ollama und deiner Weboberfläche, zwischen all den kleinen Diensten, die dein Homelab am Laufen halten — da fließen die Daten im Klartext. Jede Anfrage mit ihrem Prompt, jede Antwort des Modells, jedes API-Token. Ungeschützt. Auf deinem eigenen Server.

Der Reflex ist dann oft: „Ich brauche VLANs." Aber VLANs sind kein Allheilmittel — sie trennen Netze, verschlüsseln aber keinen Traffic. Und bevor du deinen Switch austauschst oder dich durch Managed-Switch-Konfigurationen kämpfst, gibt es einen einfacheren Weg.

Die gute Nachricht: Du kannst den internen Traffic zwischen Docker-Containern auf mindestens vier Arten absichern, ohne ein einziges VLAN einzurichten. Manche davon sind überraschend einfach, andere erfordern etwas Disziplin — aber keine verlangt neue Hardware.

In diesem Guide zeige ich, wie du Docker Container Traffic verschlüsseln kannst: mit den jeweiligen Vor- und Nachteilen und einer praxistauglichen Konfiguration für ein Homelab.

Inhaltsverzeichnis

Das unterschätzte Problem: Warum dein Reverse-Proxy nicht genug ist
Drei Sicherheitsebenen für Docker-Traffic
Methode 1: TLS zwischen Reverse-Proxy und Backend
Methode 2: mTLS mit eigener interner PKI
Methode 3: Docker Overlay-Netzwerk mit IPsec
Methode 4: WireGuard als Container-Overlay
Praxis: Ollama mit internem TLS absichern
Vergleich der Methoden — was sich im Homelab wirklich lohnt
FAQ
Fazit

Kurzantwort

Reverse-Proxy, mTLS, WireGuard oder Docker IPsec: So schützt du den Traffic zwischen Docker-Diensten ohne eine VLAN-Infrastruktur. Kurz gesagt: Docker Container Traffic verschlüsseln ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Das unterschätzte Problem: Warum dein Reverse-Proxy nicht genug ist

Stell dir dein Homelab wie ein Haus vor. Dein Reverse-Proxy ist die Haustür mit einem massiven Schloss. Besucher kommen nur durch diese Tür, und draußen sieht alles sicher aus. Aber im Inneren des Hauses stehen alle Zimmertüren sperrangelweit offen. Jeder Dienst kann jeden anderen sehen, jeder Datenstrom fließt ungeschützt durch die Flure.

Genau so funktioniert ein typisches Docker-Setup mit Reverse-Proxy: Caddy, Traefik oder Nginx terminieren TLS am Rand deines Netzwerks und sprechen dann per HTTP mit deinen Backend-Containern. Der Traffic zwischen Proxy und den eigentlichen Diensten — deinem Ollama-Container, deiner Weboberfläche, deinen Tools — läuft im Klartext über das interne Docker-Netzwerk.

Für viele Homelab-Betreiber ist das lange kein Problem. Solange niemand im selben Netzwerksegment mitlauscht, passiert nichts. Aber die Bedrohungsmodelle verschieben sich. Immer mehr Geräte hängen im Heimnetz — unsichere IoT-Geräte, Gäste-WLANs, die Kinder mit ihren Geräten. Ein kompromittiertes Gerät im selben Layer-2-Segment kann den gesamten internen Traffic mitschneiden. Und bei einem lokalen LLM fließen da potenziell sensible Prompts durch die Leitung — persönliche Fragen, geschäftliche Entwürfe, API-Keys.

Die traditionelle Antwort auf dieses Problem sind VLANs: Du steckst deine Server in ein separates Subnetz, isolierst sie vom restlichen Netzwerk und richtest Firewall-Regeln ein. Das funktioniert. Aber es setzt einen Managed Switch voraus, VLAN-fähige Netzwerkkarten oder zumindest einen Hypervisor, der tagged VLANs versteht. Nicht jedes Homelab hat das. Und selbst wenn: VLANs verschlüsseln keinen Traffic. Sie verhindern nur, dass Unbefugte ihn sehen können — solange die Switch-Konfiguration hält und niemand einen Fehler macht.

Was wir eigentlich brauchen, ist Ende-zu-Ende-Verschlüsselung zwischen unseren Diensten. Und dafür gibt es in der Docker-Welt elegantere Wege.

Drei Sicherheitsebenen für Docker-Traffic

Bevor wir in die Methoden einsteigen, hilft eine kurze Einordnung. Du kannst Docker-Netzwerk-Traffic auf drei verschiedenen Ebenen absichern:

Anwendungsebene (TLS/mTLS): Jeder Dienst spricht verschlüsselt mit jedem anderen. Das ist die granularste und flexibelste Methode, erfordert aber, dass jeder Dienst TLS kann — oder dass du ihm einen TLS-fähigen Sidecar-Proxy zur Seite stellst.

Netzwerkebene (IPsec/WireGuard): Die Verschlüsselung passiert unterhalb der Anwendung. Die Container merken davon nichts, sie sprechen ganz normales HTTP. Der Netzwerk-Layer kümmert sich transparent um die Verschlüsselung.

Isolationsebene (Bridge-Netzwerke): Streng genommen keine Verschlüsselung, aber ein wichtiger Baustein: Du trennst Dienste in separate Docker-Netzwerke und kontrollierst, wer mit wem sprechen darf. Das reduziert die Angriffsfläche erheblich und ist in jeder der folgenden Methoden implizit enthalten.

Die ersten beiden Ebenen — TLS und IPsec/WireGuard — sind die, um die es in diesem Artikel geht. Die dritte solltest du ohnehin immer im Hinterkopf haben.

Docker Container Traffic verschlüsseln – Illustration 2

Methode 1: TLS zwischen Reverse-Proxy und Backend

Bei Traefik konfigurierst du die Backend-Verbindung über die serversTransport-Sektion. Dort kannst du ein eigenes CA-Zertifikat hinterlegen, mit dem Traefik die Backend-Zertifikate validiert:

serversTransport:
  rootCAs:
    - /etc/traefik/certs/internal-ca.crt

Nginx macht es ähnlich über proxy_ssl_trusted_certificate und proxy_ssl_verify. Auch hier brauchst du eine interne CA, deren Zertifikate auf allen beteiligten Containern als vertrauenswürdig gelten.

Der Vorteil dieses Ansatzes: Du musst die Backend-Container selbst kaum anfassen. Sie bekommen ein TLS-Zertifikat (wie das geht, zeige ich gleich bei Methode 2), und der Reverse-Proxy validiert es. Der Nachteil: Die Verschlüsselung endet am Proxy. Direkte Kommunikation zwischen zwei Backend-Containern — zum Beispiel wenn deine Weboberfläche direkt mit Ollama spricht — bleibt ungeschützt.

Für viele Setups reicht das trotzdem. Wenn dein Reverse-Proxy die einzige Brücke zwischen Außenwelt und deinen Diensten ist und die Dienste untereinander nicht kommunizieren, bist du mit Proxy-zu-Backend-TLS schon deutlich besser aufgestellt als vorher.

Methode 2: mTLS mit eigener interner PKI

Der nächste Schritt: Mutual TLS. Hier weisen sich beide Seiten gegenseitig mit Zertifikaten aus — nicht nur der Server gegenüber dem Client, sondern auch umgekehrt. Kein Dienst akzeptiert Verbindungen von einem Gegenüber, das kein gültiges Zertifikat der internen CA vorweisen kann.

Das klingt nach Overkill für ein Homelab. Aber mit Tools wie Smallstep step-ca ist der Aufbau einer eigenen internen PKI heute kein mehrtägiges Projekt mehr. Du startest step-ca als Docker-Container, initialisierst deine CA einmal, und verteilst dann automatisiert Zertifikate an deine Dienste.

Der Ablauf in der Praxis sieht so aus:

CA-Container starten: Du richtest step-ca als Docker-Service ein und erzeugst ein Root-CA-Zertifikat. Dieses Root-Zertifikat verteilst du an alle Container, die deiner internen PKI vertrauen sollen — das ist dein Vertrauensanker.
Dienst-Zertifikate ausstellen: Für jeden deiner Dienste (Ollama, Open WebUI, deine Tools) erzeugst du ein eigenes Server-Zertifikat, signiert von deiner internen CA. Die Zertifikate bindest du per Volume-Mount in die Container ein.
mTLS konfigurieren: Auf jedem Dienst aktivierst du mTLS — der Server verlangt ein Client-Zertifikat, der Client prüft das Server-Zertifikat. Beide Seiten validieren gegen das Root-CA-Zertifikat.
Automatisierung: step-ca bietet einen ACME-Endpoint, mit dem deine Dienste Zertifikate automatisch anfordern und erneuern können — ähnlich wie Let’s Encrypt, nur eben intern.

Der Charme von mTLS liegt in der Granularität. Du kannst pro Dienst entscheiden, wer mit wem sprechen darf. Ein kompromittierter IoT-Container ohne gültiges Zertifikat kann keine Verbindung zu deinem Ollama-API-Endpoint aufbauen — selbst wenn er im selben Docker-Netzwerk hängt.

Der Preis: mTLS erfordert, dass jeder beteiligte Dienst TLS kann. Nicht jede schlanke Container-Anwendung bringt native TLS-Unterstützung mit. In solchen Fällen hilft ein Sidecar-Proxy — ein kleiner Nginx- oder Caddy-Container, der vor dem eigentlichen Dienst sitzt und die TLS-Terminierung übernimmt. Das verdoppelt die Container-Zahl pro Dienst, funktioniert aber zuverlässig.

Für ein Ollama-Setup bedeutet das konkret: Da Ollama selbst keine native TLS-Unterstützung für eingehende Verbindungen mitbringt (Stand Juli 2026), stellst du einen schlanken Sidecar-Proxy wie Caddy oder Nginx davor. Dieser terminiert TLS für Ollama und reicht die Anfragen lokal weiter. Für echtes mTLS müssen Client und Proxy zusätzlich gegenseitige Zertifikatsprüfung konfigurieren.

Für besonders schützenswerte Daten ist mTLS mit eigener PKI die sauberste Lösung. Sie skaliert mit wachsender Dienst-Anzahl, wenn die Zertifikatserneuerung automatisiert ist.

Methode 3: Docker Overlay-Netzwerk mit IPsec

Falls du Docker Swarm nutzt (oder zumindest mehrere Docker-Hosts betreibst), gibt es einen noch transparenteren Weg: das Docker Overlay-Netzwerk mit eingebauter IPsec-Verschlüsselung.

Ein Overlay-Netzwerk spannt ein virtuelles Layer-2-Netz über mehrere Docker-Hosts. Container auf verschiedenen physischen Maschinen sehen sich gegenseitig, als wären sie im selben Subnetz. Normalerweise läuft der Traffic zwischen den Hosts unverschlüsselt. Mit einer einzigen Option änderst du das:

docker network create \
  --driver overlay \
  --opt encrypted \
  mein-sicheres-netzwerk

Das --opt encrypted aktiviert IPsec (genauer: AES-GCM über VXLAN) für den gesamten Traffic, der dieses Overlay-Netzwerk verlässt. Docker kümmert sich automatisch um die Schlüsselverteilung über den Swarm-Manager. Die Container selbst bekommen davon nichts mit — sie sprechen ganz normales HTTP, und die Verschlüsselung passiert auf der Netzwerkebene.

Der Overhead ist messbar, aber für Homelab-Verhältnisse meist irrelevant. Die Docker-Dokumentation spricht von einem „nicht vernachlässigbaren Performance-Verlust", Community-Benchmarks zeigen je nach Hardware und Traffic-Volumen einen Durchsatzverlust zwischen 5 und 15 Prozent. Auf einem typischen Homeserver mit Gigabit-Ethernet wirst du das bei LLM-Inferenzen nicht spüren — die Latenz der Modellberechnung dominiert ohnehin.

Der Haken: Overlay-Netzwerke mit Verschlüsselung setzen Docker Swarm voraus. Wenn du deine Container mit docker-compose auf einem einzelnen Host betreibst, steht dir diese Option nicht zur Verfügung. Für Single-Host-Setups sind die TLS-basierten Methoden der richtige Weg.

Trotzdem lohnt es sich, diese Methode im Hinterkopf zu behalten. Sobald dein Homelab wächst und du auf mehrere Maschinen verteilst — etwa einen separaten GPU-Server für LLM-Inferenzen und einen NAS für Storage —, wird das verschlüsselte Overlay-Netzwerk zur einfachsten Lösung für sichere Inter-Host-Kommunikation.

Methode 4: WireGuard als Container-Overlay

WireGuard ist der Underdog unter den Verschlüsselungstechniken — und gleichzeitig eine der flexibelsten. Statt auf Docker-eigene Mechanismen zu setzen, baust du ein eigenes verschlüsseltes Overlay-Netz mit WireGuard auf und hängst deine Container dort hinein.

Das LinuxServer.io-Team pflegt mit docker-wireguard ein fertiges Image, das diesen Ansatz zum Kinderspiel macht. Die Grundidee: Du startest einen WireGuard-Container, der ein wg0-Interface aufspannt. Andere Container können den Netzwerk-Stack dieses WireGuard-Containers mitbenutzen:

services:
  wireguard:
    image: lscr.io/linuxserver/wireguard:latest
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
    volumes:
      - ./wireguard-config:/config

  ollama:
    image: ollama/ollama:latest
    network_mode: "service:wireguard"

Durch network_mode: "service:wireguard" teilen sich Ollama und der WireGuard-Container denselben Netzwerk-Stack. Der gesamte Traffic von Ollama läuft jetzt durch den verschlüsselten WireGuard-Tunnel — transparent, ohne dass Ollama selbst etwas von TLS verstehen muss.

Das Gleiche machst du mit deinem Reverse-Proxy und allen anderen Diensten, die sicher kommunizieren sollen. Jeder Container, der im service:wireguard-Netzwerkmodus läuft, spricht automatisch verschlüsselt mit allen anderen Containern im selben WireGuard-Netz.

Die Stärke von WireGuard liegt in seiner Einfachheit und Performance. Der Kernel-modul-basierte Ansatz ist extrem schlank — der Durchsatzverlust liegt typischerweise unter 5 Prozent. Anders als IPsec brauchst du keinen Swarm. Und anders als TLS/mTLS musst du keine Anwendungen umkonfigurieren.

Der Nachteil: Du fügst einen weiteren Container als Abhängigkeit hinzu. Wenn der WireGuard-Container nicht läuft, sind alle daran hängenden Dienste nicht erreichbar. Und die network_mode: service:-Syntax schränkt die Docker-Netzwerkflexibilität etwas ein — du kannst nicht gleichzeitig ein benutzerdefiniertes Bridge-Netzwerk und den Service-Modus nutzen.

Für Homelabs, die schnell und unkompliziert eine transparente Verschlüsselungsschicht wollen, ist WireGuard eine exzellente Wahl. Besonders dann, wenn du Container von verschiedenen Maintainern nutzt, die von Haus aus kein TLS mitbringen.

Praxis: Ollama mit internem TLS absichern

Kommen wir zum konkreten Beispiel — dem Setup, das die meisten Leser interessieren dürfte: Du willst ein lokales LLM betreiben, sicher und ohne VLANs. Hier ist der Schritt-für-Schritt-Weg mit der TLS-Methode, weil sie den besten Kompromiss aus Sicherheit und Konfigurationsaufwand bietet.

Schritt 1: Interne CA aufsetzen

Statt dich mit OpenSSL-Handarbeit zu quälen, nutzt du ein fertiges Tool. Die einfachste Variante für ein Homelab ist mkcert, das lokal vertrauenswürdige Zertifikate erzeugt. Für den produktiveren Dauerbetrieb empfehle ich Smallstep step-ca, das auch automatische Renewals unterstützt.

# Mit mkcert (schnellster Einstieg)
mkcert -install
mkcert ollama.local openwebui.local

# Oder: step-ca als Docker-Service für automatisierte Renewals
docker run -d --name step-ca \
  -v step-data:/home/step \
  -p 9000:9000 \
  smallstep/step-ca

Schritt 2: Ollama mit Sidecar-TLS-Proxy absichern

Da Ollama selbst keine native TLS-Unterstützung für eingehende Verbindungen mitbringt (Stand Juli 2026), stellst du einen kleinen Sidecar-Proxy davor. Der Ollama-Container bleibt unverändert, ein zusätzlicher Caddy- oder Nginx-Container übernimmt die TLS-Terminierung und leitet lokal an Ollama weiter:

ollama:
  image: ollama/ollama:latest
  volumes:
    - ollama-data:/root/.ollama
  environment:
    - OLLAMA_HOST=0.0.0.0:11434

ollama-tls-proxy:
  image: caddy:latest
  volumes:
    - ./certs/ollama.crt:/etc/caddy/certs/server.crt
    - ./certs/ollama.key:/etc/caddy/certs/server.key
    - ./Caddyfile:/etc/caddy/Caddyfile
  ports:
    - "11435:11435"

Die Caddyfile des Sidecar-Proxys:

:11435 {
    tls /etc/caddy/certs/server.crt /etc/caddy/certs/server.key
    reverse_proxy ollama:11434
}

Schritt 3: Open WebUI mit Client-Zertifikaten verbinden

Open WebUI muss jetzt über den TLS-Proxy mit Ollama sprechen:

open-webui:
  image: ghcr.io/open-webui/open-webui:main
  environment:
  volumes:
    - OLLAMA_BASE_URL=https://ollama-tls-proxy:11435
  volumes:
    - ./certs/root-ca.crt:/usr/local/share/ca-certificates/internal-ca.crt:ro

Wichtig: Du musst sicherstellen, dass Open WebUI dem internen CA-Zertifikat vertraut. Das erreichst du durch das Mounten des Root-CA-Zertifikats und (je nach Container-Basis-Image) einen entsprechenden update-ca-certificates-Befehl im Entrypoint.

Schritt 4: Reverse-Proxy konfigurieren

Dein Caddy- oder Traefik-Reverse-Proxy terminiert weiterhin das externe TLS mit Let’s Encrypt. Für die Verbindung zu den Backends konfigurierst du jetzt HTTPS:

llm.deine-domain.de {
        transport http {
            tls
            tls_insecure_skip_verify
        }
    }
}

tls_insecure_skip_verify sollte kein Dauerzustand sein: Damit wird die Zertifikatsprüfung abgeschaltet. Binde stattdessen das Zertifikat deiner internen CA ein und konfiguriere den Proxy so, dass er sie prüft.

Wenn alle Hops sauber mit TLS und Zertifikatsprüfung konfiguriert sind, läuft der LLM-Traffic verschlüsselt — von der Browser-Anfrage über den Reverse-Proxy bis zum Ollama-Backend. Ein VLAN ersetzt das nicht, ergänzt die Absicherung aber sinnvoll.

Und das Beste: Die gleiche Konfiguration funktioniert für alle anderen Dienste in deinem Homelab. Nextcloud, Vaultwarden, Paperless-ngx — einmal die interne PKI aufgesetzt, kannst du jeden neuen Dienst in wenigen Minuten mit TLS ausstatten.

Vergleich der Methoden — was sich im Homelab wirklich lohnt

Nicht jede Methode passt zu jedem Setup. Hier eine ehrliche Gegenüberstellung, basierend auf praktischer Erfahrung mit verschiedenen Homelab-Konstellationen:

Methode	Aufwand	Sicherheitsniveau	Performance-Overhead	Ohne Swarm?
Proxy→Backend TLS	Gering	Mittel (nur Proxy→Backend)	Keiner	Ja
mTLS mit PKI	Mittel-Hoch	Hoch (alle Richtungen)	Minimal	Ja
Overlay + IPsec	Gering (wenn Swarm)	Hoch (komplett)	5-15%	Nein
WireGuard Overlay	Gering-Mittel	Hoch (komplett)	<5%	Ja

Für Single-Host-Homelabs führen TLS und WireGuard, während Overlay+IPsec nur im Swarm-Kontext sinnvoll ist. Viele Setups starten mit Proxy-zu-Backend-TLS und erweitern später gezielt.

Für ein typisches Single-Host-Homelab mit mehreren Diensten empfiehlt sich diese Staffelung:

Starte mit Proxy-zu-Backend-TLS. Das ist in 30 Minuten eingerichtet und schützt die kritischste Strecke — vom Reverse-Proxy zu deinen Diensten. Für Ollama und Co. reicht das in den meisten Bedrohungsmodellen. Du hast das grüne Schloss im Browser und die Gewissheit, dass die Daten auf dem Weg zum Backend nicht im Klartext durch das Docker-Netzwerk fliegen.

Ergänze mTLS, wenn deine Dienste wachsen. Sobald du mehr als eine Handvoll Container hast und Dienste auch untereinander kommunizieren — deine Monitoring-Tools mit Ollama, das Dashboard mit der Datenbank — lohnt sich der Sprung zu mTLS. Der Initialaufwand mit step-ca liegt bei etwa zwei Stunden, danach ist es Routine.

WireGuard als Universallösung für heterogene Setups. Wenn du Container von verschiedenen Quellen nutzt, die kein natives TLS mitbringen, oder wenn du ein Setup mit zwei physischen Maschinen betreibst, ist WireGuard die pragmatischste Wahl. Es verschlüsselt alles transparent, ohne dass du jeden Dienst einzeln umkonfigurieren musst.

Overlay+IPsec nur, wenn du sowieso Swarm nutzt. Docker Swarm bringt diese Funktion mit, und wenn deine Infrastruktur bereits darauf aufbaut, gibt es keinen Grund, sie nicht zu aktivieren. Für reine docker-compose-Setups lohnt der Umstieg auf Swarm allein für IPsec allerdings nicht.

FAQ

Brauche ich VLANs überhaupt noch, wenn ich TLS nutze?

VLANs und TLS lösen unterschiedliche Probleme. VLANs isolieren Netzwerke und verhindern, dass ein Gerät in Subnetz A überhaupt Pakete an Subnetz B senden kann. TLS verschlüsselt die Daten innerhalb eines Netzwerks. Idealerweise nutzt du beides — aber wenn du dich für eines entscheiden musst, liefert TLS den stärkeren Sicherheitsgewinn, weil es auch dann schützt, wenn jemand Zugriff auf dein Netzwerksegment erlangt.

Kann ich ein lokales LLM nutzen, ohne dass meine Prompts im Klartext durchs Netz gehen?

Ja. Mit den beschriebenen TLS-Methoden ist der gesamte Pfad vom Browser bis zum Ollama-Backend verschlüsselt, sofern alle Hops konsequent mit TLS und Zertifikatsprüfung laufen. Mit Wireshark oder tcpdump kannst du die Konfiguration kontrollieren: Vor TLS sind HTTP-Payloads lesbar, danach nicht mehr.

Wie hoch ist der Performance-Verlust durch TLS bei LLM-Inferenzen?

Vernachlässigbar. Die eigentliche Rechenzeit für eine LLM-Inferenz liegt im Bereich von mehreren Sekunden bis Minuten. Der TLS-Handshake passiert einmal pro Verbindung und kostet ein paar Millisekunden. Die symmetrische AES-Verschlüsselung des Datenstroms kostet auf modernen CPUs weniger als ein Prozent Durchsatz. Du wirst keinen messbaren Unterschied in der Antwortgeschwindigkeit deines Modells feststellen.

Was mache ich mit Containern, die kein natives TLS unterstützen?

Du stellst einen Sidecar-Proxy davor — einen kleinen Nginx- oder Caddy-Container, der im selben Docker-Netzwerk wie der Dienst läuft und die TLS-Verbindungen terminiert. Der ursprüngliche Container spricht dann unverschlüsselt mit dem Sidecar — aber diese Strecke ist nur noch ein lokaler Loopback, der den Container nicht verlässt.

Ist self-signed TLS im internen Netz ausreichend?

Für ein Homelab: ja, solange du die Zertifikate korrekt validierst. Der entscheidende Punkt ist nicht, ob ein Zertifikat von einer öffentlichen CA stammt, sondern ob deine Dienste es gegen einen vertrauenswürdigen Anker prüfen. Eine interne CA mit step-ca oder mkcert erfüllt diesen Zweck genauso gut wie Let’s Encrypt — nur eben ohne externe Abhängigkeit.

Lohnt sich der Aufwand für ein Homelab mit drei Containern?

Die Proxy-zu-Backend-TLS-Methode dauert 30 Minuten. Wenn du sensible Daten verarbeitest — persönliche Dokumente, Finanzinformationen, Gesundheitsdaten — lohnt sich das auf jeden Fall. Wenn dein LLM nur öffentliche Wikipedia-Artikel zusammenfasst und du keine kritischen Daten durchschleust, kannst du den Aufwand vertagen. Aber die Frage ist weniger „lohnt es sich jetzt?" als „will ich mich später ärgern, dass ich es nicht gemacht habe?"

Kann ich mehrere Methoden kombinieren?

Ja, das ist sogar sinnvoll. Ein typisches Setup: WireGuard als Basisschicht für die Netzwerk-Verschlüsselung, plus Proxy-zu-Backend-TLS für die besonders sensiblen Dienste. Du gewinnst Tiefenverteidigung: Fällt eine Schicht, greift die andere.

Brauche ich für mTLS einen separaten Docker-Host für die CA?

Nein. step-ca läuft problemlos als Container auf demselben Host. Wichtiger ist, dass du das Root-CA-Zertifikat und den privaten Schlüssel sicherst — idealerweise offline. Eine kompromittierte Root-CA macht das gesamte mTLS-Setup wertlos. Bewahre den Root-Key auf einem verschlüsselten USB-Stick oder in einem Hardware-Security-Modul auf, nicht dauerhaft im Container-Volume.

Welche KI-Tools aus Deutschland profitieren besonders von interner Verschlüsselung?

Alle selbst gehosteten Dienste, bei denen personenbezogene Daten verarbeitet werden, profitieren davon — vom lokalen LLM über Dokumentenanalyse bis zu eigenen Übersetzungsdiensten. Besonders relevant wird das Thema, wenn ein Dienst Zugriff auf private Dateien, E-Mails oder Kalender hat.

Ist das alles kompatibel mit meinem docker-compose-Setup?

Die TLS-Methoden, mTLS und WireGuard funktionieren alle mit docker-compose. Nur das verschlüsselte Overlay-Netzwerk setzt Docker Swarm voraus. Wenn du bisher alles mit docker-compose managst, kannst du bei deiner gewohnten Arbeitsweise bleiben.

Fazit

Am Anfang stand eine einfache Erkenntnis: Dein Reverse-Proxy verschlüsselt den Traffic nach draußen — aber nicht nach drinnen. Was zwischen deinen Containern passiert, ist ein blinder Fleck. Und in einem wachsenden Homelab mit immer mehr persönlichen Daten, die durch immer mehr Dienste fließen, wird dieser Fleck größer.

Die gute Nachricht: Du musst kein Netzwerk-Ingenieur sein, um das zu ändern. Weder brauchst du teure Managed Switches, noch eine VLAN-Infrastruktur, noch ein komplettes Netzwerk-Redesign. Eine interne CA, ein paar Zertifikate und zwei Konfigurationszeilen in deinem Reverse-Proxy reichen für den Einstieg.

Welchen Weg du gehst, hängt von deinem Setup ab. Mit drei Containern und einem Reverse-Proxy startest du mit Proxy-zu-Backend-TLS. Mit zehn Diensten und sensiblen Daten lohnt sich der Schritt zu mTLS. Und wenn du einfach alles verschlüsseln willst, ohne jeden Dienst einzeln anzufassen, ist WireGuard dein Freund.

Der erste Schritt ist immer derselbe: Öffne dein Terminal, wirf einen Blick auf deine Docker-Netzwerke, und frag dich, ob der Traffic, der da fließt, wirklich im Klartext durch dein Heimnetz sollte. Die Antwort kennst du jetzt.

Quellen

Passende Produktrecherchen

Für ein sicheres Homelab können diese Produktkategorien bei der Planung helfen:

Die Links sind Affiliate-Links. Wenn du über sie einkaufst, erhält kalika.de eine kleine Provision — für dich ändert sich der Preis nicht. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.

Docker Container Traffic verschlüsseln – Illustration 3