Привет, Хабр!

Помните то блаженное время, когда для доступа к любому ресурсу хватало простого WireGuard до сервера в Германии? Я тоже помню. Но эта эпоха закончилась. Недавно я заметил, что мой верный VPN стал лагать, рвать соединение и вести себя так, будто его кто‑то целенаправленно «душит». Это был тот самый момент, когда я понял: игра изменилась. Системы глубокого анализа трафика (DPI) стали умнее, и мой трафик для них был как на ладони.

Это стало моим личным вызовом. Я отправился в путешествие по миру современных средств обхода блокировок, наступил на множество граблей (чего только стоит осознание, что «двойное шифрование» — это миф!), но в итоге нашел свое сокровище — рабочую и относительно устойчивую схему на базе VLESS+Reality и Multi‑hop.

Эта статья — не «серебряная пуля». Это честный, подробный и, надеюсь, полезный гайд по постройке сложной VPN‑цепочки. Мы разберем ее архитектуру, честно поговорим о рисках и соберем все по шагам.

Часть 1. Философия и архитектура: почему просто — уже не работает

1.1. Проблема: Почему одного сервера в ЕС недостаточно?

Все просто: протоколы вроде WireGuard и OpenVPN, при всей их крутости, имеют узнаваемые "отпечатки пальцев" (сигнатуры). Современные системы DPI на трансграничных переходах научились эти сигнатуры видеть и прицельно бить по таким соединениям. Отсюда и лаги, и разрывы.

Вывод: нужно маскироваться.

1.2. Архитектура: Multi-hop — прячемся в толпе

Мы не будем подключаться напрямую. Вместо этого мы пропустим трафик через промежуточный узел, маскируя его под обычный HTTPS на каждом этапе.

1.3. Главный компромисс: Опасная сказка о "двойном шифровании"

Давайте сразу проясним: это НЕ двойное шифрование. Любой, кто говорит обратное, либо не разбирается в теме, либо намеренно вводит вас в заблуждение.

Вот как это работает на самом деле:

Ваш клиент шифрует трафик и отправляет на сервер‑посредник (Middleman).
На Middleman трафик РАСШИФРОВЫВАЕТСЯ (пусть и только в оперативной памяти), чтобы ядро Xray поняло, куда его направить дальше.
Трафик ЗАНОВО ЗАШИФРОВЫВАЕТСЯ и отправляется на конечный сервер (Gate).

Это фундаментальный риск: на промежуточном сервере ваш трафик на короткий миг существует в незашифрованном виде. И это подводит нас к самому главному выбору.

1.4. Критический выбор: Где разместить сервер-посредник?

Схема А (Приоритет: низкий пинг)
- Маршрут: Клиент (РФ) → VPS в РФ (Middleman) → VPS в ЕС (Gate)
- Плюс: Минимальная задержка, все летает.
- МИНУС (КРИТИЧЕСКИЙ): Вы доверяете свой расшифрованный трафик серверу, который физически находится в российской юрисдикции. Это огромный и, на мой взгляд, неоправданный риск для приватности.
Схема Б (Приоритет: безопасность)
- Маршрут: Клиент (РФ) → VPS в условно-нейтральной стране (Middle-man) → VPS в ЕС/США (Gate)
- Примеры стран: Турция, Сербия, Казахстан, Армения.
- Плюс: Юрисдикционный риск снижен на порядок.
- Минус: Пинг будет выше. Вы жертвуете скоростью ради приватности.

В этом гайде я рекомендую реализовывать Схему Б (с сервером в нейтральной стране) как единственно зрелый и безопасный вариант. Однако, для демонстрации и из соображений минимального пинга, шаги ниже будут описаны для Схемы А (сервер‑посредник в РФ). Имейте в виду, что настройка для Схемы Б абсолютно идентична — вам просто нужно выбрать VPS в другой локации.

1.5. Другие риски, о которых нельзя забывать

Атака по корреляции трафика: Это "ахиллесова пята" нашей схемы. Даже при полном шифровании, наблюдатель, имеющий доступ к данным на входе и выходе нашего сервера-посредника (например, ваш провайдер и провайдер дата-центра), может сопоставить паттерны трафика (время, объем, интенсивность пакетов). Таким образом, можно с высокой вероятностью доказать факт того, что вы используете именно эту цепочку для выхода в интернет. Защита от таких атак — удел сложных систем вроде Tor, и в нашей простой схеме этот риск нужно просто принять как данность.
Утечки на клиенте: Неправильно настроенный браузер или ОС могут слить ваш реальный IP через DNS, WebRTC или IPv6, делая всю схему бесполезной.

