Полдня ебался с VPN, который перестал подключаться на мобильном интернете. И РКН

Полдня ебался с VPN, который перестал подключаться на мобильном интернете. И РКН тут вообще ни при чём.

Сервер за границей, на нём 3X-UI и VLESS + REALITY + gRPC с маскировкой под обычный HTTPS к nvidia.com. У большинства операторов такое спокойно проходит DPI. И вдруг у одного всё встало: на Wi-Fi конфиг работает, на LTE таймаут.

Сначала надо понять, где рвётся. Слушаю порт на сервере:

tcpdump -ni any 'tcp and port 45443'

За все попытки подключиться с LTE не прилетело ни одного пакета. Ни на рабочий порт, ни даже на порт панели. При этом у человека на другом операторе тот же сервер работал напрямую, а интернет-сканеры стучались свободно.

Дальше логика простая. Голый SYN нечем фильтровать по содержимому, полезной нагрузки в нём ещё нет. Если дропается сам SYN к конкретному адресу, значит фильтр смотрит на адрес. Оператор внёс IP сервера в свой блоклист. При национальной блокировке не работало бы ни у кого — а тут конкретный оператор, сам, от себя, по своему списку. Пидарасы.

Менять порт, протокол и маскировку в такой ситуации бесполезно. Нужна другая точка входа.

Попытка первая: спрятаться за CDN. Домен на Cloudflare, оранжевое облако, режим Flexible, на сервере VLESS + WebSocket без TLS на 80 порту с секретным путём. Клиент видит адрес Cloudflare, целиком его блокировать никто не рискнёт.

На Wi-Fi полетело. На LTE — хуй.

Оператор душит и Cloudflare. Диапазон 104.x вырезан в ноль, порт 8443 закрыт, живёт только 172.64.x, да и тот с троттлингом: пинг 400-500 мс и обрыв через минуту. Перебирать чужие адреса можно до посинения, только я в этой схеме всё равно заложник чужих IP.

Попытка вторая: свой релей. Дешёвый VPS с московским адресом, три правила iptables: DNAT с 443 на заграничный сервер, MASQUERADE, разрешение в FORWARD. Шифрование остаётся сквозным, релей ничего не расшифровывает, он тупо гоняет байты. В клиентской ссылке те же параметры REALITY, поменялся только адрес.

Пятнадцать минут. На LTE заработало. Забанят и этот IP — поменяю VPS ещё за пять, без всякой зависимости от чужих диапазонов.

А дальше началось самое интересное.

Через час хостер написал про аномальную нагрузку на новом VPS. Полез в логи готовиться к худшему, открыл /var/log/apt/history.log, а там unattended-upgrades. Всплеск трафика оказался установкой патчей безопасности.

Раз уж полез, решил закрыть сервер по-нормальному. Нашёл четыре ловушки, и три из них выглядели как рабочая конфигурация.

Правило connlimit в FORWARD с условием на порт 443 не совпало ни с одним пакетом. DNAT срабатывает раньше, в nat/PREROUTING, и к моменту фильтрации у пакета уже адрес и порт заграничного сервера. Правило стоит, iptables -L его послушно показывает, и не делает нихуя.

sshd берёт первое встреченное значение параметра, а не последнее. Мой 99-hardening.conf проиграл штатному 50-cloud-init.conf, где стоит PasswordAuthentication yes. Пятьдесят меньше девяноста девяти. Переименовал в 00-, применилось.

ss не видит проброшенные соединения: локального сокета у них нет, ядро только переписывает адреса. conntrack печатает на запись две пары адресов, поэтому строки dport=45443 там нет и быть не может. Час диагностики, которая выдавала правдоподобную чушь.

sysctl молча пропустил настройку conntrack, потому что отработал раньше загрузки модуля. Запросил 65536, после ребута получил 131072: модуль выставил потолок сам, из hashsize. В этот раз промах ушёл вверх, но нигде не залогировался, а в следующий раз уйдёт вниз.

Общее у всех четырёх: правило в нужной цепочке, конфиг в правильном каталоге, команда возвращает число. Отличить рабочее от нерабочего можно только по счётчикам и по выводу, который показывает эффективное состояние: iptables -L -nv, sshd -T, значение из /proc.

Привычка, которую стоило завести раньше: после каждого изменения проверять не то, что ты написал, а то, с чем работает система. Совпадает это заметно реже, чем хочется.

Сколько ваших правил в проде прямо сейчас стоят с нулём в счётчике?

✍️ Синтаксис хаоса
Подпишись: TG / DZEN / VK