From 8176fc8e36498c9f229d8acdcc1eb7abc6d34fa8 Mon Sep 17 00:00:00 2001 From: kastov Date: Wed, 15 Oct 2025 03:16:03 +0300 Subject: [PATCH] docs: add server routing guide --- docs/learn/quick-start.md | 4 +- docs/learn/server-routing.md | 280 +++++++++++++++++++++++++++++++++++ 2 files changed, 281 insertions(+), 3 deletions(-) create mode 100644 docs/learn/server-routing.md diff --git a/docs/learn/quick-start.md b/docs/learn/quick-start.md index 95c417e..244c489 100644 --- a/docs/learn/quick-start.md +++ b/docs/learn/quick-start.md @@ -1,8 +1,6 @@ --- +sidebar_position: 1 title: Быстрый старт -authors: remnawave -tags: [learn] -date: 2025-07-18 --- В этой небольшой статье мы во всех подробностях и деталях расскажем о функциях панели, которые помогут вам быстро разобраться с ее работой. diff --git a/docs/learn/server-routing.md b/docs/learn/server-routing.md new file mode 100644 index 0000000..b15ac11 --- /dev/null +++ b/docs/learn/server-routing.md @@ -0,0 +1,280 @@ +--- +sidebar_position: 2 +title: Серверный роутинг +--- + +В этом примере мы рассмотрим, как можно настроить серверный роутинг с помощью сервисных пользователей в панели Remnawave. + + + +# Серверный роутинг + +Некоторые пользователи могли столкнуться с проблемой, что Remnawave автоматически очищает массив _clients_ из серверной конфигурация. Это не ошибка и не баг, панель автоматически очищает эти массивы, так как для правильной работы некоторых функций панели – панель должна быть уверена в том, что в этом массиве не будет ничего лишнего. + +Представим, что у нас имеется два сервера. Будем называть их: `RU-001`, `DE-001`. + +Пользователи будут подключаться к серверу `RU-001`, мы будем делать _роутинг_ трафика и для примера – .ru сайты отправлять _напрямую_, а все остальное на сервер `DE-001`. + +Для решения этой задачи нам потребуется создать _сервисного пользователя_, через который мы и будем производить **роутинг**. + +## Создание профиля для DE-001 + +Перейдите в раздел _Config Profiles_ и создайте новый профиль, дадим ему название `Bridge Profile`. + +```json +{ + "log": { + "loglevel": "warning" + }, + "dns": {}, + "inbounds": [ + { + "tag": "BRIDGE_DE_IN", + "port": 9999, + "listen": "0.0.0.0", + "protocol": "shadowsocks", + "settings": { + "clients": [], + "network": "tcp,udp" + }, + "sniffing": { + "enabled": true, + "destOverride": ["http", "tls", "quic"] + } + } + ], + "outbounds": [ + { + "tag": "DIRECT", + "protocol": "freedom" + }, + { + "tag": "BLOCK", + "protocol": "blackhole" + } + ], + "routing": { + "rules": [] + } +} +``` + +Сохраняем обновленную конфигуруацию. + +Переходим в раздел **Internal Squad** (Для создания нового сквада нажмите на плюсик справа в углу). В этом скваде включаем только свежесозданных инбаунд `BRIDGE_DE_IN` из профиля `Bridge Profile`. + +Так же, обязательно включите этот инбаунд и профиль в карточке ноды. В нашем случае – ноды `DE-001`. + +## Создание сервисного пользователя + +Перейдите в раздел _Users_, создайте пользователя с названием `bridge_user_001`. Убедитесь, что у этого пользователя не установлено ограничений по трафику и установите дату, когда истекает подписка где-нибудь в районе 2099 года. (_Нам ведь не нужно, чтобы панель отключила юзера из-за достижения лимита трафика или по причине того, что у него устекла подписка?_) + +После того как пользователь успешно создался, откройте его карточку и в меню (кнопка **More Actions**) нажимаем на секцию **Detailed Info**. + +В этой секции листаем в самый низ и в зависимости от того, какого типа у вас инбаунд, копируем информацию. + +| Протокол | Обозначение в панели | +| ----------- | -------------------- | +| Shadowsocks | SS Password | +| VLESS | VLESS UUID | +| Trojan | Trojan Password | + +Итого, у нас руках должна быть следующая информация: + +- имя пользователя +- пароль для подключения (см. выше) + +## Настройка публичного профиля + +Скорее всего такой профиль уже у вас имеется, по нему подключается пользователи. Секция inbounds в нем можно не трогать, нас интересует секция outbounds и routing.rules. + +```json +{ + "log": { "loglevel": "none" }, + "inbounds": [ + { + "tag": "PUBLIC_RU_INBOUND", + "port": 443, + "listen": "0.0.0.0", + "protocol": "vless", + "settings": { "clients": [], "decryption": "none" }, + "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] }, + "streamSettings": { + "network": "raw", + "security": "reality", + "realitySettings": { + "target": "USE OWN VALUE!", + "show": false, + "xver": 0, + "shortIds": [""], + "privateKey": "USE OWN KEY!", + "serverNames": ["REPLACE WITH OWN VALUES!"] + } + } + } + ], + "outbounds": [ + { "protocol": "freedom", "tag": "DIRECT" }, + { "protocol": "blackhole", "tag": "BLOCK" } + ], + "routing": { + "rules": [ + { "ip": ["geoip:private"], "outboundTag": "BLOCK" }, + { + "domain": ["geosite:private"], + "outboundTag": "BLOCK" + }, + { "protocol": ["bittorrent"], "outboundTag": "BLOCK" } + ] + } +} +``` + +Итак, изначально перед нами стоит задача – пользователи подключаются к серверу `RU-001` по протоколу `VLESS`, а дальше мы путем роутинга перенаправляем трафик. + +### Outbound + +Для начала нам нужно собрать `outbound`. + +```json +{ + "tag": "SS_OUTBOUND_TO_DE", + "protocol": "shadowsocks", + "settings": { + "servers": [ + { + "address": "ADDRESS OF DE-001", + "email": "bridge_user_001", + "password": "ПАРОЛЬ С ПРОШЛОГО ШАГА", + "port": 9999, + "level": 0, + "method": "chacha20-ietf-poly1305" + } + ] + } +} +``` + +| Значение | Что вводить? | +| -------- | ----------------------------------------------------------------------------------------------------- | +| address | IP или доменное имя, которое будет направлено на ваш сервер, например IP-адрес сервера `DE-001` | +| port | Порт инбаунда, в нашем случае это порт инбаунда `BRIDGE_DE_IN` | +| email | Username сервисного пользователя | +| password | Пароль пользователя для подключения (в зависимости от протокола могут быть разные значения, см. выше) | + +В случае **Shadowsocks** – не используйте никакие другие методы кроме `chacha20-ietf-poly1305`, так как Remnawave поддерживает только этот метод. + +### Роутинг + +Пример правила, которое направит весь трафик в указанных выше outbound. + +```json +{ + "inboundTag": ["PUBLIC_RU_INBOUND"], + "outboundTag": "SS_OUTBOUND_TO_DE" +} +``` + +Если добавить это правило в конец объекта routing.rules, оно будет использоваться в самом конце. Следовательно, если трафик попадет под правила, которые находятся выше него – то сюда они не попадут. + +Допустим, мы хотим отправлять RU сайты напрямую (сразу на выход из ноды `RU-001`, а все остальное в `DE-001` + +```json + { + "ip": [ + "geoip:ru" + ], + "outboundTag": "DIRECT" + }, + { + "domain": [ + "geosite:category-ru" + ], + "outboundTag": "DIRECT" + } +``` + +Собираем полную конфигурацию, она будет выглядеть вот так. + +```json +{ + "log": { "loglevel": "none" }, + "inbounds": [ + { + "tag": "PUBLIC_RU_INBOUND", + "port": 443, + "listen": "0.0.0.0", + "protocol": "vless", + "settings": { "clients": [], "decryption": "none" }, + "sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] }, + "streamSettings": { + "network": "raw", + "security": "reality", + "realitySettings": { + "target": "USE OWN VALUE!", + "show": false, + "xver": 0, + "shortIds": [""], + "privateKey": "USE OWN KEY!", + "serverNames": ["REPLACE WITH OWN VALUES!"] + } + } + } + ], + "outbounds": [ + { "protocol": "freedom", "tag": "DIRECT" }, + { "protocol": "blackhole", "tag": "BLOCK" }, + { + "tag": "SS_OUTBOUND_TO_DE", + "protocol": "shadowsocks", + "settings": { + "servers": [ + { + "address": "ADDRESS OF DE-001", + "email": "bridge_user_001", + "password": "ПАРОЛЬ С ПРОШЛОГО ШАГА", + "port": 9999, + "level": 0, + "method": "chacha20-ietf-poly1305" + } + ] + } + } + ], + "routing": { + "rules": [ + { "ip": ["geoip:private"], "outboundTag": "BLOCK" }, + { "domain": ["geosite:private"], "outboundTag": "BLOCK" }, + { "protocol": ["bittorrent"], "outboundTag": "BLOCK" }, + { "ip": ["geoip:ru"], "outboundTag": "DIRECT" }, + { "domain": ["geosite:category-ru"], "outboundTag": "DIRECT" }, + { + "inboundTag": ["PUBLIC_RU_INBOUND"], + "outboundTag": "SS_OUTBOUND_TO_DE" + } + ] + } +} +``` + +Соответственно, наш outbound – `SS_OUTBOUND_TO_DE` мы добавили в массив `outbounds`, а правила добавили в массив в объекте `rules` (который находится в объекте `routing`). + +Правила в Xray работают по принципу очередности. Наши правила можно расшифровать примерно вот так: + +1. Если IP адрес входит в `geoip:private` – **BLOCK** (отправляется в `outbound` **BLOCK**, который в свою очередь является _blackhole_ (блокируется)). +2. Если домен входит в категорию `geosite:private` – те же действия +3. Тоже самое и для `bittorrent` трафика. +4. Если IP адрес входит в `geoip:ru` – отправляем в `DIRECT` Outbound, следовательно трафик выйдет с нашего `RU-001` сервера. +5. Если домен входит в категорию `geosite:category-ru` – отправляем так же в `DIRECT`. +6. Если трафик пришел из инбаунда `PUBLIC_RU_INBOUND` – мы отправляем его в outbound `SS_OUTBOUND_TO_DE` (и там он уходит уходит на наш сервер – `DE-001`). + +# Заключение + +В этом примере у нас получилась вот такая схема: + +- Пользователь подключается к серверу `RU-001` с помощью протокола `VLESS` +- Трафик попадает под правила: + - RU-сайты (или IP) – идут сразу на выход (DIRECT) + - Весь остальной трафик – отправляется через протокол `shadowsocks` на другой сервер – `DE-001` + +В качестве транзитного протокола так же можно использовать и `VLESS`, в основном будет отличаться только наш `outbound`.