Часть 2. Инструменты: Панель 3x-ui — удобный "костыль"

В гайдах часто советуют: "Забудьте о ручном редактировании JSON". Это плохой совет. Панель управления 3x-ui — это фантастически удобный инструмент для быстрой настройки, но вы обязаны понимать ее недостатки:

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

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

Часть 3. Подготовка серверов: гигиена превыше всего

Нам понадобятся два самых дешевых VPS на Ubuntu 22.04 (1 vCPU, 512MB RAM). Один в "нейтральной" стране (Middleman), другой — в Европе (Gate).

Кстати, после недолгих поисков удалось найти очень выгодный вариант у неназываемого хостера всего за 75 рублей в месяц (скриншот из корзины прилагается).

На ОБОИХ серверах выполняем эти обязательные шаги:

Настройте вход только по SSH-ключам. Отключите пароли и вход для root в /etc/ssh/sshd_config. Смените стандартный порт SSH с 22 на любой другой. Это не рекомендация, а требование.
Установите и настройте файрвол UFW. Сразу после установки разрешите только ваш новый SSH-порт и включите его.
```
sudo apt install ufw -y
sudo ufw allow <ваш_новый_ssh_порт>/tcp
sudo ufw enable
```

Отключите IPv6, если не используете его, чтобы избежать утечек.

Не обязательный шаг но думаю стоит его исполнить.

# Чтобы надежно отключить IPv6, добавьте эти строки в /etc/sysctl.conf
sudo nano /etc/sysctl.conf
# В конец файла добавьте:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
# Сохраните файл и примените изменения командой:
sudo sysctl -p

Безопасно установите 3x-ui.Лайфхак: Никогда, слышите, НИКОГДА не выполняйте скрипты из интернета через bash <(curl ...)! Это открывает двери для чего угодно.

# Сначала скачиваем скрипт
curl -o install.sh -L https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh
# Потом внимательно просматриваем его содержимое глазами
less install.sh
# И только после этого запускаем
bash install.sh

Часть 4. Пошаговая настройка цепочки

4.1. Защита панели управления (сразу после установки!)

Не открывайте порт панели в UFW! Мы будем получать к ней доступ только через безопасный SSH-туннель.

Лайфхак: Проброс порта через SSH
На вашем локальном компьютере выполните команду:

ssh -L 8080:localhost:<порт_панели> user@your_server_ip

Теперь панель будет доступна в вашем браузере по адресу http://localhost:8080, при этом снаружи она будет полностью закрыта.

Зайдя в панель, немедленно идите в «Настройки панели» и смените стандартные логин, пароль и Путь к панели.

4.2. Настройка узла Gate (Европа)

Откройте в UFW порт для VLESS (например, 20001): sudo ufw allow 20001/tcp.
В панели идем в «Входящие» → «+ Добавить входящее».
Настраиваем VLESS+Reality. В качестве "донора" (SNI) используйте какой-либо крупный сайт-донор, найденный сканером RealiTLScanner.

Лайфхак: Как найти идеального "донора" для Reality с помощью RealiTLScanner

Выбор правильного сайта-донора (dest и sni) — это 80% успеха маскировки. Сайт должен быть крупным, надежным и использовать современные стандарты TLS. Искать его вручную — долго и неэффективно. Для этого существует специальный инструмент — RealiTLScanner.

Критически важно: Никогда не запускайте сканер с вашего домашнего компьютера или с важных серверов! Сканирование множества IP-адресов может привести к тому, что ваш IP попадет в черные списки. Идеальный вариант — запустить его с "одноразового" или некритичного VPS, который не жалко "засветить". Например, с того самого Gate-сервера, который мы настраиваем.

Вот простая инструкция, как им пользоваться:

