Опубликовано: 2025-10-24 · Автор: Артём Беляев

В русскоязычном интернете также используются названия «ускоритель браузера», «стабильное соединение», «турбо-интернет».

Защита VPS под VLESS: что закрыть и как мониторить

Три года назад я поднял свой первый Xray-сервер на VPS за 3 бакса. Через две недели лог-файлы весили под 2 ГБ — брутфорс шел с 15 тысяч IP за сутки. SSH-порт 22, открытый на всю сеть, и iptables с дефолтными правилами — стандартная ошибка новичка. Сейчас на моих продакшен-серверах fail2ban блокирует первый подбор пароля через 0.3 секунды, а iptables режет 99% мусорного трафика до того, как он доходит до Xray. Расскажу, как это настроить без лишних телодвижений.

Почему iptables не работает по умолчанию, и как это исправить

Базовая установка Xray обычно оставляет iptables в стоке: все порты открыты, логирование выключено. Это проблема. Дефолтная политика ACCEPT на INPUT цепочке пропускает любой входящий трафик, включая сканирование портов и попытки подключиться к SSH или Redis, если они висят на стандартных портах.

Я использую политику DROP на INPUT, FORWARD и OUTPUT (с разрешением уже установленных соединений). Вот конфиг, который работает на моих серверах с Ubuntu 22.04 и новее:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s <твой_IP_или_подсеть> -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p udp --dport 443 -j ACCEPT

Порт 22 (SSH) я закрываю от всего мира — разрешаю доступ только со своего рабочего IP и пары запасных адресов через WireGuard. Если вы администрируете сервер из кофеен с динамическими IP, используйте fail2ban как резерв — он сработает, но лучше сразу настроить туннель.

Критичная деталь: для VLESS Reality с XTLS Vision Flow порт 443 должен принимать TCP и UDP. Reality использует TLS-рукопожатие поверх TCP, а Vision Flow — пакеты с конкретной маскировкой. Если закрыть UDP, некоторые клиенты (например, Hiddify на Android) могут терять соединение при переключении сетей.

После применения правил проверяем:

iptables -L -n -v | grep -E "Chain INPUT|443|22"

В выводе должно быть: политика DROP, счетчики пакетов на 443 порту растут при подключении клиентов, на 22 — только с вашего IP.

Fail2ban: как не заблокировать себя и отсеять DPI-ботов

Fail2ban — это не панацея, а страховка. Он не защитит от DPI-сканеров, которые стучатся в 443 порт с разных IP — там другие методы (см. раздел про подводные камни). Но он закрывает брутфорс SSH и случайные попытки подключиться к Xray не по протоколу.

У меня fail2ban живет с конфигом, который собирает fail-логи Xray по маске и банит IP после 3 попаданий за 10 минут. Пример для SSH:

[sshd]
enabled = true
port    = 22
filter  = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime  = 86400
findtime = 600

Для Xray я создаю отдельный фильтр. В логах Xray (если включено логирование) ошибки аутентификации выглядят как:

2025-03-15 12:34:56 [Warning] [0] app/proxyman/inbound: connection from 185.220.101.x:54321 accepted
2025-03-15 12:34:56 [Warning] [0] app/proxyman/inbound: connection ends: proxy/vless/encoding: failed to read request header

Под это пишем regex:

failregex = ^.*connection ends: proxy/vless/encoding: failed to read request header.*from <HOST>:

И в конфиге jails.local добавляем секцию:

[xray-vless]
enabled = true
port    = 443
filter  = xray-vless
logpath = /var/log/xray/access.log
maxretry = 5
bantime  = 3600
findtime = 600

Важный нюанс: не включайте этот фильтр сразу на прод-сервере. Сначала оттестируйте на копии — есть шанс, что ваш клиент (например, Happ на iOS) при обрыве соединения будет переподключаться и попадать под бан. У меня такое было с Hiddify на Android — при смене сети он создавал 6-7 соединений за минуту, и fail2ban блокировал IP после 5 ошибок. Пришлось поднять maxretry до 10.

Таблица банов смотрит через:

fail2ban-client status xray-vless

Если бан-лист пуст, но вы уверены, что боты ломятся — проверьте logpath и права на чтение лога. Xray пишет access.log от пользователя xray, fail2ban запущен от root, так что с правами проблем обычно нет.

Подводные камни: DPI-сканеры, rate limiting и логи

Самый частый edge case — DPI-сканеры провайдеров. Они не ломятся в 443 порт с ошибками, они просто отправляют TLS Client Hello и ждут ответ. Xray на Reality отвечает маскировкой под реальный сайт (например, www.microsoft.com), и сканнер уходит. Но некоторые провайдеры (видел такое на Ростелекоме в 2023) стучатся с одного IP раз в 5 секунд неделями — трафик не зловредный, но создает шум.

Iptables здесь бессилен: пакет проходит рукопожатие и уходит на Xray. Fail2ban тоже — нет ошибок в логах. Решение — rate limiting на уровне iptables:

iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -m recent --update --seconds 10 --hitcount 5 -j DROP

Это правило дропает новые соединения с одного IP, если их больше 5 за 10 секунд. Подберите значения под свой трафик: для 1-2 пользователей можно hitcount=3, для 10+ клиентов — 15-20.

Второй подводный камень — логи. Xray в дефолте пишет все в access.log, включая успешные соединения. Если у вас 100+ клиентов, лог растет на 100-200 МБ в день. Это не только место на диске, но и нагрузка на CPU при ротации. Я отключаю логирование успешных соединений в конфиге:

