3.2 KiB
3.2 KiB
| read_when | summary | title | x-i18n | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Netzwerk-Hub: Gateway-Oberflächen, Pairing, Discovery und Sicherheit | Netzwerk |
|
Netzwerk-Hub
Dieser Hub verlinkt die Kerndokumentation dazu, wie OpenClaw Geräte über localhost, LAN und Tailnet hinweg verbindet, pairt und absichert.
Kernmodell
Die meisten Vorgänge laufen über das Gateway (openclaw gateway), einen einzelnen langlebigen Prozess, der Channel-Verbindungen und die WebSocket-Control-Plane besitzt.
- Loopback first: Das Gateway-WS verwendet standardmäßig
ws://127.0.0.1:18789. Nicht-loopback-Bindings erfordern einen gültigen Gateway-Authentifizierungspfad: Shared-Secret- Token-/Passwort-Authentifizierung oder eine korrekt konfigurierte nicht-loopback-trusted-proxy-Bereitstellung. - Ein Gateway pro Host wird empfohlen. Für Isolation betreiben Sie mehrere Gateways mit isolierten Profilen und Ports (Multiple Gateways).
- Canvas-Host wird auf demselben Port wie das Gateway bereitgestellt (
/__openclaw__/canvas/,/__openclaw__/a2ui/), geschützt durch Gateway-Authentifizierung, wenn er über loopback hinaus gebunden ist. - Remote-Zugriff erfolgt typischerweise über SSH-Tunnel oder Tailscale VPN (Remote Access).
Wichtige Referenzen:
Pairing + Identität
- Pairing overview (DM + nodes)
- Gateway-owned node pairing
- Devices CLI (pairing + token rotation)
- Pairing CLI (DM approvals)
Lokales Vertrauen:
- Direkte lokale loopback-Verbindungen können für Pairing automatisch genehmigt werden, damit die UX auf demselben Host reibungslos bleibt.
- OpenClaw hat außerdem einen engen backend-/container-lokalen Self-Connect-Pfad für vertrauenswürdige Shared-Secret-Helper-Flows.
- Tailnet- und LAN-Clients, einschließlich Tailnet-Bindings auf demselben Host, erfordern weiterhin eine explizite Pairing-Genehmigung.