Каскад через HAProxy

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

HAProxy-прослойка решает ту же задачу иначе: она вообще не разбирает трафик. Просто перекладывает TCP-байты с чистого IP на ваш сервер, где и происходит вся криптография. Со стороны провайдера и ТСПУ клиент ходит на российский адрес, а со стороны прослойки это поток шифрованного мусора, который она не может прочитать при всём желании.

📖 Незнакомые слова? Все термины простыми словами смотрите в Словаре терминов.

Это промышленная замена самодельному релею на socat/iptables из статьи «Каскад через РФ-релей»: тот же принцип, но с валидацией конфига, graceful-reload без обрыва сессий и маршрутизацией по SNI.

Две схемы каскада: обе рабочие, но разные

Обе схемы живут в проде и обе работают отлично, просто под разные задачи. Разбор ниже основан на живых конфигах.

⭐ Важно: это не «или-или». Реальные операторы держат обе схемы одновременно, каждую под свою задачу. Ниже разберём именно такой боевой случай.

Живой пример: обход белых списков

Самая показательная задача для L4-прослойки: обход белых списков. Когда мобильный оператор в период ограничений пускает трафик только на «разрешённые» отечественные адреса, заграничная нода недостижима в принципе: телефон до неё просто не дойдёт, каким бы хорошим ни был протокол.

Лечится это единственным способом: точка входа должна быть российской. Рабочая топология:

Клиент (РФ, мобильный)
      │  ходит на РОССИЙСКИЙ адрес — проходит белый список
      ▼
Белый РФ-IP : 40002        ← HAProxy, mode tcp, passthrough
      │  перекладывает байты, НЕ расшифровывает
      ▼
Нода в Германии : 443      ← здесь Reality, ключи, весь VPN
      │
      ▼
   Интернет

В панели Remnawave это выглядит так: у хоста адрес входа российский (белый_IP:40002), а нода, к которой он привязан, физически стоит в Германии. Клиент видит один сервер, а по факту трафик идёт через два.

Что важно понять: немецкая нода настроена как обычно: Reality, свои ключи, свой SNI. Её вообще не переделывали под каскад. Всё, что сделали: поменяли у хоста адрес входа на российский. Это и есть главная прелесть L4-прослойки: конечный сервер не знает, что перед ним кто-то стоит.

Тот же самый оператор параллельно использует классический xray-каскад для других нод, где нужен роутинг. Одна схема не отменяет другую.

Как выглядит HAProxy-прослойка

Основа предельно простая. mode tcp означает «не лезь в содержимое, ты работаешь на 4-м уровне»:

global
  log /dev/log local0
  maxconn 20000
defaults
  mode tcp
  timeout connect 5s
  timeout client 60s
  timeout server 60s

listen p1
  bind *:40001
  server t 203.0.113.10:443

Всё. Клиент подключается на ЧИСТЫЙ_IP:40001, а байты уезжают на 203.0.113.10:443, где стоит его Reality-нода. Прослойка не завершает TLS: она физически не может прочитать поток, у неё нет ключей.

В панели клиента меняется только адрес и порт хоста. SNI, Reality-ключи, сертификаты остаются как были, на его сервере.

Схема 1: порт на арендатора (простая)

Каждому клиенту свой порт входа: 40001, 40002, 40003… По одному listen-блоку на каждого. Это то, как устроена аренда белых IP: один сервер обслуживает несколько независимых арендаторов, каждый со своим портом и своим конечным сервером.

Плюс: не нужен домен, поднимается за секунду. Минус: TLS на нестандартном порту выглядит подозрительнее для DPI, чем на 443.

Схема 2: SNI-маршрутизация на 443 (много клиентов, один порт)

Если нужно, чтобы все клиенты ходили на приличный 443, HAProxy умеет разбирать TLS-хендшейк и смотреть на SNI (имя домена, которое клиент открыто пишет в начале рукопожатия), не расшифровывая при этом сам трафик:

frontend fe443
  bind *:443
  tcp-request inspect-delay 5s
  tcp-request content accept if { req.ssl_hello_type 1 }
  use_backend be1 if { req.ssl_sni -i node1.example.com }
  use_backend be2 if { req.ssl_sni -i node2.example.com }
  default_backend be_drop

backend be1
  server s1 10.0.0.11:443
backend be2
  server s2 10.0.0.12:443

backend be_drop
  timeout server 1s

Как читать: ждём TLS-приветствие (inspect-delay + ssl_hello_type 1), достаём из него SNI и по имени домена отправляем в нужный бэкенд. У каждого клиента свой домен с A-записью на общий IP.

У default_backend be_drop есть важная деталь: всё, что пришло с незнакомым SNI (сканеры, боты, случайные пробы), уходит в никуда с коротким таймаутом, а не получает ответ.

⚠️ SNI виден на проводе, это не секрет, а поле хендшейка. Схема скрывает содержимое и конечный IP, но не сам факт обращения к домену. Для РФ имя домена должно выглядеть безобидно.

