3.2 KiB
3.2 KiB
| read_when | summary | title | x-i18n | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Centrum sieciowe: powierzchnie Gateway, parowanie, wykrywanie i bezpieczeństwo | Sieć |
|
Centrum sieciowe
To centrum linkuje główną dokumentację opisującą, jak OpenClaw łączy, paruje i zabezpiecza urządzenia przez localhost, LAN i tailnet.
Model podstawowy
Większość operacji przepływa przez Gateway (openclaw gateway), pojedynczy długotrwale działający proces, który zarządza połączeniami kanałów i płaszczyzną sterowania WebSocket.
- Najpierw loopback: Gateway WS domyślnie działa pod
ws://127.0.0.1:18789. Powiązania inne niż loopback wymagają poprawnej ścieżki auth gateway: auth tokenem/hasłem opartym na współdzielonym sekrecie lub poprawnie skonfigurowanego wdrożeniatrusted-proxyspoza loopback. - Zalecany jest jeden Gateway na host. Dla izolacji uruchamiaj wiele gateway z izolowanymi profilami i portami (Wiele Gateway).
- Host canvas jest serwowany na tym samym porcie co Gateway (
/__openclaw__/canvas/,/__openclaw__/a2ui/), chroniony przez auth Gateway przy bindzie wykraczającym poza loopback. - Dostęp zdalny to zwykle tunel SSH albo Tailscale VPN (Dostęp zdalny).
Kluczowe dokumentacje:
Parowanie + tożsamość
- Przegląd parowania (DM + Node)
- Parowanie Node zarządzane przez Gateway
- CLI devices (parowanie + rotacja tokenów)
- CLI pairing (zatwierdzanie DM)
Zaufanie lokalne:
- Bezpośrednie lokalne połączenia loopback mogą być automatycznie zatwierdzane do parowania, aby zapewnić płynny UX na tym samym hoście.
- OpenClaw ma też wąską ścieżkę lokalnego samopołączenia backend/kontener dla zaufanych przepływów pomocniczych ze współdzielonym sekretem.
- Klienci tailnet i LAN, w tym bindy tailnet na tym samym hoście, nadal wymagają jawnego zatwierdzenia parowania.