DNS, IP и HTTPS: какие технологии используются при блокировке сайтов

Блокировка сайта в России — это почти всегда комбинация нескольких технических мер, а не единичное действие. Оператор связи или система фильтрации может ограничивать доступ по доменному имени, IP-адресу, признакам HTTPS-соединения или через глубокую инспекцию трафика. Понимание этих механизмов критически важно не только для владельцев сайтов, но и для специалистов, отвечающих за инфраструктуру, безопасность и правовую устойчивость проекта. Без этого сложно отличить реальную блокировку от технического сбоя, правильно выстроить защиту и подготовить юридически значимое обоснование для обжалования.

Что именно блокируют: домен, IP или соединение

Чтобы разобраться в логике блокировки, удобно разделить интернет-адрес сайта на три уровня. Каждый из них может быть целью фильтрации, и последствия для пользователя будут разными.

• Домен — понятное человеку имя сайта, например example.ru. Это самый очевидный идентификатор, который фигурирует в реестре запрещённых сайтов Роскомнадзора.
• IP-адрес — технический адрес сервера в сети. Один IP может обслуживать множество доменов, особенно на shared-хостинге или за CDN.
• HTTPS-соединение — зашифрованный канал между браузером и сайтом. Несмотря на шифрование, такое соединение оставляет достаточно метаданных для фильтрации.

На практике один и тот же ресурс может быть заблокирован на любом из этих уровней, и результат будет отличаться. Иногда не открывается только конкретный домен, а иногда становится недоступен весь сервер вместе с десятками соседних проектов. Это важно учитывать при выборе хостинга: размещение на выделенном IP снижает риск пострадать от чужой блокировки, но не исключает её полностью.

Как работает DNS-блокировка

DNS — это система, которая превращает доменное имя в IP-адрес. Когда пользователь вводит адрес сайта в браузере, сначала происходит DNS-запрос: где находится этот сайт? Если ответ подменяется или не возвращается, браузер не понимает, куда подключаться. Технически оператор получает выгрузку из реестра запрещённых сайтов и настраивает свои DNS-серверы так, чтобы для указанных доменов возвращался либо адрес заглушки, либо пустой ответ.

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

Как это выглядит на практике

• Домен не открывается, но сайт по прямой ссылке или через другой резолвер работает.
• Вместо сайта отображается страница-заглушка оператора с информацией о блокировке.
• В публичных инструментах проверки видно, что IP у домена будто бы «не находится» или возвращается некорректный адрес.

Когда DNS-блокировки недостаточно

Этот метод хорошо работает против обычного пользовательского трафика, но практически бесполезен, если пользователь применяет:

• альтернативный DNS-сервер (например, публичные сервисы вроде Google DNS или Cloudflare);
• защищённый DNS поверх HTTPS (DoH) или TLS (DoT) — такие запросы оператор не видит и не может подменить;
• заранее закешированный адрес — если IP уже известен системе, DNS-запрос не требуется;
• прямое подключение к IP — браузер может обратиться к серверу, минуя доменное имя.

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

Блокировка по IP: грубый, но эффективный способ

IP-блокировка запрещает доступ к конкретному сетевому адресу. Для системы фильтрации это просто: есть адрес в реестре — трафик к нему отсекается на уровне маршрутизации или межсетевого экрана. Но у такого подхода есть серьёзный минус: на одном IP могут размещаться сразу десятки и сотни сайтов, особенно на shared-хостинге или за CDN-сетями вроде Cloudflare. Это значит, что при блокировке одного ресурса могут пострадать и чужие проекты, никак не связанные с нарушением.

С правовой точки зрения это создаёт коллизию: блокировка доступа к законным ресурсам формально является ограничением прав их владельцев. На практике такие ситуации возникают регулярно, и владельцам пострадавших сайтов приходится доказывать, что их IP попал под ограничения ошибочно или избыточно. Именно поэтому при выборе хостинга стоит учитывать, кто ещё находится на том же IP-адресе, и по возможности использовать выделенный адрес.

Что важно знать о блокировке по IP

• Она действует не на домен, а на сервер — фильтруется весь трафик к этому адресу.
• Если на IP сидят несколько сайтов, они могут исчезнуть все одновременно.
• При переезде сайта на другой хостинг блокировка может потерять эффект, если новый IP не добавлен в реестр.
• Если ресурс использует CDN, адреса могут динамически меняться, и контроль становится сложнее — система фильтрации может не успевать за обновлениями.

Признаки IP-блокировки

• Домен резолвится (DNS возвращает корректный IP), но сайт не открывается.
• Не работает ни через браузер, ни через прямое подключение к IP.
• Проблема повторяется с разных устройств и браузеров в одной сети.
• Другие сайты на том же сервере тоже недоступны — это ключевой индикатор.

HTTPS не скрывает всё: что видно даже при шифровании

