3.1 KiB
3.1 KiB
| read_when | summary | title | x-i18n | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Hub di rete: superfici del gateway, pairing, discovery e sicurezza | Rete |
|
Hub di rete
Questo hub collega la documentazione principale su come OpenClaw connette, associa e protegge i dispositivi tra localhost, LAN e tailnet.
Modello principale
La maggior parte delle operazioni passa attraverso il Gateway (openclaw gateway), un singolo processo a lunga esecuzione che possiede le connessioni ai canali e il control plane WebSocket.
- Prima il loopback: il WS del Gateway usa per impostazione predefinita
ws://127.0.0.1:18789. I bind non loopback richiedono un percorso di autenticazione gateway valido: autenticazione con segreto condiviso tramite token/password, oppure un deploymenttrusted-proxynon loopback configurato correttamente. - Un Gateway per host è consigliato. Per isolamento, esegui più gateway con profili e porte isolati (Gateway multipli).
- L'host Canvas viene servito sulla stessa porta del Gateway (
/__openclaw__/canvas/,/__openclaw__/a2ui/), protetto dall'autenticazione del Gateway quando il bind va oltre il loopback. - L'accesso remoto avviene tipicamente tramite tunnel SSH o VPN Tailscale (Accesso remoto).
Riferimenti chiave:
Pairing + identità
- Panoramica pairing (DM + nodi)
- Pairing dei nodi gestito dal Gateway
- CLI Devices (pairing + rotazione token)
- CLI Pairing (approvazioni DM)
Affidabilità locale:
- Le connessioni loopback locali dirette possono essere approvate automaticamente per il pairing per mantenere fluida l'esperienza sullo stesso host.
- OpenClaw ha anche un percorso ristretto backend/container-local self-connect per flussi helper attendibili con segreto condiviso.
- I client tailnet e LAN, inclusi i bind tailnet sullo stesso host, richiedono comunque un'approvazione esplicita del pairing.