Sie betreiben OpenClaw Gateway auf einer VPS- oder Heim-Instanz, wollen 18789 aber nicht ins öffentliche Internet hängen — und trotzdem per Notebook, weiterem Linux oder Mobilgerät auf CLI und WebSocket zugreifen, wie auf einen internen Dienst. Der Text erklärt privates Tailscale-Tailnet plus Standard-Loopback-Bindung (Grenzen, Token und Umgebungsvariablen, Remote-CLI) und trennt gezielt Fälle, in denen der Tunnel steht, RPC oder Sitzungen aber nicht. Zum Schluss: wie sich dieser Beitrag vom Artikel Cloudflare Tunnel + systemd abgrenzt und wann dediziert gemieteter Remote-Mac die bessere Rechenebene ist — inkl. Verweis auf dokumentierbare Zugriffspfade, wie sie in Betriebshandbüchern und bei Art. 30 DSGVO üblich anfallen.
OpenClaw Gateway hört standardmäßig auf 127.0.0.1 — die Kontrollfläche (HTTP/WebSocket) bleibt damit in der vom Betriebssystem vorgegebenen lokalen Domäne. Viele führen «Remote-CLI» ein, indem sie den Listener auf 0.0.0.0 stellen und die Lücke mit manueller Firewall füllen. Für Demos geht das; in Produktion vergrößern Sie damit Scanfläche, Token-Risiko und CORS-Fehlkonfigurationen in einem Schritt.
Scan-Noise: Öffentlich erreichbare Ports werden oft innerhalb von Stunden gefunden. Selbst mit starkem Token füllen Logs und SOC-Alarme mit Rauschen.
Konflikt mit «kleinster Fläche»: Der Blogbeitrag zur Gateway-Sicherheitshärtung setzt auf Loopback, Token-Rotation und Freigabe von Aktionen; ein offenes Bind ersetzt die erste Schicht.
Fehlerdiagnose verfälscht: Öffentlich kommen CDN, CGNAT und Unternehmensproxy dazu. Halb geschlossene Verbindungen und MTU passieren dann auf dem Weg, nicht in OpenClaw — falsche Wurzelsachen kosten Zeit.
Prüfspuren und Natürliche Personen: «Wer griff wann mit welcher öffentlichen IP an?» lässt sich schwer sauber Personen und Rollen zuordnen. Im Tailnet bündeln Sie Geräteidentität und ACL; das lässt sich in Verfahrens- und TOM-Dokumentationen sauberer abbilden (Transparenz- und Auskunftspflichten, interne Zugriffskontrolle).
Mehrere Gateways pro Host: Zweitinstanzen führen schneller zu Portkollisionen und vermischten Token.
Abgrenzung zu Remote-Mac: Dauerhaft schwere Lasten (Xcode, Simulator, großer Build-Cache) gehören auf einen dedizierten Mac-Knoten; das Gateway bleibt schlank orchestriert.
Besser: Listener auf dem Loopback lassen, Erreichbarkeit über ein kontrolliertes privates Netz (Tailscale o. ä.) — vergleichbar mit einer Datenbank nur auf 127.0.0.1 und Zugriff per SSH-Tunnel. Kennen Sie Cloudflare Tunnel, lesen Sie parallel Linux-VPS, systemd, Cloudflare Tunnel zum Thema Kante; dieser Text fokussiert reines Tailnet und Loopback.
| Aspekt | Loopback + Tailscale | Öffentlicher Bind | Cloudflare Tunnel |
|---|---|---|---|
| Vertrauensmodell | Tailnet-Identität + ACL, standardmäßig privat | Firewall + Token, große Angriffsfläche | Edge-Identität und Tunnel-Credentials, eher Internet-Eingang |
| Betriebsaufwand | Mittel: ACL und Hostnamen | Start simpel, langfristig riskant | Über DNS, Zertifikate und Rückrouten: mittel–hoch |
| Passend zur OpenClaw-Defaultkonfig | Hoch, kein Bind-Wechsel nötig | Niedrig, lenkt zu 0.0.0.0 | Mittel: Tunnel zeigt auf Loopback-Port |
| Typische Nutzung | Einzelpersonen, kleine Teams, interne Orchestrierung | Produktion nicht empfohlen | Öffentlicher, kontrollierter Eingang |
Der Tunnel behebt das Routing, nicht die Authentifizierung; Token und Ausführungsfreigabe bleiben vollumfänglich nötig.
Tailscale fasst Geräte in ein vertrauenswürdiges Set und liefert stabile Hostnamen für den 100.x-Bereich; es ersetzt aber keine Gateway-Tokens. Breite ACLs (z. B. *:*) erzeugen im Tailnet intern wieder eine «Minipublic-Fläche».
2026 tauchen oft Subnet-Router und Exit-Node auf: der Router hebt private RFC1918-Subnetze ins Tailnet, die Exit-Node leitet ausgewählten Internetverkehr. Liegt die Datenbank in derselben VPC wie das Gateway, Ihr Notebook aber nur im Tailnet, zählt «wer darf wohin?» doppelt — sonst wähnt man «Gateway curl’t die DB, Remote-CLI liefert 500», obwohl ACL nur asymmetrisch fehlt.
Häufig: MagicDNS und Suchdomains kollidieren mit Firmen-DNS, der *.ts.net umleitet. Beim Test parallel öffentlichen Resolver und Tailscale-DNS (z. B. per dig) abgleichen, damit Sie «DNS vermischt» nicht fälschlich als Sitzungsfehler lesen. Festgeschriebene Häkchen im Runbook sparen Wiederholungen und erleichtern spätere Auskunft, wer wann Zugang prüfen soll.
Auf dem Gateway-Host Tailscale installieren und anmelden; vom anderen Rechner im selben Tailnet (Notebook) ping und tailscale ping und RTT prüfen. Im Admin-Portal prüfen: passende Tags, MagicDNS, und ob die ACL TCP 18789 (oder Ihren Port) explizit von der Ops-Gruppe zum Tag des Gateways freigibt.
// ACL-Ausschnitt: nur tag:ops an Gateway-Port 18789
{
"groups": { "group:ops": ["alice@github", "bob@github"] },
"tagOwners": { "tag:gateway": ["group:ops"] },
"acls": [
{
"action": "accept",
"src": ["tag:ops"],
"dst": ["tag:gateway:18789"]
}
]
}
Hinweis: Nur die Form, nicht Ihre vollständige Policy. Echte Regeln brauchen Exit-Node, Subnet-Routen und Rechte minimaler Geräte; nach Änderungen am Tailnet ggf. Gerät neu anbinden und erneut testen.
Zur Abnahme in der Änderung: ① Prozess lauscht weiter 127.0.0.1:18789; ② vom Notebook aus ist der Health-Check über die Tailnet-Adresse (nicht per SSH-Portweiterleitung) erreichbar — konkreter Pfad je Version; ③ öffentliche Security-Group/ Firewall hat keinen eingehenden 18789. Läuft Ihr Eingang trotzdem stumm, siehe Kanal-Probe, Pairing, dmPolicy — anderes Problem, gleiche Sorgfalt.
Voraussetzung: openclaw doctor lokal sauber. Fehlt der Erstlauf, zuerst plattformübergreifende Installation und Fehlerbehebung, danach hierher zurück.
Listener prüfen: lsof -nP -iTCP:18789 -sTCP:LISTEN muss 127.0.0.1 zeigen. Steht *:18789, zuerst Konfiguration straffen, dann tunneln.
Token-Quelle: OPENCLAW_GATEWAY_TOKEN bevorzugt per Umgebung injizieren, nicht dauerhaft in synchronisierte Config-Repos legen, falls diese personenbezogene Metadaten enthalten (Minimierung, Zugriffsbeschränkung im Sinne gängiger Verarbeitungsdokumentation).
Remote im Client: in ~/.openclaw/openclaw.json (CLI-Version laut --help) remote mit tailnet-Hostname und Port; ws:// bzw. wss:// an interne Richtlinien anpassen.
Port-Variable: bei Nicht-Standard-Port OPENCLAW_GATEWAY_PORT client- und serverseitig identisch, sonst «doctor ok, Remote falscher Port».
TLS wirklich beenden: hinter dem Tailnet-Reverse-Proxy müssen WebSocket-Upgrade-Header intakt bleiben.
Protokoll-Schnittmenge: gateway status, doctor und ein gescheiterter Fernversuch in einem Ticket; hilft bei Versionsupgrades und bei Audit-Nachweisen, welches Setup geprüft wurde.
// Beispiel clientseitig ~/.openclaw/openclaw.json (Feldnamen: offizielles CLI)
{
"gateway": {
"remote": {
"url": "ws://openclaw-gateway.tailnet-1234.ts.net:18789",
"token": "per-env-oder-Keychain-statt-klartext"
}
}
}
Hinweis: Schweres Build- und I/O-Profil auf einem kleinen VPS bündelt Risiko. Dauerhaft xcodebuild und großer Modell- oder Artefakt-Cache gehören auf dedizierten Remote-Mac, das Gateway bleibt Sitzung und Werkzeuge. Disk und Region: Mac-Mini-Mietpreise.
| Beobachtung | Zuerst prüfen | Maßnahme |
|---|---|---|
| tailscale ping ok, CLI timeout | Port in ACL, lokale Firewall / Forwarding | Erst lokalen Loopback, dann nach außen stufen |
| HTTP 401 | Token, env in systemd-Unit | Environment= an Shell und Dienst anpassen |
| WebSocket fällt sofort / gateway closed (1000) | Version, Scope, Sitzung | gateway closed (1000) befolgen |
| Kanäle grün, keine Nachrichten | Pairing, dmPolicy | Kanal-Subbefehle und Richtlinientabelle (siehe verlinkter Beitrag) |
Fällt Remote-CLI nach einem Minor-Update plötzlich aus, vergleichen Sie Release-Notes, Standardports und ggf. Rollback, bevor Sie ACL endlos anpassen — sonst entsteht ein Ticket voll Falschalarme.
18789 (Release-Notes prüfen). Jede Abweichung muss in systemd, Compose und remote gleichlauten, sonst «halbe Umgebung, alter Port».tag:gateway in ACL skaliert; im Runbook festhalten: Offboarding = Gerät im Tailnet entfernen, Token/Keys rotieren, damit personen- und dienstbezogene Wechsel belegbar bleiben.Nur nackt öffentlicher Bind oder viel zu weite tailnet-ACLs machen die Agent-Steuerfläche 2026 schlecht prüfbar; alles Rechenklima auf demselben winzigen VPS zu bündeln, stößt an RAM und Plattentempo. Fürs erste fehlt Identitäts- und Netztiefe, fürs zweite fehlt skalierbarer Anwendungs-CPU-Raum — wie er bei dediziertem NodeMini Cloud-Mac eher verfügbar ist, wenn Ihre Verarbeitungstätigkeit dauerhaft Xcode- und Speicherfäden zieht.
Sinnvoll: leichtes Gateway, Zugriff über Tailnet mit strenger ACL, schwere Werkzeuge auf dedizierter macOS-Instanz. Dafür bieten feste Mietstufen und klare Prozesse, die sich in Dienstleister- und ggf. Auftragsverarbeitungsvereinbarungen benennen lassen, oft mehr Ruhe als Bastel-Metal.
Am Zielrechner landet der Verkehr aus dem tailnet, die lokale Weiterleitung geht an 127.0.0.1:18789 — kein Wechsel der Bind-IP nötig. Wichtig bleiben ACL, Host-Firewall und Token. Für Rechen- und Flächenfragen: Mac-Mini-Mietpreise.
Der Tunnel-Artikel: sicherer Weg vom Internet ins interne Service; dieser: nur im Tailnet und mit Loopback. Je nach Szenario eines wählen oder in Schichten kombinieren — nicht mehrere unklare Authentifizierungsketten übereinanderstapeln.
Im Blog über OpenClaw-Filter sortieren. Für Konto, SSH und Nutzung der Cloud-Instanzen: Hilfezentrum Cloud-Mac.