Серверный роутинг (мост)

Серверный роутинг соединяет два ваших сервера так, что трафик пользователей делится по направлениям: одна часть сайтов открывается напрямую со входной ноды, другая уезжает туннелем на сервер выхода. Пользователи ничего не замечают: та же подписка, те же адреса, та же скорость входа.

Два направления

Русские и зарубежные сайты видят разные IP, и вы выбираете, какой адрес видит каждая сторона.

Транспорт Shadowsocks

Один туннель chacha20-ietf-poly1305 между серверами, весь трафик, включая UDP.

Всё через панель

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

Нода не нужна заранее

Скрипт поставит её сам по SSH, вместе с Docker и портом в ufw.

Второй тип моста: VLESS Route

Каждый пользователь сам выбирает выход: у профиля появляется дополнительный хост в подписке.

Пункт находится в меню скрипта: 4. Расширения ноды → Серверный роутинг. Первый экран спрашивает, какой мост нужен:

root@server: ~

Серверный роутинг
 Подробности в wiki: https://wiki.egam.es/ru/configuration/server-routing/

1.Мост через Shadowsocks (настроено: 1)
    RU-сайты через один IP, зарубежные через другой, настройка одна на всех
2.Мост через VLESS Route (настроено: 0)
    каждому свой выход: у профиля появится ещё один хост в подписке, номер зашит в ссылку

0.Выход

Выберите действие (0-2):

Нужна панель на этом сервере и второй сервер.

Важно

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

Как это работает

В конфиг профиля входной ноды добавляется исходящий Shadowsocks и правила: куда отправлять российский трафик, а что оставить напрямую. На сервере выхода поднимается нода с одним служебным инбаундом, она ничего не раздаёт пользователям, только завершает туннель.

Направление выбираете вы

Главный вопрос настройки: куда должен идти российский трафик. Подсказка у каждого варианта прямо в меню говорит о последствиях, а выглядит результат так:

root@server: ~

Куда должен идти российский трафик (сайты и IP)?

1.Напрямую со входной ноды
    когда входная нода в РФ: русские сайты видят IP входа, зарубежные видят IP сервера выхода
2.Через мост
    когда входная нода за рубежом: русские сайты видят IP сервера выхода, зарубежные видят IP входа

Выберите действие (1-2):

Входная нода за рубежом

Режим «Через мост». Зарубежные сайты видят чистый иностранный IP входа, а русские сервисы получают родной российский адрес сервера выхода. Капч «вы заходите из-за границы» на русских сервисах нет.

Сервис	Видит IP
yandex.ru/internet и RU-сайты	сервер выхода
ifconfig.me и зарубежные	входную ноду

Входная нода в России

Режим «Напрямую со входной ноды». RU-сайты остаются на российском входе, а зарубежное уходит через второй сервер и получает иностранный адрес.

Сервис	Видит IP
yandex.ru/internet и RU-сайты	входную ноду
ifconfig.me и зарубежные	сервер выхода

Режим можно поменять в любой момент одной командой «Настроить заново», и направление переключится без переустановки: объекты переиспользуются.

Настройка

Мастер задаёт несколько вопросов подряд. Сначала, сервер выхода: он выбирается из серверов с настроенным SSH-доступом (или вводится адрес вручную, и тогда скрипт сам предложит настроить доступ):

root@server: ~

Сервер выхода (из настроенных SSH-целей):

1.root@203.0.113.20:22 (Kazan)
2.Ввести адрес вручную

Дальше идут порт, направление (экран выше), название моста и профиль входной ноды:

root@server: ~

Порт SS-моста (Enter подставит 9999): 9999
Название моста в панели (Enter подставит Kazan): Kazan

Какой профиль подключить к мосту?
 Через него пойдёт трафик по выбранным маршрутам, выбирайте профиль входной ноды

1.Default-Profile (2 инбаунда)

1. Сервер выхода. Экран выше. Если ноды на нём нет, скрипт предложит установить всё удалённо: Ноды 203.0.113.20 нет в панели. Установить её на этот сервер по SSH (docker + remnanode)? (y/n). Серверу выхода не нужны ни домен, ни сертификаты: она просто слушает порт и завершает туннель.
2. Порт моста. По умолчанию 9999, EnterEnterEnterEnterEnterEnter оставит его.
3. Направление трафика. Таблица выше.
4. Название моста. Одно имя для всех объектов в панели, EnterEnterEnterEnterEnterEnter подставит название SSH-сервера: группа Kazan bridge, служебный пользователь bridge-kazan, нода и профиль Kazan-bridge.
5. Профиль входной ноды. В него добавляется исходящий и правила. Позже можно подключить ещё профили, например когда появится вторая входная нода.

Пока вы отвечали, мастер уже всё поднял, ход установки выглядит так:

root@server: ~

