Фильтрация ТСПУ у серверов Таймвеб Cloud: диагностика, обход через reverse-proxy и СDN

Вводные

Два коммерческих сайта на WordPress, оба на одном VPS ^[1]. Клиенты в одном городе, я сам в другом.

Начало июня. Клиенты жалуются, что сайт не открывается без VPN.

Мало ли, подумал я — ограничения, белые списки и т.д.

Потом сайт перестал открываться у меня. По проводу. Дома.

Три дня был потный танец с бубном:

• отключил fail2ban — вдруг сами себя забанили;

• прибил Google Captcha — вдруг из-за гугла;

• перерыл реестр РКН по доменам и по IP — пусто;

• полез в судебные решения — пусто;

• проверил конкурентов на другом хостинге ^[1] — у них всё летает;

Вот последнее особенно бесит. Четыре утра, ты выслушаешь орущих директоров, а у конкурента на копеечном шареде сайт открывается.

Диагноз

Вся картина в итоге сводится к четырём строчкам:

TCP-коннект на 443 — устанавливается
Уходит TLS Client Hello
Server Hello в ответ — не приходит
Через 20 секунд таймаут

При этом:

• SSH на 22 к тому же IP работает и спокойно гоняет крупные пакеты;

• ICMP и TCP-SYN идут без потерь;

• mtr строит полный маршрут, потери ~0%.

Маршрут в порядке. MTU в порядке. Сервер в порядке.

Умирает конкретно TLS на 443.

Так работает DPI: соединение установить дают, потом смотрят, что внутри, и рвут.

Отдельно веселило, что фильтр менял режим на ходу.

Ночью резал по SNI. Тот же IP, но представляемся чужим именем — проходит:

# чужое имя на моём IP — 301, живо
curl --resolve example.com:443:X.X.X.X https://example.com/

# своё имя — виснет
curl https://мой-домен/

К обеду резал уже по IP: повис и example.com ^[2] на этом адресе. К вечеру на пару минут отпустило. Потом опять.

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

Что сказал хостер

5 июня. Ответ поддержки Timeweb на мой тикет (№12068181):

Вероятная причина — изменения в настройках технических средств противодействия угрозам (ТСПУ). Проводим диагностику и держим связь с профильными службами... Решение может потребовать некоторое время и не зависит от нас, поэтому не можем сориентировать по срокам.

И дальше:

Недоступность затрагивает не всех и проявляется по-разному в зависимости от оператора связи, региона и браузера.

Тогда же висела страница со статусом инцидента и шли алерты в их телеграм-канал.

Причём накрыло не только их. В те же дни про то же самое писали Beget и Selectel — про массовый сбой на Хабре уже разбирали ^[3], там же собраны ответы хостеров.

То есть проблема была признана публично. Запомните дату: 5 июня.

Совет «смените IP»

Штатная рекомендация: фильтруется адрес — возьмите другой.

На вопрос «а есть у вас диапазон, который точно не под фильтром» ответили честно:

Адреса серверам назначаются случайным образом из выделенного пула... Гарантировать адрес, который точно не попадает под правила ТСПУ мы не можем. Однако адреса можно добавлять к серверу до получения необходимого. За сутки всего можно получить до 10 IP-адресов.

Десять попыток в сутки. Это не решение, это игра в напёрстки.

Мы попробовали один раз, новый адрес через какое-то время начинал вести себя так же.

Бонусом: при смене IP на сервере Техподдержка Таймвеба адрес поправила, но A-записи доменов — нет. Сайты легли наглухо. В субботу, в самый пик. Пока разбирались, в магазине стояла толпа людей, которые не могут забрать свои заказы, а у меня сново обрывался телефон с озверевшими директорами.

Попытка вторая: CDN Таймвеба

Логика здравая, режут адрес сервера — поставим перед ним CDN. Клиент идёт на адрес CDN (их много, они большие), а CDN тянет контент с сервера по маршруту ДЦ – ДЦ. Этот маршрут не фильтруется, проверено.

Сначала попробовал CDN самого хостера — дешевле же.

