Выбор SNI и донора: как не спалить маскировку

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

Что вообще такое донор и SNI

Напомню механику коротко. Reality маскирует твою ноду под чужой большой сайт — это и есть донор. В момент рукопожатия клиент отправляет TLS ClientHello с именем донора в поле SNI (Server Name Indication) — это имя идёт открытым текстом, и именно его читает DPI. Твоя задача — чтобы это имя было настолько «белым» и обычным, что резать его никто не станет.

Два параметра в конфиге завязаны на донор: serverNames (имя, которое клиент показывает в SNI) и target/dest (куда нода реально проксирует чужой трафик и активные пробы). В классическом Reality они указывают на один и тот же чужой сайт и должны совпадать. Весь стелс держится на том, насколько удачно выбран этот сайт.

Каким должен быть хороший донор

Из практики — критерии, которые реально важны, а не «на глаз красиво»:

• TLS 1.3. Донор обязан поддерживать современный TLS 1.3. На старом TLS маскировка не соберётся корректно, и профиль рукопожатия будет отличаться от того, что ожидает клиент.
• Крупный, живой, нейтральный. Большой популярный ресурс, к которому DPI заведомо не придирается. Чем обыденнее визит на этот сайт из твоего региона, тем лучше — трафик на него не вызывает вопросов.
• Стабильный. Донор должен быть всегда доступен. Если он ляжет или сменит инфраструктуру, твоя нода перестанет корректно маскироваться — активная проба попадёт в никуда.
• Не за CDN. Это важный и неочевидный пункт. Донор за Cloudflare или другим CDN — плохой выбор: у CDN своя логика сертификатов и своё поведение, которое ломает переиспользование рукопожатия. Бери домен на собственной инфраструктуре, не за фронтом.
• Не твой. В классическом Reality донор — это именно чужой сайт. Свой домен в этой схеме не участвует вообще (кроме варианта selfsteal, где логика обратная — о нём ниже).

Каким донор быть не должен

Ошибки, которые убивают маскировку:

• Заблокированный или спорный домен. Если сам донор зарезан в твоём регионе или к нему уже есть претензии у DPI — ты маскируешься под то, что и так под подозрением. Это хуже, чем никакой маскировки.
• Мелкий или редкий сайт. Визит на малоизвестный ресурс сам по себе статистически необычен. Донор должен быть таким, к которому ходят массово.
• Донор за CDN. Повторю, потому что на этом часто спотыкаются: CDN ломает схему. Проверяй, что домен резолвится в собственные адреса, а не в диапазоны Cloudflare.
• Один и тот же на всех нодах. Об этом — отдельно, потому что это самая частая и самая дорогая ошибка.

Почему нельзя один SNI на все ноды

Соблазн понятен: нашёл хороший донор — поставил его везде. Так делать нельзя, и вот почему. Если у тебя двадцать нод и на всех один и тот же serverNames, то с точки зрения наблюдателя двадцать разных IP в разных дата-центрах вдруг все маскируются под один и тот же сайт. Это статистическая аномалия: реальный сайт живёт на своей инфраструктуре, а не «размазан» по двадцати случайным адресам. Как только DPI связывает этот SNI с паттерном «VPN», под одну блокировку уходят все твои ноды разом.

Отсюда правило: ротируй доноры между нодами. Разные ноды — разные serverNames. Тогда блокировка одного донора снимает одну ноду, а не весь сервис. И после каждой волны блокировок меняй доноры и порты на пострадавших — не жди, пока отравят следующий.

Рассинхрон «SNI ≠ владелец IP»

Главный концептуальный подвох классического Reality, который надо понимать. Ты ставишь serverNames = имя чужого донора, но этот домен не резолвится в IP твоей ноды. При достаточно глубоком анализе DPI может сопоставить: «в SNI заявлен microsoft.com, а IP принадлежит какому-то хостеру в непонятной стране, и microsoft.com в этот адрес не резолвится». Это рассинхрон между заявленным именем и владельцем адреса.

Для большинства сценариев этого мало для блокировки — ложных срабатываний было бы слишком много, ведь легитимных причин для такого расхождения тоже хватает. Но под самым жёстким DPI это зацепка, и её надо закрывать.

Закрывается она selfsteal: вместо чужого донора нода маскируется под твой собственный сайт на том же IP. Тогда serverNames — это твой домен, он резолвится в ноду, на нём живёт настоящая страница, активная проба попадает на реальный сайт именно по этому адресу. SNI, IP и контент согласованы — рассинхрона нет. Это самый стойкий вариант, ему посвящена отдельная пара статей. Плата — нужен свой домен и сайт-обманка на ноде.

Как принять решение

Сведу к рабочему чек-листу:

• Под обычный DPI хватает чужого донора — крупный нейтральный сайт с TLS 1.3, не за CDN, не твой, живой и стабильный.
• Под жёсткий DPI уходи на selfsteal — свой домен, свой сайт на ноде, никакого рассинхрона.
• Всегда ротируй доноры и SNI между нодами — один SNI на всех убивает весь сервис одной блокировкой.
• После каждой волны меняй доноры и порты на пострадавших нодах.

Выбор донора — это не мелочь в конце настройки, а половина стойкости всей схемы. Как selfsteal технически убирает рассинхрон и делает маскировку идеальной — в статьях про selfsteal.