Files
panel/docs/learn/server-routing.md
Nick 73925574f2 Removed email references (#282)
* Removed email references

* fix должна
2025-12-25 15:24:23 +03:00

13 KiB
Raw Blame History

sidebar_position, title
sidebar_position title
2 Серверный роутинг

В этом примере мы рассмотрим, как можно настроить серверный роутинг с помощью сервисных пользователей в панели Remnawave.

Серверный роутинг

Некоторые пользователи могли столкнуться с проблемой, что Remnawave автоматически очищает массив clients из серверной конфигурации. Это не ошибка и не баг, панель автоматически очищает эти массивы, так как для правильной работы некоторых функций панели панель должна быть уверена в том, что в этом массиве не будет ничего лишнего.

Представим, что у нас имеется два сервера. Будем называть их: RU-001, DE-001.

Пользователи будут подключаться к серверу RU-001, мы будем делать роутинг трафика и для примера .ru сайты отправлять напрямую, а все остальное на сервер DE-001.

Для решения этой задачи нам потребуется создать сервисного пользователя, через который мы и будем производить роутинг.

Создание профиля для DE-001

Перейдите в раздел Config Profiles и создайте новый профиль, дадим ему название Bridge Profile.

{
    "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.

{
    "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.

{
    "tag": "SS_OUTBOUND_TO_DE",
    "protocol": "shadowsocks",
    "settings": {
        "servers": [
            {
                "address": "ADDRESS OF DE-001",
                "password": "ПАРОЛЬ С ПРОШЛОГО ШАГА",
                "port": 9999,
                "level": 0,
                "method": "chacha20-ietf-poly1305"
            }
        ]
    }
}
Значение Что вводить?
address IP или доменное имя, которое будет направлено на ваш сервер, например IP-адрес сервера DE-001
port Порт инбаунда, в нашем случае это порт инбаунда BRIDGE_DE_IN
password Пароль пользователя для подключения (в зависимости от протокола могут быть разные значения, см. выше)

В случае Shadowsocks не используйте никакие другие методы кроме chacha20-ietf-poly1305, так как Remnawave поддерживает только этот метод.

Роутинг

Пример правила, которое направит весь трафик в указанный выше outbound.

{
    "inboundTag": ["PUBLIC_RU_INBOUND"],
    "outboundTag": "SS_OUTBOUND_TO_DE"
}

Пример правил, которые направят RU сайты напрямую (сразу на выход из ноды RU-001, а все остальное в DE-001)

      {
        "ip": [
          "geoip:ru"
        ],
        "outboundTag": "DIRECT"
      },
      {
        "domain": [
          "geosite:category-ru"
        ],
        "outboundTag": "DIRECT"
      }

Собираем полную конфигурацию, она будет выглядеть вот так.

{
    "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",
                        "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.