В последние дни часть пользователей сообщает о проблемах с доступом к серверам FirstVDS по протоколам HTTPS, SSH и RDP. Возможны также сбои с ICMP (пинг).
Причина. Предположительно — новые правила фильтрации трафика со стороны государственных регуляторов. Проблемы с внутренней связностью и оборудованием нет — наши серверы работают штатно. Проверить состояние узлов можно в статус-панели.
К сожалению, повлиять на настройки операторов связи и фильтрацию напрямую мы не можем.
Как восстановить доступ
Для начала вы можете обратиться к вашему оператору связи — нужно будет передать оператору данные для диагностики. Если потребуется, он сам свяжется с нами, и мы поможем.
Для диагностики будет нужна следующая информация:
- подробное описание проблемы и точное время её возникновения,
- тип протокола,
- проблема появляется всё время или периодически,
- примеры: откуда и куда идёт трафик (
source-destination), - что показывают команды
nslookup/ping/traceroute.
Всем клиентам — временные решения:
- Используйте веб-консоль (VNC) в личном кабинете FirstVDS. Она работает через браузер и не зависит от SSH и RDP.
- Попробуйте сменить оператора связи — например, переключиться с домашнего интернета на мобильный.
- Временно используйте браузер Mozilla Firefox: его TLS-отпечаток отличается от браузеров на Chromium.
Смена IP-адреса на сервере иногда помогает, но не гарантирует результат: сегодня работает, завтра перестанет, необходимо устранить первопричину, используя наши рекомендации ниже.
Практические рекомендации для владельцев веб-сервисов
Использовать HTTP/2 как основной режим работы сайта.
HTTP/2 позволяет обслуживать много запросов внутри одного TCP/TLS-соединения. Это снижает количество параллельных TLS-сессий от одного клиента и уменьшает вероятность ложного срабатывания фильтрации.
Ограничить TLS до версии 1.2.
На публичном frontend-прокси рекомендуется отключить TLS 1.3 и оставить TLS 1.2 как основной рабочий вариант. Это делает HTTPS-трафик более предсказуемым для сетевой фильтрации.
Не использовать HTTP/1.1 как основной публичный режим.
HTTP/1.1 может открывать много параллельных соединений для загрузки картинок, CSS, JavaScript, шрифтов и других ресурсов. Такой профиль трафика может выглядеть подозрительно для автоматических систем фильтрации.
Не включать QUIC / HTTP/3.
Для стабильной работы лучше использовать классическую схему: TCP/443 → TLS 1.2 → HTTP/2
UDP/443 лучше закрыть или не публиковать.
Поставить перед сайтом reverse proxy.
Если backend менять неудобно, внешний трафик лучше принимать на отдельном frontend-прокси: Клиент → reverse proxy → backend
На reverse proxy включить HTTP/2 и TLS 1.2, а backend оставить за ним.
Не делать обязательный redirect HTTP → HTTPS на backend, если сайт работает через proxy.
Иначе можно получить петли редиректов, некорректную схему запроса или 502-ошибки.
Направить DNS-записи домена на frontend-прокси.
Реальный IP backend-сервера по возможности не должен быть публичной точкой входа для пользователей.
Проверять доступность сайта из разных сетей РФ.
Проблема может проявляться не у всех операторов одновременно. У одного провайдера сайт может открываться, у другого — уходить в timeout.
Не считать миграцию на другой хостинг полноценным решением.
Переезд может временно помочь, но не устраняет саму причину — после переезда, через некоторое время, ресурс также может затронуть фильтрация.
Что отключить
TLS 1.3
HTTP/3 / QUIC / UDP 443
HTTP/1.1 как основной публичный режим
Главная рекомендация
Сделать внешний HTTPS-трафик максимально предсказуемым: TLS 1.2 + HTTP/2 поверх TCP/443
Без TLS 1.3, без QUIC и без HTTP/3.
Мы продолжаем следить за ситуацией и собирать обратную связь от клиентов. При поступлении новой информации обновим новость.