Получаю ключ связи ноды с панели...
Ключ связи получен
Ставлю Docker на удалённый сервер (может занять пару минут)...
Пишу compose-файл ноды...
Файлы ноды записаны на сервер
Поднимаю контейнер ноды...
Жду подключения ноды к панели (попытка 1)...
Нода подключилась к панели
Создаю внутреннюю группу моста...
Группа создана
Создаю сервисного пользователя моста...
Сервисный пользователь создан
Добавляю в профиль «Default-Profile» исходящий и правила роутинга...
Профиль «Default-Profile» обновлён, конфиг уйдёт на его ноды
Открываю порт моста в ufw на 203.0.113.20...
Порт открыт в ufw

В конце мастер настройки проверяет связность живьём: подключена ли нода к панели, отвечает ли порт моста, и напоминает, как проверить результат с клиента.

Под капотом: правила в профиле

В режим «Через мост» в конфиг профиля добавляется исходящий и такие правила:

{ "ip": ["geoip:private"], "outboundTag": "BLOCK" },
{ "protocol": ["bittorrent"], "outboundTag": "BLOCK" },
{ "ip": ["geoip:ru"], "outboundTag": "SR_BRIDGE_SS" },
{ "domain": ["geosite:category-ru"], "outboundTag": "SR_BRIDGE_SS" }

В режиме «Напрямую со входной ноды» у geoip:ru и geosite:category-ru меняется outboundTag на DIRECT, и добавляется замыкающее правило: весь остальной трафик профиля уходит в SR_BRIDGE_SS. При расширенных RU-списках в конец добавляется ещё одно правило с ext:geosite-ruex.dat:ru-available-only-inside, ему всегда назначается мост.

Меню моста

root@server: ~

Мосты через Shadowsocks: Kazan

 Мост: 203.0.113.20:9999
 Нода 203.0.113.20 подключена к панели
 Порт 9999 отвечает с этого сервера

1.Подключить ещё профиль
    входная нода этого профиля пойдёт через тот же выход
2.RU-списки: расширенные (вернуть стандартные)
    переключатель общий для всех мостов, файл списков ставится на входные ноды
3.Настроить заново
    полная настройка с самого начала: сервер выхода, порт, режим, профиль
4.Переименовать мост
    новое имя получат группа, пользователь, нода и профиль
5.Убрать роутинг
    профили вернут прямой выход, нода и профиль моста останутся

0.Выход

Выберите действие (0-5):

Мостов может быть несколько: каждое со своим сервером выхода, своими объектами в панели и своими подключёнными профилями. Если профиль уже занят другим мостом, скрипт предупредит и предложит перепривязать.

Мост через VLESS Route

Мост по странам решает за всех: направление одно на весь профиль. Второй тип отдаёт выбор пользователю. У профиля появляется дополнительный хост в подписке, например «Germany → Moscow», и выбрав его, пользователь целиком выходит через сервер моста: и русские, и зарубежные сайты видят его IP. Обычный хост работает как раньше.

Хост в подписке	RU-сайты видят	Зарубежные видят
Germany (обычный)	по общим правилам профиля	по общим правилам профиля
Germany → Moscow	IP сервера моста	IP сервера моста

Хосты переключаются в клиенте в любой момент, без переустановки и второй подписки: телефон может жить на «Germany → Moscow» ради банков, а компьютер на обычном «Germany».

Как это устроено

Номер маршрута это штатное поле хоста в панели (vlessRouteId). Панель вшивает число в UUID ссылки, входная нода читает его и отправляет соединение через нужный исходящий. Пользователь ничего не настраивает: просто выбирает хост с понятным названием.

Линия на каждый выход

Сколько серверов выхода, столько линий, у каждой свой номер маршрута и своя статистика у сервисного пользователя в панели.

Переиспользование выхода

Вторая линия на тот же выход создаётся без нового сервера: тот же туннель, свой сервисный пользователь и свой учёт трафика.

Несколько входов

Пункт «Подключить ещё профиль» добавляет хост «его вход → этот выход» на второй входной ноде тем же номером маршрута.

Гео не мешает

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

Под капотом: правила и UUID

В профиль входной ноды добавляются исходящий и правила с номерами маршрутов:

{ "vlessRoute": 1, "outboundTag": "DIRECT" },
{ "vlessRoute": 2, "outboundTag": "SR_BRIDGE_SS_kazan" }

Маршрут 1 служебный: прямой выход со входной ноды, хост для него создаётся, только если профиль уже разделён по странам. Номер живёт в третьей группе UUID: пользователь 9d5f42a1-7b3c-4d8e-… на маршруте 2 получает ссылку с 9d5f42a1-7b3c-0002-…, и именно эту пару байтов нода читает как номер.

Настройка

Мастер VLESS Route начинает с сервера выхода: нового сервера по SSH или строки «Выход моста …» из уже настроенных:

