Маршрутизация на стороне сервера

Только для демонстрации | Не готово к использованию в продакшене

Данное руководство предназначено исключительно как демонстрация маршрутизации на стороне сервера. Не предполагайте, что копирование этих примеров создаст полностью работоспособную конфигурацию в продакшене. Оно не охватывает все возможности Xray-core и не гарантирует безупречной работы в каждой среде.

Для получения полной информации о синтаксисе конфигурации и поведении обратитесь к официальной документации Xray.

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

В этом руководстве мы настроим маршрутизацию трафика на стороне сервера, используя два узла: RU и DE. Пользователи будут подключаться к узлу RU. Оттуда трафик будет маршрутизироваться следующим образом:

Трафик к сайтам .ru будет проксироваться напрямую через узел RU.
Весь остальной трафик будет направляться через узел DE.

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

В результате «поток» трафика может выглядеть примерно так:

Пользователь открывает google.com.
Запрос сначала достигает узла RU.
Узел RU применяет правила маршрутизации. Поскольку google.com не является доменом .ru, трафик направляется на узел DE.
Узел DE завершает подключение к google.com.

Такой тип конфигурации маршрутизации на стороне сервера часто называют «мостом».

Создание профиля конфигурации для DE

Перейдите в раздел «Профили конфигурации» и создайте новый профиль конфигурации, например DE Bridge Profile.

DE 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": []
    }
}

Не забудьте назначить профиль и создать внутренний отряд

Назначьте только что созданный профиль конфигурации узлу DE. Выберите входящее подключение BRIDGE_DE_IN.

Создайте новый внутренний отряд, назовём его Bridge Squad. Включите входящее подключение, которое мы создали ранее — BRIDGE_DE_IN.

Создание сервисного пользователя

Для работы нашего моста нам нужно создать пользователя. Назовём его bridge_user.

Не забудьте убрать ограничения трафика и продлить дату истечения

Поскольку это сервисный пользователь, мы явно не хотим, чтобы его подписка истекала или ограничивалась по использованию трафика. Установите Data Limit на 0, а Expiry Date — на 2099 год.

Затем назначьте этому пользователю соответствующий отряд. В нашем случае это Bridge Squad.

После создания сервисного пользователя нам нужно получить его пароль. Откройте карточку пользователя, нажмите кнопку More Actions, затем Detailed Info. Там вы должны увидеть раздел Connection Information.

В зависимости от протокола входящего подключения (в нашем случае Shadowsocks) скопируйте соответствующее значение:

Протокол	Значение информации о подключении
Trojan	Пароль Trojan
VLESS	UUID VLESS
Shadowsocks	Пароль SS

Настройка публичного профиля

Скорее всего, у вас уже есть профиль конфигурации, к которому подключаются пользователи. Если нет, обратитесь к этому руководству.

На этом шаге нас не интересуют "inbounds" — вместо этого мы будем изменять массивы "outbounds", "routing" и "rules" этого профиля.

Public Profile Example
{
    "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 YOUR OWN VALUE!",
                    "show": false,
                    "xver": 0,
                    "shortIds": [""],
                    "privateKey": "USE YOUR OWN KEY!",
                    "serverNames": ["USE YOUR 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"
            }
        ]
    }
}

Outbounds

Сначала нам нужно изменить массив outbounds.

outbounds
{
    "tag": "SS_OUTBOUND_TO_DE",
    "protocol": "shadowsocks",
    "settings": {
        "servers": [
            {
                "address": "DE NODE ADDRESS",
                "password": "PASSWORD FROM PREVIOUS STEP",
                "port": 9999,
                "level": 0,
                "method": "chacha20-ietf-poly1305"
            }
        ]
    }
}

Поле	Значение
`address`	IP-адрес или доменное имя вашего сервера узла `DE`.
`port`	Порт входящего подключения; в нашем случае — порт `BRIDGE_DE_IN`.
`password`	Пароль сервисного пользователя. Зависит от используемого протокола; см. предыдущий шаг.
`method`	Метод шифрования. Для Shadowsocks в Remnawave всегда используйте `chacha20-ietf-poly1305`.

Маршрутизация и правила

Затем измените правила маршрутизации в соответствии с вашими потребностями.

Ниже приведён пример правила, которое делает узел RU выходным узлом для российских IP-адресов и сайтов, тогда как остальной трафик отправляется на узел DE.

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

Ниже приведён пример правила, которое направляет весь трафик в исходящее подключение SS_OUTBOUND_TO_DE.

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

Полный публичный профиль конфигурации может выглядеть следующим образом:

Complete Public Config Profile Example
{
    "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 YOUR OWN VALUE!",
                    "show": false,
                    "xver": 0,
                    "shortIds": [""],
                    "privateKey": "USE YOUR OWN KEY!",
                    "serverNames": ["USE YOUR OWN VALUES!"]
                }
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "DIRECT"
        },
        {
            "protocol": "blackhole",
            "tag": "BLOCK"
        },
        {
            "tag": "SS_OUTBOUND_TO_DE",
            "protocol": "shadowsocks",
            "settings": {
                "servers": [
                    {
                        "address": "DE NODE ADDRESS",
                        "password": "PASSWORD FROM PREVIOUS STEP",
                        "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"
            }
        ]
    }
}

подсказка

Правила маршрутизации Xray обрабатываются по порядку, сверху вниз.
Вот как работают правила в нашем примере:

Приватные IP-адреса (geoip:private) → BLOCK
Трафик, соответствующий этому правилу, отправляется в исходящее подключение BLOCK — это протокол blackhole (полная блокировка).
Приватные домены (geosite:private) → BLOCK
Аналогично предыдущему, но для доменных имён.
Трафик BitTorrent (bittorrent) → BLOCK
Весь трафик BitTorrent блокируется.
Российские IP-адреса (geoip:ru) → DIRECT
Трафик, соответствующий этому правилу, отправляется в исходящее подключение DIRECT — это протокол freedom (узел RU выступает в роли выходного узла).
Российские домены (geosite:category-ru) → DIRECT
Трафик к российским доменам также выходит напрямую с узла RU.
Ни одно правило не совпало (остальной трафик) → SS_OUTBOUND_TO_DE
Любой оставшийся трафик, поступающий на PUBLIC_RU_INBOUND, направляется на узел DE через исходящее подключение Shadowsocks, созданное ранее.

Вам необязательно использовать Shadowsocks в качестве транзитного протокола — вместо него можно использовать VLESS. Просто убедитесь, что вы соответствующим образом обновили конфигурацию.

Создание профиля конфигурации для DE​

Создание сервисного пользователя​

Настройка публичного профиля​

Outbounds​

Маршрутизация и правила​

Создание профиля конфигурации для DE

Создание сервисного пользователя

Настройка публичного профиля

Outbounds

Маршрутизация и правила