From 75fe586f8470ba269d352e6a8ee06f6beab2e711 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Wed, 29 Apr 2026 14:34:45 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/security/network-proxy.md | 122 +++++++++++++++--------------- 1 file changed, 61 insertions(+), 61 deletions(-) diff --git a/docs/uk/security/network-proxy.md b/docs/uk/security/network-proxy.md index 84d49b6f0..2d9c13ad3 100644 --- a/docs/uk/security/network-proxy.md +++ b/docs/uk/security/network-proxy.md @@ -1,53 +1,53 @@ --- read_when: - - Вам потрібен багаторівневий захист від SSRF та атак повторного прив’язування DNS + - Вам потрібен багаторівневий захист від атак SSRF і повторного прив’язування DNS - Налаштування зовнішнього прямого проксі для трафіку середовища виконання OpenClaw -summary: Як маршрутизувати HTTP- і WebSocket-трафік середовища виконання OpenClaw через фільтрувальний проксі, керований оператором +summary: Як спрямувати HTTP- і WebSocket-трафік середовища виконання OpenClaw через фільтрувальний проксі, керований оператором title: Мережевий проксі x-i18n: - generated_at: "2026-04-29T11:03:53Z" + generated_at: "2026-04-29T14:34:02Z" model: gpt-5.5 provider: openai - source_hash: b653991b31793a7ac0a8c45ff9bb2fa24288acc8835aefe0031eb218453380ec + source_hash: d5f6c2ba03ef9826675bb82957be21ec690631fcf5eca1e99775c3c145cd1531 source_path: security/network-proxy.md workflow: 16 --- # Мережевий проксі -OpenClaw може спрямовувати runtime-трафік HTTP і WebSocket через прямий проксі, керований оператором. Це додатковий необов’язковий захист для розгортань, яким потрібні централізований контроль вихідного трафіку, сильніший захист від SSRF і краща аудитованість мережі. +OpenClaw може спрямовувати runtime HTTP- і WebSocket-трафік через керований оператором прямий проксі. Це необов’язковий додатковий рівень захисту для розгортань, яким потрібні централізований контроль вихідного трафіку, сильніший захист від SSRF і краща можливість аудиту мережі. -OpenClaw не постачає, не завантажує, не запускає, не налаштовує й не сертифікує проксі. Ви запускаєте проксі-технологію, яка підходить вашому середовищу, а OpenClaw спрямовує через неї звичайні локальні для процесу клієнти HTTP і WebSocket. +OpenClaw не постачає, не завантажує, не запускає, не налаштовує й не сертифікує проксі. Ви запускаєте ту проксі-технологію, яка підходить вашому середовищу, а OpenClaw спрямовує через неї звичайні локальні для процесу HTTP- і WebSocket-клієнти. ## Навіщо використовувати проксі? -Проксі дає операторам одну точку мережевого контролю для вихідного трафіку HTTP і WebSocket. Це може бути корисно навіть поза посиленням захисту від SSRF: +Проксі дає операторам одну точку мережевого контролю для вихідного HTTP- і WebSocket-трафіку. Це може бути корисно навіть поза посиленням захисту від SSRF: -- Централізована політика: підтримуйте одну політику вихідного трафіку замість того, щоб покладатися на те, що кожне місце виклику HTTP в застосунку правильно застосує мережеві правила. -- Перевірки під час з’єднання: оцінюйте призначення після DNS-резолюції та безпосередньо перед тим, як проксі відкриє upstream-з’єднання. -- Захист від DNS rebinding: зменшуйте проміжок між DNS-перевіркою на рівні застосунку та фактичним вихідним з’єднанням. -- Ширше покриття JavaScript: спрямовуйте звичайні `fetch`, `node:http`, `node:https`, WebSocket, axios, got, node-fetch і подібні клієнти через той самий шлях. +- Централізована політика: підтримуйте одну політику вихідного трафіку замість того, щоб покладатися на коректне застосування мережевих правил у кожному місці HTTP-виклику застосунку. +- Перевірки під час підключення: оцінюйте призначення після DNS-резолюції та безпосередньо перед тим, як проксі відкриє upstream-з’єднання. +- Захист від DNS rebinding: зменшуйте розрив між DNS-перевіркою на рівні застосунку та фактичним вихідним з’єднанням. +- Ширше покриття JavaScript: спрямовуйте звичайні `fetch`, `node:http`, `node:https`, WebSocket, axios, got, node-fetch і подібні клієнти одним шляхом. - Аудитованість: журналюйте дозволені й заборонені призначення на межі вихідного трафіку. -- Операційний контроль: застосовуйте правила призначень, сегментацію мережі, обмеження швидкості або allowlist для вихідного трафіку без повторної збірки OpenClaw. +- Операційний контроль: застосовуйте правила призначень, сегментацію мережі, обмеження швидкості або allowlist вихідного трафіку без перебудови OpenClaw. -OpenClaw і далі зберігає захист від SSRF на рівні застосунку, зокрема `fetchWithSsrFGuard`. Маршрутизація через проксі є додатковим захисним обмеженням на рівні процесу для звичайного вихідного трафіку HTTP і WebSocket, а не заміною захищених fetch-викликів або мережевої пісочниці на рівні ОС. +Маршрутизація через проксі є guardrail на рівні процесу для звичайного вихідного HTTP- і WebSocket-трафіку. Вона дає операторам fail-closed шлях для спрямування підтримуваних JavaScript HTTP-клієнтів через власний фільтрувальний проксі, але не є мережевою пісочницею на рівні ОС і не означає, що OpenClaw сертифікує політику призначень проксі. ## Як OpenClaw спрямовує трафік -Коли `proxy.enabled=true` і налаштовано URL проксі, захищені runtime-процеси, як-от `openclaw gateway run`, `openclaw node run` і `openclaw agent --local`, спрямовують звичайний вихідний трафік HTTP і WebSocket через налаштований проксі: +Коли `proxy.enabled=true` і налаштовано URL проксі, захищені runtime-процеси, як-от `openclaw gateway run`, `openclaw node run` і `openclaw agent --local`, спрямовують звичайний вихідний HTTP- і WebSocket-трафік через налаштований проксі: ```text -OpenClaw process - fetch -> operator-managed filtering proxy -> public internet - node:http and https -> operator-managed filtering proxy -> public internet - WebSocket clients -> operator-managed filtering proxy -> public internet +Процес OpenClaw + fetch -> керований оператором фільтрувальний проксі -> публічний інтернет + node:http і https -> керований оператором фільтрувальний проксі -> публічний інтернет + WebSocket-клієнти -> керований оператором фільтрувальний проксі -> публічний інтернет ``` -Публічним контрактом є поведінка маршрутизації, а не внутрішні хуки Node, використані для її реалізації. Клієнти WebSocket площини керування OpenClaw Gateway використовують вузький прямий шлях для local loopback Gateway RPC-трафіку, коли URL Gateway використовує `localhost` або літеральну loopback IP-адресу, як-от `127.0.0.1` чи `[::1]`. Цей шлях площини керування має мати змогу досягати loopback Gateway навіть тоді, коли операторський проксі блокує loopback-призначення. Звичайні runtime-запити HTTP і WebSocket і далі використовують налаштований проксі. +Публічний контракт — це поведінка маршрутизації, а не внутрішні хуки Node, які використовуються для її реалізації. Клієнти WebSocket площини керування OpenClaw Gateway використовують вузький прямий шлях для трафіку Gateway RPC через local loopback, коли URL Gateway використовує `localhost` або буквальний loopback IP, як-от `127.0.0.1` чи `[::1]`. Цей шлях площини керування має бути здатен досягати loopback Gateway, навіть коли проксі оператора блокує loopback-призначення. Звичайні runtime HTTP- і WebSocket-запити все одно використовують налаштований проксі. -Сам URL проксі має використовувати `http://`. HTTPS-призначення все одно підтримуються через проксі за допомогою HTTP `CONNECT`; це лише означає, що OpenClaw очікує звичайний HTTP-слухач прямого проксі, як-от `http://127.0.0.1:3128`. +Сам URL проксі має використовувати `http://`. HTTPS-призначення все ще підтримуються через проксі за допомогою HTTP `CONNECT`; це лише означає, що OpenClaw очікує звичайний HTTP-слухач прямого проксі, як-от `http://127.0.0.1:3128`. -Поки проксі активний, OpenClaw очищає `no_proxy`, `NO_PROXY` і `GLOBAL_AGENT_NO_PROXY`. Ці списки обходу базуються на призначенні, тому залишення там `localhost` або `127.0.0.1` дозволило б високоризиковим SSRF-цілям оминути фільтрувальний проксі. +Поки проксі активний, OpenClaw очищає `no_proxy`, `NO_PROXY` і `GLOBAL_AGENT_NO_PROXY`. Ці списки обходу базуються на призначеннях, тому залишення там `localhost` або `127.0.0.1` дозволило б високоризиковим SSRF-цілям оминути фільтрувальний проксі. Під час завершення роботи OpenClaw відновлює попереднє проксі-середовище та скидає кешований стан маршрутизації процесу. @@ -67,9 +67,9 @@ OPENCLAW_PROXY_URL=http://127.0.0.1:3128 openclaw gateway run `proxy.proxyUrl` має пріоритет над `OPENCLAW_PROXY_URL`. -Якщо `enabled=true`, але не налаштовано дійсний URL проксі, захищені команди не запускаються замість того, щоб повертатися до прямого мережевого доступу. +Якщо `enabled=true`, але не налаштовано чинний URL проксі, захищені команди не запускаються, замість того щоб повертатися до прямого доступу до мережі. -Для керованих служб Gateway, запущених через `openclaw gateway start`, краще зберігати URL у конфігурації: +Для керованих служб gateway, запущених через `openclaw gateway start`, бажано зберігати URL у конфігурації: ```bash openclaw config set proxy.enabled true @@ -78,9 +78,9 @@ openclaw gateway install --force openclaw gateway start ``` -Резервний варіант через середовище найкраще підходить для запусків у передньому плані. Якщо ви використовуєте його з установленою службою, помістіть `OPENCLAW_PROXY_URL` у тривале середовище служби, наприклад `$OPENCLAW_STATE_DIR/.env` або `~/.openclaw/.env`, а потім перевстановіть службу, щоб launchd, systemd або Scheduled Tasks запускали gateway із цим значенням. +Резервний варіант із середовищем найкраще підходить для запусків у foreground. Якщо ви використовуєте його з інстальованою службою, помістіть `OPENCLAW_PROXY_URL` у довготривале середовище служби, як-от `$OPENCLAW_STATE_DIR/.env` або `~/.openclaw/.env`, а потім перевстановіть службу, щоб launchd, systemd або Scheduled Tasks запускали gateway з цим значенням. -Для команд `openclaw --container ...` OpenClaw передає `OPENCLAW_PROXY_URL` у дочірній CLI, націлений на контейнер, коли це значення встановлено. URL має бути доступним ізсередини контейнера; `127.0.0.1` вказує на сам контейнер, а не на хост. OpenClaw відхиляє loopback URL проксі для команд, націлених на контейнер, якщо ви явно не перевизначите цю перевірку безпеки. +Для команд `openclaw --container ...` OpenClaw передає `OPENCLAW_PROXY_URL` у дочірній CLI, призначений для контейнера, коли його задано. URL має бути доступний зсередини контейнера; `127.0.0.1` посилається на сам контейнер, а не на хост. OpenClaw відхиляє loopback URL проксі для команд, призначених для контейнера, якщо ви явно не перевизначите цю перевірку безпеки. ## Вимоги до проксі @@ -89,44 +89,44 @@ openclaw gateway start Налаштуйте проксі так, щоб він: - Прив’язувався лише до loopback або приватного довіреного інтерфейсу. -- Обмежував доступ так, щоб ним могли користуватися лише процес OpenClaw, хост, контейнер або службовий обліковий запис. -- Самостійно резолвив призначення та блокував IP-адреси призначення після DNS-резолюції. -- Застосовував політику під час з’єднання як для звичайних HTTP-запитів, так і для HTTPS-тунелів `CONNECT`. -- Відхиляв обходи на основі призначення для loopback, приватних, link-local, metadata, multicast, зарезервованих або документаційних діапазонів. -- Уникав allowlist імен хостів, якщо ви не повністю довіряєте шляху DNS-резолюції. -- Журналював призначення, рішення, статус і причину без журналювання тіл запитів, заголовків авторизації, cookie або інших секретів. -- Тримав політику проксі під контролем версій і перевіряв зміни як чутливу до безпеки конфігурацію. +- Обмежував доступ так, щоб його могли використовувати лише процес OpenClaw, хост, контейнер або службовий обліковий запис. +- Самостійно резолвив призначення й блокував IP-адреси призначень після DNS-резолюції. +- Застосовував політику під час підключення як для звичайних HTTP-запитів, так і для HTTPS-тунелів `CONNECT`. +- Відхиляв обходи на основі призначення для loopback, приватних, link-local, metadata, multicast, reserved або documentation діапазонів. +- Уникав allowlist імен хостів, якщо ви повністю не довіряєте шляху DNS-резолюції. +- Журналював призначення, рішення, статус і причину без журналювання тіл запитів, заголовків авторизації, cookies або інших секретів. +- Тримав політику проксі під контролем версій і переглядав зміни як конфігурацію, чутливу до безпеки. ## Рекомендовані заблоковані призначення Використовуйте цей denylist як відправну точку для будь-якого прямого проксі, firewall або політики вихідного трафіку. -Логіка класифікатора на рівні застосунку OpenClaw розташована в `src/infra/net/ssrf.ts` і `src/shared/net/ip.ts`. Відповідні хуки паритету: `BLOCKED_HOSTNAMES`, `BLOCKED_IPV4_SPECIAL_USE_RANGES`, `BLOCKED_IPV6_SPECIAL_USE_RANGES`, `RFC2544_BENCHMARK_PREFIX` і вбудована обробка sentinel для IPv4 для NAT64, 6to4, Teredo, ISATAP і IPv4-mapped форм. Ці файли є корисними довідковими матеріалами під час підтримки зовнішньої політики проксі, але OpenClaw не експортує й не застосовує ці правила у вашому проксі автоматично. +Логіка класифікатора OpenClaw на рівні застосунку міститься в `src/infra/net/ssrf.ts` і `src/shared/net/ip.ts`. Відповідні хуки parity — це `BLOCKED_HOSTNAMES`, `BLOCKED_IPV4_SPECIAL_USE_RANGES`, `BLOCKED_IPV6_SPECIAL_USE_RANGES`, `RFC2544_BENCHMARK_PREFIX` і вбудована обробка sentinel IPv4 для NAT64, 6to4, Teredo, ISATAP і IPv4-mapped форм. Ці файли є корисними довідниками під час підтримки зовнішньої політики проксі, але OpenClaw не експортує й не застосовує ці правила автоматично у вашому проксі. -| Діапазон або хост | Чому блокувати | -| ------------------------------------------------------------------------------------ | ---------------------------------------------------- | -| `127.0.0.0/8`, `localhost`, `localhost.localdomain` | IPv4 loopback | -| `::1/128` | IPv6 loopback | -| `0.0.0.0/8`, `::/128` | Невизначені адреси та адреси цієї мережі | -| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` | Приватні мережі RFC1918 | -| `169.254.0.0/16`, `fe80::/10` | Link-local адреси та поширені шляхи cloud metadata | -| `169.254.169.254`, `metadata.google.internal` | Служби cloud metadata | -| `100.64.0.0/10` | Спільний адресний простір carrier-grade NAT | -| `198.18.0.0/15`, `2001:2::/48` | Діапазони для бенчмаркінгу | -| `192.0.0.0/24`, `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, `2001:db8::/32` | Діапазони special-use і документаційні діапазони | -| `224.0.0.0/4`, `ff00::/8` | Multicast | -| `240.0.0.0/4` | Зарезервований IPv4 | -| `fc00::/7`, `fec0::/10` | Локальні/приватні діапазони IPv6 | -| `100::/64`, `2001:20::/28` | Діапазони IPv6 discard і ORCHIDv2 | -| `64:ff9b::/96`, `64:ff9b:1::/48` | Префікси NAT64 із вбудованим IPv4 | -| `2002::/16`, `2001::/32` | 6to4 і Teredo із вбудованим IPv4 | -| `::/96`, `::ffff:0:0/96` | IPv4-compatible і IPv4-mapped IPv6 | +| Діапазон або хост | Навіщо блокувати | +| ------------------------------------------------------------------------------------ | --------------------------------------------------- | +| `127.0.0.0/8`, `localhost`, `localhost.localdomain` | IPv4 loopback | +| `::1/128` | IPv6 loopback | +| `0.0.0.0/8`, `::/128` | Невизначені адреси й адреси цієї мережі | +| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` | Приватні мережі RFC1918 | +| `169.254.0.0/16`, `fe80::/10` | Link-local адреси та поширені шляхи cloud metadata | +| `169.254.169.254`, `metadata.google.internal` | Служби cloud metadata | +| `100.64.0.0/10` | Спільний адресний простір carrier-grade NAT | +| `198.18.0.0/15`, `2001:2::/48` | Діапазони benchmark | +| `192.0.0.0/24`, `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, `2001:db8::/32` | Діапазони special-use і documentation | +| `224.0.0.0/4`, `ff00::/8` | Multicast | +| `240.0.0.0/4` | Зарезервований IPv4 | +| `fc00::/7`, `fec0::/10` | Локальні/приватні діапазони IPv6 | +| `100::/64`, `2001:20::/28` | Діапазони IPv6 discard і ORCHIDv2 | +| `64:ff9b::/96`, `64:ff9b:1::/48` | Префікси NAT64 із вбудованим IPv4 | +| `2002::/16`, `2001::/32` | 6to4 і Teredo із вбудованим IPv4 | +| `::/96`, `::ffff:0:0/96` | IPv4-compatible і IPv4-mapped IPv6 | -Якщо ваш cloud provider або мережева платформа документує додаткові metadata хости чи зарезервовані діапазони, додайте і їх. +Якщо ваш cloud provider або мережева платформа документує додаткові metadata-хости чи зарезервовані діапазони, додайте також їх. ## Валідація -Перевіряйте проксі з того самого хоста, контейнера або службового облікового запису, де працює OpenClaw: +Перевірте проксі з того самого хоста, контейнера або службового облікового запису, який запускає OpenClaw: ```bash curl -x http://127.0.0.1:3128 https://example.com/ @@ -134,7 +134,7 @@ curl -x http://127.0.0.1:3128 http://127.0.0.1/ curl -x http://127.0.0.1:3128 http://169.254.169.254/ ``` -Публічний запит має успішно виконатися. Запити до loopback і metadata мають завершитися помилкою на проксі. +Публічний запит має пройти успішно. Loopback- і metadata-запити мають зазнати помилки на проксі. Потім увімкніть маршрутизацію OpenClaw через проксі: @@ -144,7 +144,7 @@ openclaw config set proxy.proxyUrl http://127.0.0.1:3128 openclaw gateway run ``` -або встановіть: +або задайте: ```yaml proxy: @@ -154,9 +154,9 @@ proxy: ## Обмеження -- Проксі покращує покриття для локальних для процесу JavaScript-клієнтів HTTP і WebSocket, але не замінює `fetchWithSsrFGuard` на рівні застосунку. -- Сирі сокети `net`, `tls` і `http2`, native addons і дочірні процеси можуть обходити маршрутизацію проксі на рівні Node, якщо вони не успадковують і не поважають змінні середовища проксі. -- Локальні WebUI користувача та локальні сервери моделей слід додавати до allowlist у політиці операторського проксі, коли це потрібно; OpenClaw не надає для них загального обходу локальної мережі. -- Обхід проксі площини керування Gateway навмисно обмежений `localhost` і літеральними loopback IP URL. Використовуйте `ws://127.0.0.1:18789`, `ws://[::1]:18789` або `ws://localhost:18789` для локальних прямих з’єднань площини керування Gateway; інші імена хостів маршрутизуються як звичайний трафік на основі імені хоста. -- OpenClaw не інспектує, не тестує й не сертифікує вашу політику проксі. -- Розглядайте зміни політики проксі як чутливі до безпеки операційні зміни. +- Проксі покращує покриття для локальних для процесу JavaScript HTTP- і WebSocket-клієнтів, але не є мережевою пісочницею на рівні ОС. +- Сирі сокети `net`, `tls` і `http2`, нативні addons і дочірні процеси можуть обходити маршрутизацію через проксі на рівні Node, якщо вони не успадковують і не поважають змінні середовища проксі. +- Локальні WebUI користувача та локальні сервери моделей слід додавати до allowlist у політиці проксі оператора, коли це потрібно; OpenClaw не надає для них загального обходу локальної мережі. +- Обхід проксі для площини керування Gateway навмисно обмежений `localhost` і URL із буквальними loopback IP. Використовуйте `ws://127.0.0.1:18789`, `ws://[::1]:18789` або `ws://localhost:18789` для локальних прямих з’єднань площини керування Gateway; інші імена хостів маршрутизуються як звичайний трафік на основі імені хоста. +- OpenClaw не перевіряє, не тестує й не сертифікує вашу політику проксі. +- Розглядайте зміни політики проксі як операційні зміни, чутливі до безпеки.