Teams, die das OpenClaw-Gateway auf einer schlanken Linux-Cloud-VM betreiben, wollen meist dasselbe: MCP und Streamable HTTP leben nur im Tailnet, ohne öffentlichen Listener auf dem Host oder in der Security Group. Das tragfähige Muster ist ein Docker-Compose-Stack, in dem das offizielle Tailscale-Image als Sidecar fungiert: Es übernimmt tailscale up, persistenten State unter einem Volume und Interface-Bring-up, während der Gateway-Container an die Bridge oder 127.0.0.1 bindet und niemals 0.0.0.0:443 ins Internet annonciert. Behandeln Sie die Provider-Firewall als nötig, aber nicht hinreichend — ports:-Mappings und systemd-Socket-Units können trotzdem Wege öffnen, die auf dem Papier der Security Group nicht sichtbar sind. Konkrete Image-Tags, Healthchecks und Ports hängen von der OpenClaw-Version ab, die Sie pinnen; dieser Artikel fasst die Netz- und Auth-Schichten für Ihr Runbook zusammen. Wie OpenClaw sich auf Docker versus native Dienste auf einem Remote-Mac abbildet, steht in
OpenClaw Remote-Mac-Bereitstellung: Installationspfade, Docker und lokaler Dauerbetrieb.
1. Compose-Sidecars: ports: darf die öffentliche Datenfläche nicht wieder öffnen
Sidecar und Gateway gehören auf dieselbe benutzerdefinierte Bridge, mit getrennten State-Verzeichnissen; teilen Sie niemals ein einziges /var/lib/tailscale zwischen zwei Containern. Der klassische Fußangel ist ports: "443:443" oder ein Gateway, das testweise an 0.0.0.0 bindet — die Cloud-Firewall kann perfekt sein, während Docker trotzdem einen Weg ins öffentliche Internet veröffentlicht. Bevorzugen Sie Loopback oder die interne Bridge-IP und erreichen Sie den Dienst über MagicDNS von anderen Tailnet-Mitgliedern. Wenn Sie TLS terminieren, soll die Terminierung auf einem Reverse-Proxy liegen, der nur innerhalb des Tailnets erreichbar ist, nicht per Host-Publish. Wenn Sie openclaw.json mit Minimalrechten und Tokens verschärfen, halten Sie dieselbe Disziplin ein wie bei den Netzregeln:
OpenClaw-Konfiguration mit Minimalrechten und reproduzierbarer doctor-Fehlersuche.
docker ps aus und prüfen Sie, dass nichts auf die öffentliche Host-Schnittstelle gemappt ist, bevor Sie Stunden in ACL- oder Zertifikatstuning investieren.2. Gateway im Tailnet binden: HTTPS und Bearer-Token schichten
Nach erfolgreichem tailscale up vergeben Sie Zertifikate mit tailscale cert oder einer internen Caddy-Instanz, damit Clients die Kette vertrauen statt selbstsignierte Dateien still zu akzeptieren. Injizieren Sie Token per Umgebungsvariable oder Docker-Secrets als Dateimount — niemals in Image-Layern backen. Terminieren Sie TLS vor dem Gateway, sollten Sie Authorization: Bearer sowohl im Proxy als auch im Gateway prüfen, damit ein falsch gerouteter Pfad die Auth nicht umgeht. Loggen Sie strukturierte 401-Antworten getrennt von TLS-Handshake-Fehlern, damit Bereitschaft nicht die falsche Schicht jagt. Rotieren Sie Token per Rolling Restart; langlebige Prozesse cachen alte Geheimnisse oft bis zum Austausch. Dokumentieren Sie gemeinsam mit API-Schlüsseln, wer den Tailscale-Auth-Key besitzt und wer ACLs ändern darf.
Taggen Sie Container mit Umgebung und Release-Hash, damit On-Call nicht raten muss, ob noch ein alter Sidecar ohne neuen ACL-Stand läuft. Für interne Clients lohnt sich ein kurzer „Happy-Path“-Smoke-Test nach jedem Zertifikatswechsel: gleicher Hostname, gleicher Pfad, nur neues Zertifikat — so erkennen Sie pinning- oder Trust-Store-Probleme früh, bevor Produktions-Agents den Gateway-Handshake massenhaft ablehnen.
3. Serve versus Funnel: Richtliniengrenzen explizit halten
tailscale serve ist in der Regel das richtige Primitive für rein tailnet-internen Zugriff. Funnel exponiert ausgewählte Pfade absichtlich ins öffentliche Internet. Wenn Compliance keine öffentliche Exposition verlangt, Funnel standardmäßig aus, in Policy blockieren und auf „temporäre“ Debug-Schalter auditieren. Unter Serve wirken falsch abgestimmte Hostnamen oder Pfadpräfixe relativ zur Gateway-Basis wie flackernde 404er oder Redirect-Loops, obwohl der Prozess gesund ist — MagicDNS-Namen, Serve-Pfade und OpenClaw-Routen gehören in dasselbe Change-Ticket.
4. Verbindungsfehler: Suchraum in fester Reihenfolge verkleinern
1) Im Sidecar tailscale status ausführen und prüfen, dass das gewünschte Tailnet ohne NeedsLogin aktiv ist. 2) Von einem anderen Mitglied ping auf die 100.x-Adresse und curl -vk https://maschinenname, um ACL-Verweigerungen von Anwendungsfehlern zu trennen. 3) Das Gateway direkt mit echtem Authorization-Header per curl treffen, damit TLS-Fehler nicht als 401 maskieren. 4) Wenn Streamable HTTP scheitert, stdio aber läuft, Idle-Timeouts und Body-Limits Ende-zu-Ende prüfen. Für Übungen eine ACL bewusst verschärfen, Logs erfassen, dann zurückrollen — Rollback sollte genauso skriptiert sein wie der Ausfall.
- Hat ein Sidecar-Neustart das State-Volume geleert und einen frischen Login erzwungen?
- Laufen versehentlich sowohl Host-
tailscaledals auch ein Container-Sidecar mit überlappenden Routen? - Wurden Cloud-Metadata-Endpunkte in „nur intern“-Routingtabellen gezogen?
Abschluss: Linux-Gateway, macOS für die schwere Hälfte
Das Gateway auf einer kleinen Linux-VM zu halten spart Kosten, aber Notarisierung, Codesigning und GUI-lastiges Debuggen bleiben Sache von macOS. Wenn Sie die Steuerungs-Container im Tailnet von Burst-Workloads auf einem dedizierten Mac mini trennen, profitieren Sie von Apple-Silicon-Speicherbandbreite und nativem Xcode-Werkzeugkasten, ohne eine Seite öffentlich zu exponieren. Mac mini bleibt im Leerlauf bei etwa vier Watt, arbeitet lautlos unter Dauerlast und stapelt Gatekeeper, SIP und FileVault für unbeaufsichtigte Maschinen. Wenn Sie diese Kombination ohne weiteren Schreibtisch-Rechner wollen, starten Sie mit einem Mac mini M4 in einer nahen Region auf der Macstripe-Startseite und hängen Sie ihn in dasselbe Tailnet wie diesen Compose-Stack.
