Ретранслятор на VPS добавляет один переход перед уже работающим прокси-сервером: клиенты подключаются к промежуточному VPS, а он передаёт их пакеты TCP и UDP на конечный сервер, ничего не расшифровывая. Сделать это можно в ядре — через nftables DNAT с подменой адреса источника — или в пространстве пользователя через пересылку GOST; оба способа допустимы только между серверами, которыми вы владеете или на которые у вас есть разрешение.

Ключевые выводы

Ретранслятор меняет адрес входа, но не выход: сайты по-прежнему видят конечный сервер.

Для nftables DNAT нужны пересылка IP и парное правило SNAT или masquerade, иначе ответы уходят не тем путём.

GOST пересылает трафик на уровне приложения и не требует пересылки в ядре, но для длинных UDP-сессий нужен keepAlive.

При обоих способах конечный сервер видит адрес ретранслятора, а не адрес каждого клиента.

Настройки TLS, REALITY или ключей в клиенте не меняются; меняются только адрес и порт сервера.

Инструкция подготовлена по официальным источникам ниже; полный сквозной тест не выполнялся. Команды рассчитаны на Ubuntu 24.04 LTS на обоих серверах, nftables из дистрибутива и GOST v3.3.0; они описывают документированное поведение, а не измеренные результаты. Начните с чек-листа обязанностей владельца и восстановления, чтобы знать, кто управляет каждым сервером.

Когда ретранслятор на VPS помогает, а когда нет?

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

Проброс порта также делает его публичным. Прочитайте, как входящий проброс портов открывает службу, прежде чем что-либо открывать, и решите, с каких адресов разрешать подключения. Ретранслятор не исправит конечный сервер, который уже медленный или перегружен: сначала измерьте это по проверкам медленного собственного сервера. Если обслуживание двух серверов, двух файрволов и двух графиков обновлений — больше, чем требует ваша задача, сравните обязанности при VPS и управляемом VPN, прежде чем добавлять переход.

Используйте только серверы, которыми управляете, с консольным доступом, не зависящим от пробрасываемого порта, и с ключами хостов SSH, проверенными по независимому каналу. Избегайте скриптов «ретранслятор в один клик» из неизвестных источников: они часто целиком заменяют правила файрвола и не оставляют записи о том, что изменилось.

nftables DNAT или GOST: какой способ выбрать?

Вопрос	nftables DNAT на VPS	Проброс портов GOST
Где работает	Netfilter в ядре Linux с отслеживанием соединений	Процесс в пространстве пользователя на ретрансляторе
Нужен `ip_forward`	Да	Нет
Какой источник видит конечный сервер	Адрес ретранслятора после SNAT или masquerade	Адрес ретранслятора, потому что GOST открывает своё соединение
Обработка UDP	Записи conntrack на каждый поток	UDP-слушатель с параметрами `keepAlive` и `ttl`
Дополнительные возможности	Счётчики, сопоставление, без отдельного демона	Несколько целей, стратегия выбора, переходы цепочки по желанию
Типичный сбой	Нет SNAT или пакеты отбрасывает политика forward	Процесс остановлен или UDP-канал закрыт слишком рано

Stateful NAT в nftables создаёт привязку по первому пакету потока, а последующие пакеты используют её повторно.［1］ Службы пересылки TCP и UDP в GOST принимают соединение на ретрансляторе и открывают новое к каждому целевому узлу; они также умеют отправлять трафик через переход цепочки с -F, для чего на следующем сервере нужна парная служба.［2］ В этой инструкции оба способа пересылают трафик без дополнительных слоёв; для каждого порта выберите один.

Шаг 1: запишите данные конечного сервера и спланируйте порты

В примерах публичный интерфейс ретранслятора — eth0 с адресом 198.51.100.10, а конечный сервер — 203.0.113.30, где существующий прокси слушает TCP и UDP 443. Замените все значения своими и убедитесь, что конечная служба работает напрямую, прежде чем добавлять ретранслятор.

Выберите на ретрансляторе свободные порты: здесь 8443 для nftables и 8444 для GOST, чтобы способы можно было сравнить. Проверьте это командой sudo ss -lntup. Сохраните текущие правила ретранслятора: sudo nft list ruleset > ~/relay-ruleset-before.nft, и отметьте, какой менеджер файрвола используется, например UFW или Docker.

Если файрвол конечного сервера пропускает только известные адреса клиентов, добавьте адрес ретранслятора для TCP и UDP 443. После включения ретранслятора конечный сервер будет видеть 198.51.100.10 в качестве собеседника для всех клиентов, поэтому ограничения и журналы по адресам клиентов перестанут различать пользователей.

Шаг 2: включите пересылку и добавьте nftables DNAT с SNAT

