12.07.2025 05:29
cyberscoper 20 4500 Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Ваш клиент шифрует трафик и отправляет на сервер‑посредник (Middleman).

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

  3. Трафик ЗАНОВО ЗАШИФРОВЫВАЕТСЯ и отправляется на конечный сервер (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 рублей в месяц (скриншот из корзины прилагается).

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

  1. Настройте вход только по SSH-ключам. Отключите пароли и вход для root в /etc/ssh/sshd_config. Смените стандартный порт SSH с 22 на любой другой. Это не рекомендация, а требование.

  2. Установите и настройте файрвол UFW. Сразу после установки разрешите только ваш новый SSH-порт и включите его.

    sudo apt install ufw -y
sudo ufw allow <ваш_новый_ssh_порт>/tcp
sudo ufw enable

  3. Отключите 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

  4. Безопасно установите 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 (Европа)

  1. Откройте в UFW порт для VLESS (например, 20001): sudo ufw allow 20001/tcp.

  2. В панели идем в «Входящие» → «+ Добавить входящее».

  3. Настраиваем VLESS+Reality. В качестве "донора" (SNI) используйте какой-либо крупный сайт-донор, найденный сканером RealiTLScanner.

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

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

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

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

  1. Подключитесь по SSH к вашему Gate-серверу (или любому другому "расходному" VPS или используйте WSL с Linux).

  2. Перейдите на страницу официальных релизов сканера: https://github.com/XTLS/RealiTLScanner/releases.

  3. Найдите самый свежий релиз (он будет наверху). В секции "Assets" найдите файл с названием RealiTLScanner-linux-64.

  4. Скопируйте ссылку на этот файл (правой кнопкой мыши → "Копировать ссылку").

  5. Вернитесь в терминал и скачайте его. Чтобы не возиться с длинным именем, мы сразу скачаем его под коротким именем RealiTLScanner с помощью флага -O:

    # ВАЖНО: Замените ссылку на актуальную со страницы релизов!
wget -O RealiTLScanner https://github.com/XTLS/RealiTLScanner/releases/download/v0.2.1/RealiTLScanner-linux-64

  6. Теперь сделаем скачанный файл исполняемым:

    chmod +x RealiTLScanner

  7. Наконец, запускаем сканирование! Укажем несколько популярных сайтов для проверки и увеличим количество потоков для скорости:

    ./RealiTLScanner -addr www.microsoft.com,www.google.com,www.amazon.com -thread 20

  8. Смотрите на вывод. Вам нужны строки с 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-сервера самый быстрый доступ. Логика проста: чем быстрее отвечает "настоящий" сайт, на который мы притворяемся похожими, тем меньше аномалий в поведении нашего сервера.

  1. Из списка, который выдал ./RealiTLScanner, выберите несколько доменов крупных компаний (например, microsoft.com, cloudflare.com, digitalocean.com и т.д.).

  2. Находясь в терминале вашего Gate-сервера (это важно!), пропингуйте IP-адреса этих доноров.

    ping <IP-адрес_или_домен_из_сканера>

    1. Смотрите на значение time=. Чем оно меньше, тем лучше. В идеале — меньше 10 мс.

      Найденный мною "идеальный" кандидат.
      Найденный мною "идеальный" кандидат.

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

  1. Копируем его данные: 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. Это наш мост во внешний мир.

  1. Идем в «Настройки XRAY» → «Исходящие (Аутбанды)» → «+ Создать Аутбанд».

  2. Заполняем поля, используя все те данные, что мы бережно скопировали на шаге 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.

  3. Сохраняем.

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

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

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

  1. Идем в «Входящие» → «+ Добавить входящее».

  2. Настраиваем соединение, которое будет "смотреть" на вас:

    • Примечание: client-in-reality (для себя, чтобы не запутаться).

    • Протокол: vless.

    • Порт: 443.

    • Безопасность (TLS): выбираем reality.

    • Dest (Target): www.microsoft.com:443 (или другой надежный сайт-донор, который вы выбрали. Он не обязан совпадать с тем, что используется на Gate).

    • SNI: www.microsoft.com (должен совпадать с Dest).

    • Нажимаем «Get New Cert», чтобы сгенерировать новые, уникальные ключи для этого соединения. Не используйте ключи от Gate!

  3. Сохраняем.

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

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

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

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

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

  1. Заходим в панель 3x-ui на Middleman-сервере.

  2. Переходим в раздел «Настройки Xray» (в некоторых версиях — «Маршрутизация»).

  3. Нажимаем «+ Создать правило».

  4. Заполняем всего два поля:

    • В секции Inbound (условие на входе): Port → вписываем 443.

    • В секции Outbound (действие на выходе): Outbound Tag → из выпадающего списка выбираем наш gate-out.

Скриншот настройки правила маршрутизации в 3x-ui
Скриншот настройки правила маршрутизации в 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. Клиент и финальная проверка

  1. Используйте клиент с поддержкой TUN/TAP (Nekoray для ПК, v2rayNG для Android). Это гарантирует, что весь трафик вашей системы, включая DNS, пойдет в туннель.

  2. Подключитесь, используя конфиг от вашего узла Middleman.

  3. Зайдите на ipleak.net и browserleaks.com/webrtc.

  4. Убедитесь, что:

    • Ваш IP и DNS-серверы соответствуют местоположению сервера Gate (Европа).

    • WebRTC не раскрывает ваш реальный IP.

    • Встроенный "Secure DNS" в вашем браузере отключен, чтобы он не конфликтовал с VPN.

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

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

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

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

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

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

Комментарии (20)