Как поднять устойчивый VPN-сервер, который переживёт белые списки

Почему обычный VPS блокируется первым

Сценарий «арендовал VPS, поставил Xray, раздал ключи» работает ровно до первого серьёзного витка блокировок. Причин, по которым такой сервер отваливается, три, и различать их обязательно — от этого зависит стратегия устойчивости.

• Блок по IP. Самый грубый метод: адрес или целая /24 хостера уезжает в чёрный список ТСПУ. Лечится сменой IP, но это гонка, которую вы проигрываете по времени.
• DPI по сигнатуре протокола. ТСПУ распознаёт рукопожатие Shadowsocks / старого VLESS / OpenVPN по паттернам и рвёт коннект. Лечится маскировкой (Reality, XHTTP под TLS реального сайта).
• Белые списки (самое опасное). В зонах жёсткой фильтрации логика инвертируется: пропускается трафик только к *разрешённым* сетям (банки, госуслуги, крупные российские хостеры и CDN), а всё прочее — в первую очередь любые зарубежные дата-центровые IP — режется по умолчанию. Здесь не важно, насколько хорошо замаскирован ваш VLESS: сам факт коннекта на «чужой» IP уже достаточен для дропа.

Первые два случая решаются на уровне ноды. Третий — принципиально нет. Именно белые списки превращают задачу «как развернуть VPN-сервер» из запуска скрипта в архитектурную. Механику самих белых списков мы разбирали отдельно — здесь фокус на том, как под них строить сервер.

Что значит «устойчивый»: модель угроз до установки

Прежде чем поднимать сервер, зафиксируйте, от чего защищаетесь. Устойчивый VPN-сервер — это не «самый быстрый скрипт установки», а конфигурация с продуманной реакцией на каждый вектор.

Ключевой вывод: точка входа (куда стучится клиент) и точка выхода (откуда трафик идёт в интернет) — это разные роли, и устойчивость каждой обеспечивается по-своему. Сервер вне РФ — прекрасная точка выхода, но плохая точка входа в зоне белых списков. Дальше эти роли не путаем.

Как развернуть VPN-сервер: базовая установка

Базовый слой одинаков для всех и делается за полчаса. Дальше на него навешивается устойчивость.

1. VPS. Провайдер с хорошей связностью до РФ и адекватной ISP-репутацией; локации-фавориты по наблюдениям — Германия, Нидерланды, Финляндия. 1 vCPU / 1–2 GB RAM хватает на несколько сотен пользователей на VLESS; трафик считайте от объёма, а не от числа юзеров.

2. Панель. Не собирайте Xray руками — возьмите панель:

• Remnawave — современная, ноды архитектурно отделены от панели, удобно для нескольких серверов;
• Marzban — зрелая, большое комьюнити;
• 3x-ui — проще всего для старта на одном сервере.

3. Протокол и маскировка. Два рабочих выбора на 2026:

• VLESS + Reality на 443 — маскирует трафик под TLS стороннего реального сайта, устойчив к активному зондированию, ключи короткие. Дефолт для большинства. Пару ключей генерируйте штатно: xray x25519 (в Docker — docker exec <container> xray x25519), в dest/serverNames ставьте реально живой сайт на 443.
• VLESS + XHTTP — нужен, когда вход планируете уводить за CDN. Нюанс: если CDN отдаёт только GET (без POST), в конфиге обязателен явный mode вида packet-up, иначе получаете классику «в одном приложении работает, в другом нет».

4. Домен и сертификат. Свой домен, DNS на нужный IP (для CDN-схемы — проксируемая запись), TLS через Let's Encrypt (certbot) или сертификат провайдера фронта.

5. Гигиена сразу. SSH по ключу (PasswordAuthentication no), файрвол наружу только на 22 и 443, fail2ban, автообновления:

ufw default deny incoming && ufw allow 22 && ufw allow 443 && ufw enable

Это не про блокировки, а про то, чтобы ноду не увели по abuse. На этом «свой VPN-сервер» уже поднят и переживает простой DPI. Дальше — то, что отличает его от одноразового.

Почему одного сервера мало: вход через whitelisted-сеть