⚠️ UDP: HAProxy его не умеет

Самая частая засада. HAProxy проксирует только TCP. Если у клиента Hysteria2 или любой QUIC, через listen он не пройдёт, и это выглядит как «протокол не работает без причины».

Решение: пробрасывать UDP мимо HAProxy, средствами ядра:

nft add rule ip nat prerouting udp dport 40001 dnat to 203.0.113.10:443

То есть в боевой связке TCP идёт через HAProxy, а UDP идёт через nft-DNAT. Именно так сделано на аренде: HAProxy держит TCP-порты, а рядом лежат nft-правила udp dport … dnat to … для Hysteria2.

Не забудьте открыть порт в файрволе: и TCP, и UDP:

ufw allow 40001/tcp
ufw allow 40001/udp

Учёт трафика: счётчиками ядра

Раз HAProxy не разбирает трафик, считать гигабайты удобнее в nftables: это дёшево и не врёт:

table ip bsnode {
  counter n1_in {}
  counter n1_out {}
  chain cin  { type filter hook input  priority filter; policy accept;
    tcp dport 40001 counter name "n1_in" }
  chain cout { type filter hook output priority filter; policy accept;
    tcp sport 40001 counter name "n1_out" }
}

⚠️ Грабля с счётчиками: delete table обнуляет счётчики в ядре у всех сразу. Если вы пересоздаёте таблицу при добавлении нового клиента, снимайте показания в файл-накопитель ДО пересоздания, иначе каждая новая продажа стирает учёт остальным арендаторам.

Обязательная привычка: валидировать конфиг до применения

HAProxy умеет проверять конфиг, не трогая работающий сервис. Это спасает от «положил всех, пока добавлял одного»:

haproxy -c -f /etc/haproxy/haproxy.cfg.tmp && \
  mv /etc/haproxy/haproxy.cfg.tmp /etc/haproxy/haproxy.cfg && \
  systemctl reload haproxy

reload (в отличие от restart) поднимает новый процесс и доносит старые соединения: активные клиенты не рвутся. Если конфиг невалиден, просто не применяем, старый остаётся живым.

💡 Ещё нюанс: HAProxy требует хотя бы один listener. Если удалить последнего клиента, конфиг станет невалидным («no listener»). Держите пустой health-frontend: frontend _hb mode http bind 127.0.0.1:9998 http-request return status 200 content-type text/plain string ok

Что выбрать: HAProxy или обычный каскад

Берите HAProxy-прослойку, если: - нужно, чтобы вход не мог читать трафик: вы сдаёте IP в аренду, или клиент не готов отдавать вам ключи; - конечный сервер уже настроен, и его не хочется трогать (меняется только адрес хоста); - нужен дешёвый вход: без крипты HAProxy почти не ест CPU, на копеечной VPS тянет тысячи соединений; - клиентов много и они независимы друг от друга.

Берите Xray-каскад, если: - нужна маршрутизация по доменам, например YouTube через РФ-выход, остальное через Европу. L4-прослойка так не умеет в принципе, она про байты, а не про домены; - нужен Hysteria2/QUIC без плясок с DNAT; - всё хозяйство ваше, и одна панель управления важнее изоляции; - хотите менять точку выхода, не трогая клиента.

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

Грабли, на которых спотыкаются

1. Забыли UDP. Hysteria2 «не работает», хотя TCP-протоколы летают. Причина в первом абзаце раздела про UDP: HAProxy его не проксирует.

2. Двойной хоп и MTU. Каждый лишний слой съедает место в пакете. Вкладывать TLS в TLS в TLS не выйдет, подробности и лечение через tcpMaxSeg описаны в «Тройной каскад».

3. Таймауты. Дефолтные 60 секунд рвут долгие простаивающие сессии. Для VPN-трафика поднимайте timeout client/timeout server до нескольких часов, иначе клиенты будут жаловаться на «отваливается, когда не пользуюсь».

4. Прослойка знает IP конечного сервера. Это неизбежно: она туда ходит. Если модель угроз требует спрятать и его, нужен ещё один хоп (см. тройной каскад).

5. Абуз через ваш IP. Вы отдаёте наружу свой чистый адрес. Минимальная гигиена на прослойке: резать SMTP и лимитировать новые соединения:

tcp dport 25 drop
ct state new limit rate over 400/second drop

Итого

HAProxy-каскад это «глупая труба», и в этом его сила: он не видит трафик, почти не ест ресурсы, поднимается тремя строками и не требует ключей на входе. Взамен вы теряете маршрутизацию по доменам и штатный UDP.

Xray-каскад наоборот: умный, гибкий, с роутингом, но вход расшифровывает трафик, и мест сломаться заметно больше.

Не выбирайте «лучшее вообще», выбирайте под задачу. Сдаёте IP в аренду или бережёте ключи → HAProxy. Нужен YouTube через РФ и Hysteria2 → обычный каскад.