DockTail: Container per Label ins Tailnet heben – ohne offene Ports

Hallo, hier ist wieder Kora. Heute geht es um ein kleines Open-Source-Werkzeug, das mir sofort sympathisch war, weil es ein sehr konkretes Alltagsproblem löst: Wie bekomme ich meine Docker-Dienste erreichbar, ohne sie ins öffentliche Netz zu stellen?

Was DockTail macht

DockTail beobachtet den Docker-Daemon und wertet Labels mit dem Präfix docktail.* aus. Setzt man an einem Container die drei Basis-Labels für Aktivierung, Namen und Port, registriert das Tool den Dienst automatisch als Service im Tailscale-Tailnet. Die Anwendung bekommt damit einen festen Namen über MagicDNS – etwa jellyfin.tailnet-name.ts.net – sowie eine eigene virtuelle IPv4- und IPv6-Adresse.

Der Clou für alle, die Sicherheit ernst nehmen: Ports muss man auf dem Host gar nicht erst veröffentlichen. DockTail leitet direkt an die Container-IP im Docker-Netzwerk weiter. Startet ein Container neu oder ändert sich seine IP, zieht die Konfiguration automatisch nach. Diese Fummelei mit Listen aus Hostnamen und Portnummern, die irgendwann niemand mehr pflegt, entfällt also.

Warum das gegenüber den bisherigen Wegen aufgeräumter ist

Bisher kannte man im Tailscale-Umfeld vor allem zwei Muster: Entweder bekommt jede Anwendung einen eigenen Tailscale-Container als Sidecar, oder ein Proxy startet pro Container einen eingebetteten Tailscale-Knoten. Beides funktioniert, aber jede Anwendung taucht dann als eigenes Gerät in der Admin-Konsole auf. Wer zwanzig Container betreibt, hat zwanzig Geräte in der Liste – und entsprechend viel Rauschen.

DockTail geht den anderen Weg: ein Gerät pro Host, die Anwendungen erscheinen als Services. Das ist nicht nur hübscher in der Übersicht, es macht auch Policies und Tags handhabbarer. Und weil Services an keinen bestimmten Host gebunden sind, bleibt die Adresse gleich, wenn ein Dienst umzieht, redundante Hosts dazukommen oder man über mehrere Regionen verteilt. Genau das ist aus Betreibersicht interessant, weil Failover und Migration damit nicht mehr automatisch eine DNS-Änderung nach sich ziehen.

Protokolle und Zertifikate

Unterstützt werden HTTP, HTTPS, TCP sowie TCP mit TLS-Terminierung. Bei TCP-Diensten kann optional das PROXY-Protokoll genutzt werden, damit das Backend die tatsächliche Client-IP aus dem Tailnet sieht – wichtig für alles, was Logging, Rate-Limiting oder IP-basierte Regeln macht. Für HTTPS holt Tailscale die Zertifikate bei Let's Encrypt; zum Container selbst darf die Verbindung dann unverschlüsselt per HTTP laufen. Ob einem das reicht, hängt davon ab, wie sehr man dem Host-internen Netzwerk vertraut.

Die Sache mit dem Docker-Socket

Einen Punkt möchte ich ausdrücklich hervorheben, weil er gern unterschätzt wird: DockTail braucht Zugriff auf den Docker-Socket. In Beispielkonfigurationen ist der oft "read-only" eingebunden – das klingt beruhigend, verhindert aber keine schreibenden API-Aufrufe. Das Flag bezieht sich auf das Mount, nicht auf die API dahinter. Wer den Socket kontrolliert, kontrolliert faktisch den gesamten Docker-Daemon und damit den Host.

Für uns heißt das in der Praxis: Solche Tools gehören auf Hosts, deren Workload man ohnehin vertraut, und man sollte sich die Lieferkette des Images genauso genau ansehen wie bei jedem anderen privilegierten Container. Wer es strenger braucht, schaut sich Socket-Proxys mit Methodenfilterung an. Die Zugangsdaten für OAuth beziehungsweise die Tailscale-API übergibt man übrigens besser als Docker-Secret oder eingebundene Datei statt als Umgebungsvariable – das unterstützt DockTail explizit, und es ist eine gute Angewohnheit.

Voraussetzungen und Grenzen

Der Docker-Host muss selbst mit Tailscale verbunden sein und per Tags und Tailnet-Policy die Berechtigung haben, Services bereitzustellen. Die Service-Definitionen legt DockTail dann selbst an. Zu beachten: Tailscale-Services sind seit Februar 2026 allgemein verfügbar, nachdem sie im Oktober 2025 als Beta gestartet waren. Jeder Account – auch im Personal-Tarif – kann bis zu zehn Services anlegen, darüber hinaus nur auf Anfrage.

• Hauptplattform sind Linux-Hosts mit Docker, dort wird auch primär getestet.
• Installationswege gibt es außerdem für Unraid (Community-Plug-in mit Assistent für die Labels), TrueNAS SCALE ab 24.10, den Container Manager von Synology und Podman.
• Unter macOS und Windows ist zusätzlich ein Tailscale-Sidecar nötig.
• Docker Swarm wird nur eingeschränkt unterstützt, Kubernetes gar nicht.

Mein Fazit

Für Homelabs, kleine Entwicklungsumgebungen und interne Admin-Werkzeuge finde ich den Ansatz richtig gut: weniger offene Ports, weniger manuell gepflegte Reverse-Proxy-Konfiguration, weniger Geräte-Wildwuchs in der Konsole. Wer dagegen Kubernetes fährt oder bewusst keine Abhängigkeit von einem zentralen Cloud-Dienst für Schlüssel- und Policy-Verteilung eingehen will, ist mit klassischem Reverse Proxy plus eigenem WireGuard-Setup weiterhin besser bedient. Spannend bleibt der Gedanke dahinter allemal: Erreichbarkeit als Eigenschaft des Dienstes zu deklarieren statt als Loch in der Firewall.

Bis demnächst, eure Kora

Quelle: heise online