Подключитесь по SSH к вашему Gate-серверу (или любому другому "расходному" VPS или используйте WSL с Linux).
Перейдите на страницу официальных релизов сканера: https://github.com/XTLS/RealiTLScanner/releases.
Найдите самый свежий релиз (он будет наверху). В секции "Assets" найдите файл с названием RealiTLScanner-linux-64.
Скопируйте ссылку на этот файл (правой кнопкой мыши → "Копировать ссылку").
Вернитесь в терминал и скачайте его. Чтобы не возиться с длинным именем, мы сразу скачаем его под коротким именем RealiTLScanner с помощью флага -O:
```
# ВАЖНО: Замените ссылку на актуальную со страницы релизов!
wget -O RealiTLScanner https://github.com/XTLS/RealiTLScanner/releases/download/v0.2.1/RealiTLScanner-linux-64
```
Теперь сделаем скачанный файл исполняемым:
```
chmod +x RealiTLScanner
```
Наконец, запускаем сканирование! Укажем несколько популярных сайтов для проверки и увеличим количество потоков для скорости:
```
./RealiTLScanner -addr www.microsoft.com,www.google.com,www.amazon.com -thread 20
```
Смотрите на вывод. Вам нужны строки с feasible=true, tls=1.3 и alpn=h2.
```
2024/05/20 10:30:15 INFO Connected to target feasible=true host=13.107.21.200 tls=1.3 alpn=h2 domain=www.microsoft.com issuer="Microsoft"
```
Домен www.microsoft.com — отличный кандидат. Его и используем для Dest (Target) и SNI.

Итак, RealiTLScanner выдал нам список из десятков технически подходящих сайтов. Но какой из них выбрать? Чтобы сделать нашу маскировку еще убедительнее, мы выберем тот, до которого у нашего Gate-сервера самый быстрый доступ. Логика проста: чем быстрее отвечает "настоящий" сайт, на который мы притворяемся похожими, тем меньше аномалий в поведении нашего сервера.

Из списка, который выдал ./RealiTLScanner, выберите несколько доменов крупных компаний (например, microsoft.com, cloudflare.com, digitalocean.com и т.д.).
Находясь в терминале вашего Gate-сервера (это важно!), пропингуйте IP-адреса этих доноров.
```
ping <IP-адрес_или_домен_из_сканера>
```
1. Смотрите на значение time=. Чем оно меньше, тем лучше. В идеале — меньше 10 мс.
  Найденный мною "идеальный" кандидат.

Именно этот домен вы и будете использовать в полях Dest (Target) и SNI при настройке Reality. Теперь, когда у нас есть надежный донор, продолжим настройку.

Копируем его данные: UUID, Порт, Public Key, один Short ID, SNI. Они понадобятся для Middleman.

4.3. Настройка узла Middleman (Нейтральная страна) — мозг операции

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

Сначала открываем порт в файрволе для клиента:

sudo ufw allow 443/tcp

Почему именно 443? Это не техническое, а логическое требование для маскировки. Мы имитируем обычный HTTPS-трафик, а он всегда "живет" на порту 443. Использование другого порта — это аномалия, которая сразу бросается в глаза системам анализа.

Теперь заходим в защищенную SSH-туннелем панель 3x-ui и выполняем два ключевых шага.

4.3.1. Создаем исходящий туннель в Европу (Outbound)

Сначала научим наш Middleman-сервер "ходить" на Gate. Это наш мост во внешний мир.

Идем в «Настройки XRAY» → «Исходящие (Аутбанды)» → «+ Создать Аутбанд».
Заполняем поля, используя все те данные, что мы бережно скопировали на шаге 4.2 с узла Gate:
- Протокол: vless
- Тег: gate-out (это очень важно для последующей маршрутизации, назовите его осмысленно!)
- Адрес: IP-адрес вашего сервера Gate (в Европе).
- Порт: 20001 (или тот, который вы открыли на Gate).
- ID пользователя (UUID): UUID с сервера Gate.
- Безопасность (TLS): выбираем reality. Да, мы используем Reality и на этом участке. Это может показаться избыточным для канала между дата-центрами, но добавляет еще один слой маскировки и унифицирует нашу конфигурацию.
- SNI: тот же SNI, что вы указали на Gate.
- Public Key: Public Key, сгенерированный на Gate.
- Short ID: Short ID, скопированный с Gate.
Сохраняем.

Теперь наш сервер-посредник знает, как связаться с конечным узлом.

4.3.2. Создаем входящее соединение для клиента (Inbound)

Теперь откроем "дверь" для себя. Это та самая точка входа, к которой будет подключаться ваш клиентский софт.