Вернёмся к третьему вектору. Когда включаются белые списки, ваш идеально замаскированный VLESS в немецком дата-центре недоступен не потому, что его «раскрыли», а потому, что клиент физически не доходит до его IP — адреса нет в списке разрешённых. Переустановка, смена порта, новый Reality-ключ здесь бесполезны: проблема не на ноде.

Решение — разнести вход и выход так, чтобы клиент стучался на IP, который белым спискам приходится пропускать. То есть поставить перед нодой фронт, живущий в whitelist-сети:

клиент → whitelisted-CDN (белый IP, который ТСПУ не режет, потому что за той же сетью висят легитимные сервисы) → ваша нода-выход за рубежом → интернет.

Отрезать такой вход дорого: блок «белой» сети задевает сопутствующие сервисы, ради которых её и внесли в список. В этом и источник устойчивости — не героическая нода, а вход, который невыгодно блокировать. Подробную сборку связки (нода за CDN, XHTTP-транспорт) мы разбирали в отдельных материалах, здесь важен сам принцип.

Честные оговорки:

• не любой CDN на «белых» IP. Whitelist проверяется по конкретным /24 — соседняя подсеть того же провайдера может уже не пройти. Список нужно верифицировать и держать актуальным: сети из белого списка меняются.
• под CDN обычно ложится XHTTP, а не Reality — трафик проходит через HTTP-слой фронта.
• перепродажа чужого CDN работает, но дороже. Для оператора со стабильным трафиком своя дистрибуция дешевле; экономика упирается не столько в гигабайты, сколько в число запросов.

Если не хотите сами собирать и мониторить whitelist, эту роль закрывает whitelist-CDN как сервис (например, Clearway): готовая «белая» точка входа перед вашей нодой, а нода остаётся где угодно.

Чек-лист устойчивости VPN-сервера

Каждый пункт закрывает конкретный вектор из модели угроз.

• [ ] Панель отделена от ноды. Веб-панель не висит на том же публичном IP, что раздаёт трафик; админка закрыта по IP / VPN / basic-auth.
• [ ] Маскировка на 443. Reality или XHTTP под обычный TLS; нет палевных портов и голых протоколов.
• [ ] Вход ≠ выход. Явно продумано, куда стучится клиент и откуда идёт выход; при белых списках вход — во whitelisted-сети.
• [ ] Резерв входа. Минимум один запасной способ дойти до пользователя (вторая нода, CDN-фронт, резервный домен), переключаемый через подписку — без переустановки клиента у пользователя.
• [ ] Подписки, а не голые ключи. Раздача через subscription-URL: конфиги и точки входа ротируются централизованно.
• [ ] Кэш подписок под контролем. У клиентов (особенно iOS Happ) агрессивный кэш; отдавайте подписку с Cache-Control: no-cache (в nginx — add_header Cache-Control "no-store";), иначе смена входа не доедет.
• [ ] Мониторинг доступности из РФ. Проверки коннекта именно из целевой зоны, а не только «сервер пингуется извне».
• [ ] План отката. Перед любой правкой на проде — бэкап конфига и явный откат в одну команду.
• [ ] Whitelist верифицирован. Если используете «белые» IP — они проверены по /24 и перепроверяются, а не взяты один раз на веру.

Частые ошибки при попытке сделать сервер устойчивым

• Лечить белые списки сменой IP. Бесконечная гонка: адрес выжигается быстрее, чем вы поднимаете новый. Проблема архитектурная, а не адресная.
• Считать Reality панацеей. Reality отлично прячет протокол, но не помогает, если до IP ноды вообще не пускают. Против белых списков нужен «белый» вход, а не лучшая маскировка выхода.
• Класть панель и ноду на один IP. Спалили ноду по abuse — потеряли и управление. Всегда разносите.
• Раздавать статичные ключи вместо подписок. При переезде входа придётся переконфигурировать каждого пользователя вручную.
• XHTTP за CDN без явного mode. Если фронт отдаёт только GET, без packet-up часть клиентов молча не подключается — тот самый «у одного работает, у другого нет».
• Менять прод без бэкапа. Одна правка конфига без плана отката — и сервис лежит, пока вы вспоминаете, что было раньше.
• Брать «CDN», не проверив whitelist. Не всякий CDN стоит на нужных IP; сети из белого списка проверяются посегментно по /24 и меняются со временем.