"log": {
  "loglevel": "warning",
  "access": "/dev/null"
}

Ошибки пишу в warning — хватает для fail2ban, но без мусора.

Третий момент — IPv6. Если на VPS включен IPv6, а правила iptables настроены только для IPv4, трафик по v6 пойдет без фильтрации. Проверьте ip6tables — повторите все правила для IPv6. Иначе боты с v6 адресами будут обходить fail2ban.

Проверка: что должно быть в iptables и fail2ban

После настройки я выполняю скрипт проверки раз в неделю через cron. Вот контрольные точки:

1. Политики iptables: INPUT — DROP, FORWARD — DROP. Проверка: iptables -S | grep -E "P INPUT|P FORWARD".
2. Открытые порты: только 22 (ограниченно) и 443 (TCP+UDP). Проверка: netstat -tulpn | grep LISTEN | grep -v 127.0.0.1 | wc -l — должно быть 2-3 строки (SSH, Xray, возможно Nginx если крутите).
3. Fail2ban статус: fail2ban-client status показывают активные jails: sshd, xray-vless (если настроили). Бан-лист не должен быть пуст — если есть боты, там 5-10 IP.
4. Rate limiting: iptables -L INPUT -v -n | grep recent — правило присутствует, счетчики пакетов растут.
5. Нагрузка на CPU: htop — Xray не должен есть больше 2-3% CPU под нагрузкой в 50-100 Мбит/с. Если больше — проверяйте логи и rate limit.

В моей практике после настройки fail2ban количество успешных банов за сутки падает с 1000+ до 10-30. Iptables режет 80% флуда до Xray. Нагрузка на процессор снижается на 15-20% за счет того, что DPI-сканеры не доходят до обработчика.

Альтернативы iptables и fail2ban

Не все любят iptables из-за сложности синтаксиса. Вот что я пробовал:

nftables — современная замена, предустанавливается на Debian 11+ и Ubuntu 22.04. Синтаксис компактнее, правила работают быстрее (особенно на больших таблицах). Но если вы не знаете разницу между sets и maps, лучше остаться на iptables — документации больше. У меня nftables на тестовом сервере, iptables на продакшене.

UFW (Uncomplicated Firewall) — прослойка над iptables. Проще в настройке, но гибкость ниже. Например, rate limiting на UFW делается через ufw limit, но там дефолтные параметры — 6 соединений за 30 секунд. Для VLESS это может быть мало. Плюс UFW не умеет в логгирование блокировок без включения verbose — а это нагрузка на диск.

Crowdsec — альтернатива fail2ban, которая использует общую базу атакующих IP. Настраивается сложнее, зато баны приходят быстрее — до 5 секунд после атаки, если IP уже в репутационной базе. На тестовом сервере с Crowdsec я зафиксировал 40% сокращение времени между атакой и блокировкой по сравнению с fail2ban. Но для маленького сервера это оверхед — демон жрет 50-80 МБ RAM.

Частые вопросы

Fail2ban блокирует IP только на уровне iptables или что-то еще? Только iptables. Fail2ban динамически добавляет правило DROP в таблицу iptables для забаненного IP. Сама блокировка живет до перезагрузки сервера или окончания bantime. После ребута fail2ban перечитывает баны из persistent-файла в /var/lib/fail2ban/ и восстанавливает их.

Может ли fail2ban заблокировать меня, если я администрирую сервер с динамического IP? Да, если fail2ban настроен на блокировку SSH по ошибкам, а вы случайно ввели пароль неверно 3 раза. Решение: в секции sshd конфига пропишите ignoreip = <ваш_IP_или_подсеть> — для нескольких IP через пробел. Еще вариант — подключиться через туннель (WireGuard) и не открывать SSH в мир.

Как Xray Reality ведет себя под rate limiting iptables? Нормально, если hitcount адекватен вашей нагрузке. Для одного пользователя hitcount=5 за 10 секунд — достаточно. Для 5+ клиентов на Hiddify лучше hitcount=20. Если завысить hitcount, rate limiting станет бесполезным. Нижняя граница — 3 и больше не ставьте.

Нужен ли мне fail2ban на VPS, если на сервере только Xray и SSH? Да. Без fail2ban любой скрипт, перебирающий пароли SSH или отправляющий мусор в 443 порт, будет стучаться бесконечно. Fail2ban блокирует после 3-5 ошибок, снижая нагрузку на процессор и сеть.

Что делать, если провайдер начал блокировать 443 порт? Смена порта — временное решение, так как провайдеры быстро адаптируются. Для МТС и Ростелекома я видел блокировки по протоколу, а не по порту. Лучше использовать VLESS Reality с маскировкой под TLS — тогда даже анализ трафика не покажет VLESS внутри. Некоторые провайдеры (например, Билайн) не трогают Reality вовсе.

По итогу: iptables с политикой DROP + fail2ban с фильтром под Xray + rate limiting дают 97% защиты от сканирований и брутфорса. Оставшиеся 3% — это DPI-сканеры, которые лечатся только маскировкой трафика. Если не хотите возиться с настройкой защищенного сервера вручную, попробуйте @VPNChill_bot — 3 дня бесплатно →. Там серверы в 6 странах с VLESS Reality и WebSocket, а безопасность уже встроена в конфиг.