root@server: ~

Сервер выхода

1.Новый сервер (SSH)
2.Выход моста «Kazan» (203.0.113.20:9999)

1. Сервер выхода. Экран выше: та же линия, свой сервисный пользователь.

2. Порт и название. По умолчанию 9999 и имя SSH-сервера, EnterEnterEnterEnterEnterEnter оставит оба.

3. Профиль входной ноды. Только VLESS: маршрут ездит в UUID ссылки, у Trojan и Shadowsocks его нет. Профили, уже занятые другими мостами, помечаются в списке.

4. Номер маршрута. Свободный номер предлагается сам, занятые не предложат:

   root@server: ~

   Номер маршрута (Enter подставит 2): 2

5. Название хоста. По умолчанию «вход → выход», например «Germany → Moscow».

Дальше скрипт работает сам: если на сервере уже бежит контейнер ноды без записи в панели, предложит подключить его как есть, без переустановки. ufw на сервере выхода включается автоматически: порты, которые уже слушают снаружи, остаются открытыми, закрывается всё прочее.

Меню моста

root@server: ~

Мост через VLESS Route: Kazan (маршрут 2)

 Мост: 203.0.113.20:9999
 Нода 203.0.113.20 подключена к панели
 Порт 9999 отвечает с этого сервера
 Хост в подписке: Germany → Kazan

1.Скрыть хост из подписок
    правила остаются, хост просто пропадает из подписок пользователей
2.Подключить ещё профиль
    вторая входная нода через тот же выход и тот же номер маршрута
3.Настроить заново
    полная настройка с самого начала: сервер выхода, профиль, номер маршрута, хост
4.Переименовать мост
    новое имя получат группа, пользователь и хост в подписке
5.Убрать роутинг
    хост удалится, правила уйдут, все вернутся к общим правилам профиля

0.Выход

Выберите действие (0-5):

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

Расширенные RU-списки

Стандартное правило geosite:category-ru покрывает все домены в зонах .ru, .su, .рф и именные списки. Но русские сервисы, живущие на иностранных доменах, в него не попадают и остаются не у дел.

Пункт «RU-списки» подключает списки проекта runetfreedom, обновляемые ежедневно. Добавляется одно правило для доменов, доступных только изнутри России (ext:ru-available-only-inside):

root@server: ~

Включить расширенные RU-списки (домены, доступные только из РФ)? Стандартные останутся, новое правило добавится поверх (y/n): y
Скачиваю geosite.dat с runetfreedom...
Файл получен, контрольная сумма совпала
Монтирую списки в ноду node.example.com...
Добавляю правило расширенных списков в мостовые профили...
Правило добавлено, профилей обновлено: 1
Расширенные RU-списки включены на серверах: node.example.com

Ничего не заменяется

Стандартные правила остаются как есть, новое правило добавляется поверх.

Всегда российский выход

Доменам из списка обеспечен выход через РФ в любом режиме работы моста.

Ставится на входные ноды

Решения о маршрутизации принимает входная нода, туда и ложится файл списков, отдельно от штатных геоданных Xray.

Обновляется само

Каждый день в 4:30 свежая версия списков скачивается с зеркал и проверяется по контрольной сумме. Ноды перезапускаются только если файл изменился.

Под капотом: файлы и cron

• Директория/usr/local/remnawave_reverse

  • Директорияserver-routing

    • kazan.bridge (мост: сервер, порт, режим, объекты панели)
    • ruex.state (состояние расширенных списков)
    • ruex-update.sh (ежедневный обновлятор)
    • ruex-update.log (последние 50 строк журнала)

Строка в crontab -l выглядит так: 30 4 * * * bash /usr/local/remnawave_reverse/server-routing/ruex-update.sh. Обновлятор скачивает датник с четырёх зеркал, сверяет sha256 и раскладывает файл на входные ноды. Рестарт нод вызывается через API панели и только при реальном изменении файла.

Проверка с клиента

Подключитесь пользователем из обычной группы (где входная нода) и откройте два сайта:

RU напрямую

yandex.ru/internet покажет IP входной ноды, ifconfig.me покажет IP сервера выхода.

RU через мост

yandex.ru/internet покажет IP сервера выхода, ifconfig.me покажет IP входной ноды.

Хост маршрута (VLESS Route)

Выберите у клиента хост моста, например «Germany → Moscow»: ifconfig.me покажет IP сервера моста, обычный хост вернёт свой привычный адрес.

Отключение

«Убрать роутинг» возвращает профилям прямой выход, удаляет служебного пользователя и группу, закрывает порт в ufw на втором сервере. Нода и профиль моста остаются, они больше ничего не маршрутизируют, и их можно удалить в панели вручную, если они не нужны.

---

SSH-доступ к удалённым серверамКак скрипт получает доступ ко второму серверу и что можно делать удалённо.