Получил залипший отравленный кэш: узел закэшировал 403 и продолжал его отдавать, очистка кэша не помогала. Следом легла сама платформа CDN.

Баг признали, передали разработчикам. Тикет №12082217, прошло 2 месяца – сроков нет до сих пор!

Переехал на CDN Yandex Cloud. Собрал ресурсы, сертификаты через Certificate Manager, переключил DNS. Сайт открылся, скорость отличная. Выдохнул.

Сново звонок от директора: клиенты не могут положить товар в корзину.

CDN Yandex Cloud пропускает только GET, HEAD и OPTIONS. POST включить нельзя — это не галочка, это их ограничение.

Для статики — прекрасно. Для магазина — приговор:

POST /wp-login.php → 405 Method Not Allowed

Вход в админку, корзина, checkout, любой AJAX — всё POST. Получается красивый быстрый сайт в режиме «только посмотреть».

Что в итоге заработало: свой reverse-proxy

Простое решение: отдельная VPS ^[1] в российском облаке, на ней обычный nginx как обратный прокси.

Почему такое работает:

• адрес из огромного пула российского облачного провайдера — такие диапазоны массово не режут, слишком много живого бизнеса ляжет заодно;

• пропускает все методы, включая POST;

• один статический IP — обычные A-записи, никакой возни с CNAME на апексе;

• кэш, заголовки, буферы, логи — свои, а не три переключателя в чужой панели.

Машина нужна минимальная: 2 vCPU, 2 ГБ, диск 15–20 ГБ. Прокси ничего не считает, он перекладывает байты.

Конфиг

Главное — правильно донести имя хоста до бэкенда. Иначе он не поймёт, какой сайт отдавать, и вернёт не тот сертификат.

# заглушка для чужих доменов, которые прилетают на IP просто так
server {
    listen 80 default_server;
    server_name _;
    location / { return 444; }
}
server {
    listen 443 ssl default_server;
    ssl_reject_handshake on;
}