Пересылка в ядре по умолчанию выключена (net.ipv4.ip_forward равен 0).［3］ Создайте файл /etc/sysctl.d/90-relay-forward.conf со строкой net.ipv4.ip_forward = 1, затем выполните sudo sysctl --system и проверьте результат командой sysctl net.ipv4.ip_forward. Документация ядра отмечает, что изменение этого значения сбрасывает параметры интерфейсов к значениям по умолчанию, поэтому после него перепроверьте собственные настройки интерфейсов.［3］

Сохраните правила в /etc/nftables-relay/relay-nat.nft:

table ip relay_nat
delete table ip relay_nat

table ip relay_nat {
    chain prerouting {
        type nat hook prerouting priority -100; policy accept;
        iifname "eth0" tcp dport 8443 counter dnat to 203.0.113.30:443
        iifname "eth0" udp dport 8443 counter dnat to 203.0.113.30:443
    }
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        ip daddr 203.0.113.30 tcp dport 443 counter masquerade
        ip daddr 203.0.113.30 udp dport 443 counter masquerade
    }
}

Первые две строки создают и тут же удаляют таблицу, поэтому повторная загрузка файла заменяет только relay_nat и не трогает другие таблицы. Не добавляйте flush ruleset: эта команда удалит и правила, принадлежащие UFW, Docker или агенту провайдера. Цепочка prerouting меняет адрес назначения, цепочка postrouting — адрес источника на адрес ретранслятора; тогда конечный сервер отвечает ретранслятору, а conntrack переводит ответ обратно клиенту.［1］ Без SNAT ответы уходят с конечного сервера прямо клиенту и не совпадают с его соединением.

Проверьте синтаксис командой sudo nft -c -f /etc/nftables-relay/relay-nat.nft, затем загрузите правила через sudo nft -f с тем же путём.

Разрешите пересылаемый трафик в фильтре

Правило NAT не отменяет фильтр. В nftables вердикт accept в одной базовой цепочке не окончателен, и drop в другой базовой цепочке на том же хуке всё равно срабатывает.［4］ Выполните sudo nft list ruleset | grep -B2 -A4 'hook forward'. Если у цепочки forward стоит policy drop, добавьте разрешение в том инструменте, которому эта цепочка принадлежит. Для UFW, например, используйте sudo ufw route allow proto tcp to 203.0.113.30 port 443 и такое же правило с proto udp, а не создавайте конкурирующую таблицу.

Шаг 3: или пересылайте ту же службу через GOST

Скачайте сборку для Linux из официального выпуска GOST v3.3.0, проверьте примечания к выпуску и опубликованные контрольные суммы и установите файл как /opt/gost/v3.3.0/gost с владельцем root и правами 0755.［5］ GOST читает файл YAML или JSON, переданный через -C.［6］ Сохраните конфигурацию как /etc/gost-relay/gost.yml:

services:
- name: relay-tcp
  addr: :8444
  handler:
    type: tcp
  listener:
    type: tcp
  forwarder:
    nodes:
    - name: landing-tcp
      addr: 203.0.113.30:443
- name: relay-udp
  addr: :8444
  handler:
    type: udp
  listener:
    type: udp
    metadata:
      keepAlive: true
      ttl: 30s
  forwarder:
    nodes:
    - name: landing-udp
      addr: 203.0.113.30:443

Когда keepAlive равен false, UDP-слушатель GOST закрывает канал сразу после ответа: это подходит для одиночных DNS-запросов, но ломает прокси на основе QUIC, которые обмениваются множеством пакетов. С keepAlive: true простаивающие каналы проверяются каждые ttl и закрываются не позже чем через два цикла простоя.［2］ Значение readBufferSize по умолчанию — 4096 байт, а более крупные UDP-пакеты обрезаются, поэтому оставьте его, если ваш протокол не отправляет датаграммы большего размера.

Создайте служебную учётную запись без входа gost-relay и юнит systemd, который запускает /opt/gost/v3.3.0/gost -C /etc/gost-relay/gost.yml от её имени с Restart=on-failure и NoNewPrivileges=true. Порт 8444 выше 1024, поэтому процессу не нужны дополнительные привилегии. Разрешите TCP и UDP 8444 во входящем файрволе ретранслятора; трафик GOST локален для ретранслятора, так что правило forward не требуется.

Шаг 4: направьте клиента на ретранслятор

Скопируйте рабочий профиль клиента и измените только адрес сервера на 198.51.100.10 и порт на 8443 (nftables) или 8444 (GOST). Имя сервера TLS, параметры REALITY, UUID и ключи оставьте как есть. Ни один из способов не завершает TLS, поэтому клиент по-прежнему проверяет сертификат или параметры REALITY конечного сервера сквозным образом.

Если исходный профиль использовал IP-адрес конечного сервера в качестве имени TLS, он продолжит работать через ретранслятор: проверка имени относится к сертификату, а не к адресу сокета. Сохраняйте прямой профиль как запасной, пока не пройдут проверки ниже.

Как проверить путь через ретранслятор и обратный трафик?