У HTTPS есть важное свойство: содержимое страницы шифруется. Но это не означает, что для сети соединение становится полностью «невидимым». Провайдер или фильтрующая система может видеть часть метаданных: IP-адрес, порт, особенности TLS-рукопожатия, а в ряде случаев — доменное имя из служебных полей соединения. Именно поэтому блокировка по HTTPS часто строится не на чтении контента страницы, а на анализе признаков самого соединения.

На практике это означает, что даже полностью зашифрованный сайт может быть идентифицирован и заблокирован без расшифровки трафика. Система анализирует косвенные признаки: куда идёт пакет, с какими параметрами устанавливается защищённый канал, какие сертификаты предъявляются.

Что может использоваться при фильтрации HTTPS

• IP-адрес назначения — базовый идентификатор сервера.
• Доменное имя в служебных полях TLS (SNI) — ключевой маркер, о котором ниже.
• Характеристики рукопожатия — набор шифров, версия протокола, параметры сессии.
• Поведенческие признаки потока — частота пакетов, размеры, тайминги.
• Сигнатуры протокола — шаблоны, характерные для определённых приложений или сервисов.

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

SNI: ключевой маркер в TLS-соединении

SNI (Server Name Indication) — это поле, в котором браузер сообщает серверу, к какому домену он хочет подключиться. Это нужно для корректной выдачи сертификата и обслуживания множества сайтов на одном IP. Проблема в том, что это имя долгое время передавалось в открытом виде в начале соединения — до установки шифрованного канала.

Для систем фильтрации SNI стало удобной точкой контроля: если домен виден в SNI, его можно сравнить со списком запрещённых и разорвать соединение ещё до того, как начнётся передача данных. Это гораздо точнее, чем блокировка по IP, и не требует расшифровки трафика.

Почему SNI-фильтрация так распространена

• Она точнее, чем простая блокировка IP — позволяет блокировать конкретный домен, а не весь сервер.
• Работает на этапе установления соединения, не пропуская трафик дальше.
• Не требует расшифровки всего трафика, что снижает нагрузку на оборудование.
• Легко интегрируется в существующие DPI-системы.

Но у SNI-фильтрации есть ограничения

• Современные протоколы постепенно сокращают видимость SNI — например, ESNI и ECH шифруют это поле, делая его недоступным для анализа.
• Некоторые соединения создают ложные срабатывания, особенно если один IP обслуживает сотни доменов через CDN.
• При сложной инфраструктуре можно случайно задеть легитимные сервисы, что приводит к репутационным и юридическим рискам для оператора.

DPI: когда система смотрит глубже

DPI, или глубокая инспекция пакетов, — это анализ сетевого трафика по множеству признаков. Система может не читать содержимое страницы целиком, но распознавать протокол, тип соединения, заголовки, частоту пакетов и их поведение. На практике DPI используют, когда одной DNS- или IP-блокировки уже недостаточно — например, если ресурс активно меняет IP-адреса или маскируется под другой трафик.

DPI-системы, развёрнутые на сетях операторов, работают в пассивном режиме: они анализируют проходящий трафик и при обнаружении признаков запрещённого ресурса инициируют сброс соединения. Это требует значительных вычислительных мощностей и тонкой настройки, чтобы минимизировать ложные срабатывания.

Что умеет DPI

• Определять протокол — HTTP, HTTPS, QUIC, DNS и другие.
• Распознавать TLS-паттерны — версии, шифры, особенности рукопожатия.
• Сравнивать SNI со списками запрещённых доменов.
• Анализировать нестандартные соединения — например, туннелирование трафика.
• Сбрасывать подозрительный поток — отправлять RST-пакеты для разрыва соединения.

Типовые проблемы DPI

• Ложные срабатывания на обычный трафик — когда легитимный сервис по косвенным признакам принимается за запрещённый.
• Сложности с мобильными сетями и CDN — динамические IP и общая инфраструктура усложняют точную идентификацию.
• Ошибки при массовой блокировке похожих сервисов — когда под ограничения попадают целые подсети.
• Нестабильность, когда политика фильтрации меняется без заметных признаков для пользователя — сайт то открывается, то нет.

Как понять, каким способом заблокирован сайт

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

Пошаговая проверка

1. Проверить, открывается ли сайт с разных сетей — домашний интернет, мобильный интернет другого оператора, корпоративная сеть.
2. Сравнить поведение в обычном DNS (предоставляемом провайдером) и в альтернативном резолвере — например, публичном DNS Google или Cloudflare.
3. Проверить, доступен ли сайт по прямому IP — ввести IP-адрес в браузере и посмотреть, открывается ли страница.
4. Посмотреть, не совпадает ли блокировка с проблемой TLS/SNI — обратить внимание, на каком этапе происходит сбой: до установки соединения или во время рукопожатия.
5. Сверить домен и IP с официальными реестрами Роскомнадзора и внутренними логами сервера.
6. Проверить, не сидят ли на этом IP сторонние ресурсы — это можно сделать через сервисы reverse IP lookup.

На что смотреть в первую очередь