Идем в «Входящие» → «+ Добавить входящее».
Настраиваем соединение, которое будет "смотреть" на вас:
- Примечание: client-in-reality (для себя, чтобы не запутаться).
- Протокол: vless.
- Порт: 443.
- Безопасность (TLS): выбираем reality.
- Dest (Target): www.microsoft.com:443 (или другой надежный сайт-донор, который вы выбрали. Он не обязан совпадать с тем, что используется на Gate).
- SNI: www.microsoft.com (должен совпадать с Dest).
- Нажимаем «Get New Cert», чтобы сгенерировать новые, уникальные ключи для этого соединения. Не используйте ключи от Gate!
Сохраняем.

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

4.3.3. Связываем всё воедино: настройка маршрутизации

Отлично. Мы настроили вход для клиента и выход в Европу. Но сейчас они живут каждый своей жизнью. Наш Middleman-сервер пока не знает, что трафик, пришедший от клиента, нужно отправлять в туннель до Gate-сервера. Этот шаг — как клей, который скрепляет всю конструкцию. Без него ничего не заработает.

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

Важно понимать: его главный недостаток в том, что это правило будет перехватывать абсолютно весь трафик с порта 443. Если вы в будущем захотите повесить на этот же IP и порт, например, свой сайт, это правило придется переделывать на более сложное (по тегу входящего соединения, как в Способе 1). Но для нашей цели это — быстрый и надежный вариант.

Заходим в панель 3x-ui на Middleman-сервере.
Переходим в раздел «Настройки Xray» (в некоторых версиях — «Маршрутизация»).
Нажимаем «+ Создать правило».
Заполняем всего два поля:
- В секции Inbound (условие на входе): Port → вписываем 443.
- В секции Outbound (действие на выходе): Outbound Tag → из выпадающего списка выбираем наш gate-out.

*Скриншот настройки правила маршрутизации в 3x-ui*

Сохраняем правило и перезапускаем ядро Xray.

Теперь логика работы сервера безупречна: всё, что прилетело на порт 443, автоматически заворачивается в туннель до нашего европейского сервера. Middleman превратился из простого сервера в умный и скрытный маршрутизатор.

4.4. Тонкая настройка ядра: DNS, логи

DNS-over-HTTPS (DoH): На обоих серверах в «Настройках Xray» → «Настройки DNS» впишите адреса DoH: https://1.1.1.1/dns-query,https://dns.google/dns-query. Это заставит Xray обрабатывать все DNS-запросы внутри себя, не допуская утечек.
Отключение логов: В «Настройках Xray» на обоих серверах отключите «Логи». Меньше логов — меньше цифровых следов.

Перезапустите Xray на обоих серверах кнопкой в панели.

Часть 5. Клиент и финальная проверка

Используйте клиент с поддержкой TUN/TAP (Nekoray для ПК, v2rayNG для Android). Это гарантирует, что весь трафик вашей системы, включая DNS, пойдет в туннель.
Подключитесь, используя конфиг от вашего узла Middleman.
Зайдите на ipleak.net и browserleaks.com/webrtc.
Убедитесь, что:
- Ваш IP и DNS-серверы соответствуют местоположению сервера Gate (Европа).
- WebRTC не раскрывает ваш реальный IP.
- Встроенный "Secure DNS" в вашем браузере отключен, чтобы он не конфликтовал с VPN.

Часть 6. Трезвый взгляд на результат и что дальше

Поздравляю! Мы построили сложную, многоуровневую систему. Она не является неуязвимой "серебряной пулей", но это разумный и зрелый компромисс между стабильностью, производительностью и безопасностью для личного пользования в текущих реалиях.

Поддерживайте систему: Регулярно обновляйте ОС и 3x-ui. Гонка вооружений не прекращается.
Продолжайте учиться: Следите за новостями в сфере блокировок. Сегодняшнее решение может потребовать адаптации уже завтра.

Надеюсь, этот честный гайд был полезен.

А теперь открытый вопрос к вам, Хабр: Какой путь в этой "гонке вооружений" выбрали вы? Используете multi-hop, нашли другие элегантные решения на базе Shadowsocks, или, может, верите в будущее AmneziaVPN? Делитесь своим опытом и граблями в комментариях.

Frontender`s Spectre

VLESS+Reality и Multi-hop: Архитектура VPN-цепочки для нового поколения блокировок

Как починить GoodbyeDPI, если он перестал работать 22.09.24