Способ проверки	Ожидаемое поведение	Если результат другой
Отправьте запрос через профиль с ретранслятором к своему эндпоинту	Ожидаемый ответ	Сначала проверьте прямой профиль, затем слушатели и правила ретранслятора
`sudo nft list table ip relay_nat` на ретрансляторе	Счётчики правил DNAT и masquerade растут	Нет счётчика DNAT — неверный интерфейс или порт; DNAT без masquerade — проверьте `ip daddr`
`sudo ss -tn state established '( sport = :443 )'` на конечном сервере	Собеседником указан адрес ретранслятора	Виден адрес клиента — SNAT отсутствует или трафик прошёл мимо ретранслятора
Запустите UDP-нагрузку через профиль с ретранслятором	Счётчики UDP растут, сессии не обрываются	Для GOST проверьте `keepAlive: true`, для nftables — правила UDP
Остановите только `gost-relay` и повторите подключение к 8444	Новые соединения не проходят, порт 8443 работает	Порт 8444 занят другим процессом или клиент использовал не тот профиль
Прямой профиль к конечному серверу	Работает или отклоняется, если вы ограничили конечный сервер ретранслятором	Приведите файрвол конечного сервера в соответствие с планом

Откройте инструмент проверки IP-адреса через профиль с ретранслятором. Он должен показать адрес выхода конечного сервера, а не ретранслятора, потому что ретранслятор несёт только входящий участок. Если позже вы построите цепочку, где на каждом переходе работает свой прокси-протокол, проверяйте её по переходам цепочки Xray, а не по этой таблице.

Как сохранить настройки, откатить и прибрать за собой?

Чтобы файл nftables загружался при старте, создайте небольшой однократный юнит relay-nat.service с владельцем root: он запускает /usr/sbin/nft -f /etc/nftables-relay/relay-nat.nft после network-online.target, задаёт RemainAfterExit=yes и использует ExecStop=/usr/sbin/nft delete table ip relay_nat. Включите его, перезагрузите сервер в окно обслуживания и повторите проверки счётчиков и собеседников. Файл sysctl уже сохраняет пересылку. Включайте gost-relay, только если оставляете способ с GOST.

Откат начинается с клиента: переключитесь на прямой профиль и проверьте новый запрос. На ретрансляторе выполните sudo systemctl disable --now relay-nat gost-relay, удалите добавленные правила UFW route или input и файл /etc/sysctl.d/90-relay-forward.conf, если пересылка больше ничему не нужна, затем выполните sudo sysctl --system. Сравните sudo nft list ruleset с сохранённой копией. Правило для ретранслятора на конечном сервере удаляйте последним.

Итоги

Ретранслятор переносит только точку входа; выходом остаётся конечный сервер, и нового расшифрования не происходит.
Для nftables нужны пересылка, DNAT, SNAT и разрешение в фильтре forward, согласованное с вашим менеджером файрвола.
GOST не требует пересылки в ядре, но должен держать UDP-каналы открытыми для длинных сессий.
Проверьте счётчики, собеседников на конечном сервере, UDP и адрес выхода, прежде чем отказываться от прямого профиля.

Часто задаваемые вопросы (FAQ)

Добавляет ли ретранслятор на VPS шифрование к трафику прокси?

Нет. Оба способа пересылают пакеты или потоки, не расшифровывая их. Шифрование по-прежнему обеспечивает прокси-протокол между вашим клиентом и конечным сервером.

Почему соединения зависают, когда настроен только DNAT?

Конечный сервер отвечает на исходный адрес клиента, а не ретранслятору. Добавьте SNAT или masquerade, чтобы ответы возвращались через отслеживание соединений на ретрансляторе.

Можно ли использовать GOST и nftables на одном ретрансляторе?

Да, на разных портах, как в этой инструкции. Не направляйте оба способа на один порт ретранслятора: правило DNAT перехватит пакеты раньше, чем их увидит GOST.

Увидит ли конечный сервер мой реальный адрес клиента?

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

Подходит ли UDP-пересылка GOST для прокси на основе QUIC?

Может подойти, если UDP-слушатель держит каналы открытыми. Установите keepAlive в true и разумный ttl, затем убедитесь, что длинные сессии через ретранслятор не обрываются.

Ускорит ли ретранслятор медленный конечный сервер?

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

Как убрать ретранслятор, не сломав другие правила файрвола?

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

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

Источники:

nftables wiki: Performing Network Address Translation (NAT) — https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)
GOST: Port forwarding — https://gost.run/en/tutorials/port-forwarding/
Linux kernel documentation: IP sysctl — https://docs.kernel.org/networking/ip-sysctl.html
nftables wiki: Configuring chains — https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains
GOST release v3.3.0 — https://github.com/go-gost/gost/releases/tag/v3.3.0
GOST: Command line reference — https://gost.run/en/reference/configuration/cmd/

Sources checked 14 октября 2026 г.

Рекомендуемые статьи:

Ретранслятор на VPS: nftables DNAT или GOST