• Если не работает только домен — вероятна DNS-блокировка.
• Если не работает весь сервер — вероятна IP-блокировка.
• Если домен и IP «живы», но соединение сбрасывается на HTTPS-этапе — возможна SNI/DPI-фильтрация.

Типичные ошибки при анализе блокировки

1. Проверять только из одной сети

Один и тот же сайт может вести себя по-разному у разных операторов. У одного провайдера блокировка уже применена, у другого — ещё нет, или используются разные методы фильтрации. Всегда проверяйте минимум с двух-трёх независимых сетей.

2. Путать блокировку с технической аварией

Проблема может быть не в фильтрации, а в DNS-сбое, истечении сертификата, неполадках CDN или хостинга. Прежде чем делать выводы, исключите технические причины на стороне сервера.

3. Делать выводы только по ping

Отклик ICMP ничего не говорит о том, работает ли сайт по HTTP или HTTPS. Сервер может отвечать на пинги, но при этом блокироваться на уровне приложений. ping — лишь индикатор доступности IP, не более.

4. Игнорировать инфраструктуру CDN

Если ресурс использует общую платформу вроде Cloudflare, блокировка одного адреса может затронуть множество чужих сайтов. Проверьте, не находится ли ваш IP в пуле CDN, который мог попасть под ограничения из-за другого проекта.

5. Сразу менять все подряд

Когда одновременно меняют DNS, IP и настройки TLS, становится невозможно понять, что именно сломалось и какая мера помогла. Вносите изменения по одному и фиксируйте результат на каждом шаге.

Практический чек-лист для владельца сайта

• Проверить, есть ли домен и IP в реестрах ограничений Роскомнадзора.
• Сравнить доступность сайта через разные DNS-резолверы — провайдерский и публичный.
• Протестировать прямое подключение к IP — ввести IP в браузере и оценить результат.
• Посмотреть, не блокируется ли только один поддомен — иногда фильтрация затрагивает лишь часть доменной зоны.
• Проверить сертификаты и TLS-настройки — срок действия, цепочку доверия, поддерживаемые версии протокола.
• Убедиться, что на общем IP нет конфликтующих соседних проектов — через reverse IP lookup.
• Зафиксировать все симптомы до внесения изменений — скриншоты, логи, traceroute, результаты DNS-запросов.
• Сохранить логи запросов, ошибки TLS и данные от провайдера — это пригодится для обжалования или технического разбора.

Почему это важно для специалистов по кибербезопасности и IT-праву

Понимание DNS, IP и HTTPS в контексте блокировок полезно не только для администраторов. Это базовая связка для специалистов по расследованию инцидентов, сетевой безопасности и интернет-праву. Без неё сложно:

• правильно интерпретировать причины недоступности ресурса — блокировка это или технический сбой;
• отличить блокировку от сбоя — на основе объективных признаков, а не догадок;
• подготовить техническое обоснование для жалобы или обращения в суд — с описанием метода фильтрации и его последствий;
• оценить риски при размещении сайта на shared-инфраструктуре — и предложить клиенту оптимальную архитектуру;
• объяснить клиенту, почему «сайт сломался» не всегда означает проблему у разработчиков — и что нужно проверять в первую очередь.

В образовательных программах по кибербезопасности и IT-праву эта тема часто разбирается фрагментарно, но на практике она оказывается одной из самых востребованных. Специалист, который может провести грамотный анализ блокировки и подготовить юридически значимое заключение, ценится и в коммерческом секторе, и в правозащитной сфере.

Вывод

Блокировка сайта почти всегда строится на комбинации технологий. DNS ограничивает видимость домена, IP-блокировка отрезает сервер целиком, а HTTPS не гарантирует полной невидимости, потому что фильтрующим системам доступны служебные признаки соединения, включая SNI и другие параметры TLS. Чем лучше понимать эти уровни, тем проще быстро определить причину недоступности сайта и выбрать правильный путь реакции — будь то техническая корректировка инфраструктуры или юридическое обжалование.

FAQ

Что чаще всего блокируют в России: домен или IP?

Чаще всего встречаются оба варианта, но доменная блокировка удобнее для точечного ограничения — она позволяет заблокировать конкретный ресурс, не затрагивая соседние. IP-блокировка применяется для более грубого отсечения сервера, особенно если домен продолжает резолвиться через альтернативные DNS.

Может ли HTTPS скрыть сайт от блокировки?

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

Почему при смене DNS сайт иногда снова открывается?

Потому что блокировка может быть только на уровне DNS. Если использовать другой резолвер, не подверженный фильтрации, можно получить настоящий адрес сайта и обойти ограничение. Однако этот метод не работает, если дополнительно применяется IP-блокировка или DPI.

Почему блокировка по IP опасна для соседних сайтов?

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

Как понять, что сработала SNI-блокировка?

Обычно сайт доступен по IP или с альтернативными настройками, но HTTPS-соединение сбрасывается именно на этапе установления защищённого канала. Браузер может сообщать об ошибке TLS, а прямое HTTP-соединение (если оно разрешено) может работать.