server {
    listen 80;
    server_name example.ru www.example.ru;
    location / { return 301 https://$host$request_uri; }
}

server {
    listen 443 ssl;
    server_name example.ru www.example.ru;

    ssl_certificate     /etc/nginx/ssl/example.fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.key.pem;

    client_max_body_size 256m;

    location / {
        proxy_pass https://ORIGIN_IP;

        # без этого бэкенд отдаст дефолтный сертификат
        proxy_ssl_server_name on;
        proxy_ssl_name        $host;
        proxy_ssl_verify      off;

        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Host  $host;

        proxy_http_version 1.1;
        proxy_set_header Connection "";

        proxy_connect_timeout 60s;
        proxy_send_timeout    300s;
        proxy_read_timeout    300s;
    }
}

Грабли 1: 502 в админке

Через день админка WordPress начала сыпать 502 на admin-ajax.php. У анонимных посетителей — тишина, ошибки видят только залогиненные.

В логе прокси:

upstream sent too big header while reading response header from upstream

У залогиненного админа куки жирные (особенно если на сайте живёт аналитика), ответ бэкенда не влезает в дефолтные буферы. Лечится одним файлом:

# /etc/nginx/conf.d/proxy-buffers.conf
proxy_buffer_size           32k;
proxy_buffers               8 32k;
proxy_busy_buffers_size     64k;
large_client_header_buffers 4 32k;

Грабли 2: ломается выпуск Let's Encrypt

Как только домен смотрит на прокси, панель на бэкенде больше не может выпустить сертификат по HTTP-01. Она кладёт проверочный файл у себя, а Let's Encrypt стучится на прокси:

Invalid response from http://example.ru/.well-known/acme-challenge/...

Пробрасываем проверку насквозь. На прокси:

location /.well-known/acme-challenge/ {
    proxy_pass http://ORIGIN_IP;
    proxy_set_header Host $host;
}

Внимание на редирект http – https: если он стоит выше и хватает всё подряд, проверка снова сорвётся. Location с acme должен отработать раньше.

Дальше сертификат живёт на бэкенде, а TLS клиентам отдаёт прокси — значит, свежий сертификат надо туда доставлять. Скрипт тянет файлы и релоадит nginx только если что-то реально изменилось:

#!/bin/bash
set -e
ORIGIN=root@ORIGIN_IP
SRC=/var/www/httpd-cert/www-root
DST=/etc/nginx/ssl
TMP=$(mktemp -d)
CHANGED=0

declare -A CERTS=( ["example"]="example.ru_le1" )

for name in "${!CERTS[@]}"; do
  src="${CERTS[$name]}"
  scp -q -i /home/ubuntu/.ssh/id_ed25519 "$ORIGIN:$SRC/${src}.crtca" "$TMP/${name}.fullchain.pem"
  scp -q -i /home/ubuntu/.ssh/id_ed25519 "$ORIGIN:$SRC/${src}.key"   "$TMP/${name}.key.pem"
  if ! cmp -s "$TMP/${name}.fullchain.pem" "$DST/${name}.fullchain.pem"; then
    cp "$TMP/${name}.fullchain.pem" "$DST/${name}.fullchain.pem"
    cp "$TMP/${name}.key.pem"       "$DST/${name}.key.pem"
    chmod 644 "$DST/${name}.fullchain.pem"
    chmod 600 "$DST/${name}.key.pem"
    CHANGED=1
  fi
done

rm -rf "$TMP"
[ "$CHANGED" = "1" ] && nginx -t && systemctl reload nginx

Крон:

17 3 * * * /usr/local/bin/sync-certs.sh >> /var/log/sync-certs.log 2>&1

Как тестировать, не роняя прод

Самое полезное за всю историю. --resolve притворяется, что домен указывает куда надо, — DNS при этом не трогаем вообще:

# отдаётся ли сайт через прокси
curl -sI --resolve example.ru:443:PROXY_IP https://example.ru/ | head -5

# и главное — проходит ли POST
curl -s --resolve example.ru:443:PROXY_IP -X POST https://example.ru/wp-login.php 
  -o /dev/null -w "POST: %{http_code}n"

200 вместо 405 — магазин будет живой. Вот теперь можно переключать DNS.

Что ещё советуют (я не проверял)

Пока копал, нашёл в сообществе ещё несколько направлений. Сам не тестировал, но выглядят рабочими, оставлю ссылками:

• Отключить TLS 1.3 / включить HTTP/2. Есть версия, что триггер срабатывает на отпечаток TLS 1.3 и на количество TLS-соединений в единицу времени. Подробно — в разборе реального кейса ^[3] и в статье про схему ограничений июня ^[4].

• Белые списки. У некоторых хостеров юрлицо или ИП может подать обоснование, чтобы подсеть исключили из фильтрации. Selectel это описывает у себя в документации.

• Чужие проверялки. dpi-checkers ^[5] — если хочется понять, что именно у вас срабатывает.

Если у кого-то взлетело — напишите в комментариях, допишу в статью.

Теперь про «Таймвеб»

5 июня Таймвеб публично признал фильтрацию, повесил статус, писал про связь с профильными службами.

Конец июля. Прихожу с той же проблемой тикет №12374081. Плашки нет. Статуса нет. У них все хорошо.

Первая линия просит прислать mtr, несмотря на то, что я пишу им, что это не сработает.

Тут надо остановиться, потому что момент принципиальный.

mtr в принципе не может показать эту проблему. Он работает по ICMP и видит маршрут и потери. А DPI пакеты на маршруте не роняет — он даёт установить TCP и рвёт TLS. Для mtr трасса выглядит идеально чистой.

Круг замыкается:

1. Клиент приносит проблему.

2. У него просят диагностику, которая эту проблему не ловит по своей природе.

3. Диагностика ожидаемо чистая.

4. «С нашей стороны всё работает».

Вероятно, злой умысел – регламента на «клиент попал под фильтрацию» нет. Есть скрипт «просить трассировку» и предлагать выдать другой адрес.

Выглядит так, будто проблему решили молчанием.