Как обойти блокировки через DNS: Smart DNS, DoH и почему VPN не всегда нужен.

Нужный сайт заблокирован. Коллега говорит «поставь VPN». Вы ставите, настраиваете, скорость падает вдвое — и выясняется, что достаточно было сменить один DNS-сервер. Две минуты вместо двадцати.

Или наоборот: сменили DNS, всё равно не открывается. Ставите VPN — тоже не работает. Потому что там DPI, и обычный VPN давно под блокировкой.

Разница между этими случаями — в понимании того, как именно работает блокировка. Без этого выбираете инструмент вслепую.

КАК СТРАНЫ БЛОКИРУЮТ САЙТЫ

Блокировка — это не одна технология. Это несколько уровней, и каждый следующий сложнее обойти.

Уровень первый: DNS-блокировка. Самый простой и самый распространённый. Провайдер настраивает свои DNS-серверы так, чтобы они возвращали неправильный ответ для заблокированных доменов — либо IP страницы-заглушки с текстом «сайт заблокирован», либо вообще NXDOMAIN. Технически сайт работает, IP доступен — просто DNS врёт.

Именно так работает большинство блокировок в Литве, странах ЕС и многих других. Решается элементарно: сменить DNS на 1.1.1.1 или 8.8.8.8 — и блокировки нет.

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

Уровень третий: DPI — Deep Packet Inspection. Провайдер анализирует содержимое пакетов в реальном времени. Видит не просто IP назначения, а конкретный домен в SNI поле TLS-рукопожатия, HTTP Host заголовке, или даже паттерны трафика. Именно так работает российский ТСПУ (технические средства противодействия угрозам) и китайский Great Firewall. Против DPI не помогает ни смена DNS, ни обычный VPN с легко идентифицируемым протоколом. Нужна обфускация трафика.

Уровень четвёртый: блокировка по URL или содержимому. Редкость, обычно в связке с DPI. Блокируется не весь сайт, а конкретные страницы.

Отдельная история — DNS hijacking провайдера без всяких блокировок. Многие ISP перехватывают NXDOMAIN-ответы (домен не существует) и вместо ошибки возвращают свою страницу с рекламой. Вы опечатались в домене — вместо стандартной ошибки браузера видите поисковик провайдера. Это происходит без вашего ведома и без всякого реестра. Решается той же сменой DNS на 1.1.1.1 или DoH.

Понимание уровня блокировки — это первый шаг. Без него выбираете инструмент вслепую.

КАК ОПРЕДЕЛИТЬ УРОВЕНЬ БЛОКИРОВКИ

Большинство сразу лезет что-то настраивать. Правильнее — сначала потратить две минуты на диагностику. Инструмент зависит от типа блокировки, и ошибиться здесь — значит потратить час на настройку того что не поможет.

Шаг первый — проверьте DNS. Спросите у провайдерского резолвера и у публичного, сравните ответы:

# Спросите у DNS провайдера
dig @провайдерский_DNS заблокированный_сайт.com

# Спросите у публичного DNS
dig @1.1.1.1 заблокированный_сайт.com
dig @8.8.8.8 заблокированный_сайт.com

Ответы разные — провайдер подменяет DNS. Смена резолвера решает проблему полностью, никакого VPN не нужно.

Ответы одинаковые — DNS тут ни при чём. Проверьте доступность IP напрямую:

curl -v --connect-timeout 5 https://заблокированный_сайт.com
traceroute заблокированный_сайт.com

Traceroute обрывается на узлах провайдера — IP-блокировка, нужен прокси или VPN. Соединение устанавливается но сразу сбрасывается — DPI, нужна обфускация.

Заодно проверьте DNS hijacking — не подменяет ли провайдер несуществующие домены рекламой:

# Запросите заведомо несуществующий домен
dig @провайдерский_DNS этого-домена-точно-нет-12345.com
dig @1.1.1.1 этого-домена-точно-нет-12345.com

Провайдерский резолвер должен вернуть NXDOMAIN — статус «домен не существует». Если вместо этого возвращает какой-то IP — провайдер перехватывает NXDOMAIN и перенаправляет на свою страницу.

SMART DNS — ЧТО ЭТО И КАК РАБОТАЕТ

Smart DNS — это не VPN и не шифрование. Это DNS-сервис, который для определённых доменов возвращает IP своего прокси-сервера вместо реального. Браузер идёт на прокси, прокси делает запрос от своего IP — который находится в другой стране — и возвращает ответ вам.

Зачем нужен IP другой страны? Многие блокировки работают по географии: сайт доступен из Германии, но недоступен из России или Беларуси. Прокси Smart DNS находится в стране где сайт открыт — и делает запрос оттуда. Целевой сайт видит IP прокси, а не ваш. Провайдер видит соединение с прокси, а не с заблокированным сайтом.

Ключевое отличие от VPN: через прокси идут только запросы к заблокированным сайтам. Весь остальной трафик — напрямую, без туннеля, без потери скорости.

Схема работы:

1. Вы прописываете DNS Smart DNS провайдера вместо обычного
2. Запрашиваете заблокированный сайт
3. DNS возвращает IP прокси Smart DNS провайдера
4. Браузер подключается к прокси
5. Прокси делает запрос от имени IP в нужной стране
6. Вы получаете контент

Плюсы: быстро, без настройки VPN-клиента, не влияет на скорость для остального трафика, работает на устройствах где VPN не настроить (Smart TV, игровые консоли, роутеры).

Минусы: не добавляет шифрование — если сайт работает по HTTP, провайдер видит содержимое. Для HTTPS-сайтов контент уже зашифрован TLS, но провайдер видит IP прокси и может понять что вы обходите блокировки. Работает только против DNS-блокировок. Против IP-блокировок и DPI бессилен. Требует доверия к Smart DNS провайдеру — весь трафик к заблокированным сайтам идёт через него.

Настройка на Linux-сервере — просто меняете DNS:

# /etc/resolv.conf
nameserver IP_SMART_DNS_ПРОВАЙДЕРА

Или через systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=IP_SMART_DNS_ПРОВАЙДЕРА

DOH КАК ИНСТРУМЕНТ ОБХОДА

DNS over HTTPS решает другую задачу — шифрует DNS-запросы. Но у этого есть важный побочный эффект: провайдер не видит, какие домены вы резолвируете, и не может подменить ответ.

Если блокировка работает через DNS-подмену — DoH её обходит автоматически. Вы резолвируете через Cloudflare 1.1.1.1 или Google 8.8.8.8 по зашифрованному каналу на порту 443. Провайдер видит только HTTPS-трафик — не может ни подменить ответ, ни понять что это DNS.

Важно различать DoH и DoT. systemd-resolved поддерживает только DoT — DNS over TLS на порту 853. DoT тоже шифрует трафик и скрывает DNS-запросы от провайдера, но работает на отдельном порту 853, который можно заблокировать. DoH работает на порту 443 — том же что и HTTPS — и заблокировать его без поломки всего интернета невозможно.

Для DoT через systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
DNSOverTLS=yes

systemctl restart systemd-resolved

Проверка что работает:

resolvectl status | grep "DNS over TLS"

Для настоящего DoH на порту 443 — dnscrypt-proxy. Это лёгкий прокси с поддержкой DoH, доступный в стандартных репозиториях начиная с Debian 13 и Ubuntu 25. На более старых дистрибутивах устанавливается с GitHub releases:

apt install dnscrypt-proxy       # Debian 13+ / Ubuntu 25+
dnf install dnscrypt-proxy       # RHEL/Fedora

Настройте upstream-серверы в конфиге:

# /etc/dnscrypt-proxy/dnscrypt-proxy.toml
listen_addresses = ['127.0.0.1:5300']
server_names = ['cloudflare', 'quad9']

systemctl enable --now dnscrypt-proxy

Укажите dnscrypt-proxy как DNS-резолвер в systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=127.0.0.1:5300
DNSOverTLS=no

systemctl restart systemd-resolved

dnscrypt-proxy проксирует все запросы через DoH на порт 443. Провайдер видит обычный HTTPS-трафик.

Ограничения: DoH и DoT работают только против DNS-блокировок. Если сайт заблокирован по IP или через DPI — не поможет. Провайдер не видит DNS-запросы, но видит IP назначения и SNI в TLS.

VPN vs SMART DNS vs DOH — ЧТО И КОГДА

Главная ошибка — выбирать инструмент до того как понял что именно заблокировано. VPN не помогает против DNS-блокировки лучше чем смена резолвера — просто медленнее и дороже.

DNS-блокировка — провайдер подменяет DNS-ответы. Самый распространённый тип в ЕС и большинстве стран с умеренной цензурой. Решение: сменить DNS на 1.1.1.1. Буквально тридцать секунд. DoH — то же самое плюс шифрование запросов. Smart DNS — если нужен IP другой страны. VPN работает, но избыточен как отбойный молоток для гвоздя.

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

DPI — глубокая инспекция пакетов. Провайдер видит не только IP назначения, но и имя домена в SNI, паттерны трафика, сигнатуры протоколов. Смена DNS бесполезна — запрос дойдёт правильно, но соединение всё равно сбросят. Обычный WireGuard или OpenVPN легко определяется по сигнатурам. Работает только обфусцированный трафик: Shadowsocks, VLESS с reality, Trojan — протоколы, которые притворяются обычным HTTPS.

Отдельная ловушка при использовании VPN — DNS leaks. VPN настроен, трафик идёт через туннель, но DNS-запросы продолжают резолвиться через провайдера в обход VPN. Происходит это потому что многие VPN-клиенты создают туннель для IP-трафика, но не трогают системный DNS — он продолжает использовать тот резолвер который был настроен до подключения. Вы думаете что обошли блокировки, а провайдер по-прежнему видит все домены которые вы запрашиваете.

Проверяется на dnsleaktest.com — сайт показывает через какой резолвер идут ваши DNS-запросы. Если в результатах видите IP провайдера вместо VPN-сервера — утечка есть. Исправляется в настройках VPN-клиента (опция «DNS leak protection» или «Use VPN DNS») или принудительной настройкой DoT/DoH поверх VPN.

РЕАЛЬНОСТЬ ПО СТРАНАМ

Литва и большинство стран ЕС. Блокировки существуют — азартные игры, пиратский контент, некоторые финансовые сервисы. Реализованы через DNS на уровне провайдеров. DPI нет. Решение: смена DNS на 1.1.1.1 закрывает вопрос полностью.

Россия. Три уровня одновременно. Роскомнадзор ведёт реестр — провайдеры обязаны блокировать по DNS и IP. Но главное — ТСПУ: оборудование для DPI, установленное у всех крупных провайдеров начиная с 2019 года. Именно ТСПУ замедляло Twitter в 2021-м и блокирует VPN-протоколы сейчас. Смена DNS помогает против части блокировок — тех что без IP-блокировки. Но ТСПУ работает глубже. С 2023 года обычный WireGuard и OpenVPN на многих провайдерах блокируются или замедляются — сигнатуры распознаются. Что работает в 2026: Shadowsocks, VLESS с reality, Trojan. Главный принцип — трафик должен быть неотличим от обычного HTTPS. Вот как это достигается: обычный VPN-протокол имеет узнаваемую сигнатуру — характерное рукопожатие, паттерн пакетов, заголовки. DPI его видит и блокирует. Shadowsocks шифрует трафик так что он выглядит как случайный шум. VLESS с reality идёт дальше — он притворяется реальным TLS-соединением с настоящим сайтом, имитируя его fingerprint вплоть до деталей TLS-рукопожатия. Trojan работает поверх настоящего HTTPS и буквально неотличим от веб-трафика — потому что и является веб-трафиком с точки зрения провайдера.

Китай. Great Firewall — самая технически продвинутая система фильтрации в мире. DNS там заблокированы публичные резолверы (8.8.8.8, 1.1.1.1 недоступны). DPI повсеместный. Большинство VPN-протоколов заблокированы. Работает только глубоко обфусцированный трафик. DNS-решения бесполезны.

Беларусь, Иран. Уровень между Россией и Китаем. DPI есть, но покрытие неполное. Смена DNS + DoH помогает в части случаев. Для надёжного обхода — VPN с обфускацией.

ПРАКТИКА: ЧТО НАСТРОИТЬ НА СЕРВЕРЕ

Базовый уровень — DoT через systemd-resolved. Шифрует DNS-трафик, скрывает запросы от провайдера:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
FallbackDNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=yes

systemctl restart systemd-resolved
resolvectl status

DoH через dnscrypt-proxy — если DoT блокируется провайдером (порт 853 закрыт). dnscrypt-proxy проксирует запросы через DoH на порт 443. Провайдер видит обычный HTTPS-трафик. Доступен в стандартных репо начиная с Debian 13 / Ubuntu 25, на более старых — устанавливается с GitHub releases.

apt install dnscrypt-proxy       # Debian 13+ / Ubuntu 25+
dnf install dnscrypt-proxy       # RHEL/Fedora

# /etc/dnscrypt-proxy/dnscrypt-proxy.toml
listen_addresses = ['127.0.0.1:5300']
server_names = ['cloudflare', 'quad9']

systemctl enable --now dnscrypt-proxy

После этого в systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNS=127.0.0.1:5300
DNSOverTLS=no

systemctl restart systemd-resolved

Проверка что DNS-блокировка обходится:

# Сравните ответы
dig @8.8.8.8 заблокированный_сайт.com
dig заблокированный_сайт.com

Если ответы совпадают — шифрование работает, провайдер не подменяет ответы.

ПОЧЕМУ DNS НЕ СЕРЕБРЯНАЯ ПУЛЯ

Представьте: вы зашифровали адресную книгу. Никто не видит куда вы едете. Но когда выезжаете на улицу — табличка с названием улицы и номером дома всё равно видна всем вокруг.

Именно так работает SNI — Server Name Indication. Это поле в TLS-рукопожатии, где клиент открытым текстом сообщает имя домена к которому подключается. Нужно чтобы сервер знал какой сертификат показать — один IP может обслуживать сотни доменов. DNS зашифрован через DoH, а имя домена в SNI видно любому наблюдателю по дороге.

Именно через SNI провайдер с DPI определяет к какому домену вы подключаетесь — даже если DNS-запрос шёл зашифрованным. Поэтому DoH скрывает DNS-запросы, но не скрывает само соединение с заблокированным ресурсом.

ECH — Encrypted Client Hello — шифрует SNI. Cloudflare поддерживает, Firefox поддерживает. Но провайдеры с DPI просто блокируют соединения с ECH как подозрительные. Что само по себе говорит о том, насколько серьёзно они относятся к этому вопросу.

Вывод простой: DoH — хорошая практика в любом случае, включайте всегда. Но против DPI DNS-инструменты не помогают. Там нужна обфускация трафика на уровне протокола.

Ещё один важный нюанс который часто упускают: DoH не устраняет проблему доверия — он её перемещает. Раньше ваш провайдер видел все DNS-запросы. С DoH их видит Cloudflare или Google. Вы просто сменили наблюдателя.

Браузерный DoH идёт дальше — он молча обходит ваш локальный резолвер. Если у вас настроена фильтрация рекламы, блокировка малвари или мониторинг DNS на уровне сети — браузер с включённым DoH всё это игнорирует без вашего ведома. Firefox использует Cloudflare, Chrome обновляет системный DNS до DoH — и ваш локальный Pi-hole или корпоративный файрвол перестаёт работать для браузерного трафика.

Правильное решение когда нужны и приватность и контроль — свой локальный резолвер. dnscrypt-proxy или Unbound с DoT upstream к 1.1.1.1 дают шифрование исходящего DNS-трафика и полный контроль над тем что фильтруется, логируется и блокируется. Вы шифруете трафик между собой и публичным резолвером, но при этом остаётесь хозяином своей сети.

В корпоративной сети браузерный DoH нужно отключать через групповые политики. Иначе сотрудники обходят корпоративный DNS — фильтрацию, мониторинг, блокировку — просто открыв браузер с настройками по умолчанию. DoT в этом контексте лучше: DNS остаётся отдельным сервисом который можно контролировать и мониторить, шифрование при этом есть.

В Chrome DoH отключается через реестр:

HKLM\SOFTWARE\Policies\Google\Chrome\DnsOverHttpsMode = off

В Firefox через корпоративный policies.json:

{
  "policies": {
    "DNSOverHTTPS": {
      "Enabled": false,
      "Locked": true
    }
  }
}

Locked: true важен — без него пользователь может включить DoH обратно через about:config.

И ещё один нестандартный сценарий который редко упоминают: взломанный роутер. Если злоумышленник получил доступ к роутеру — он меняет DNS на свой в настройках DHCP. Все устройства в сети автоматически получают его резолвер и резолвируют через него. Смена DNS вручную на устройстве помогает, но не всегда — часть устройств принудительно берёт DNS только с роутера и игнорирует ручные настройки.

DoH в браузере обходит это полностью — и вот почему. Браузер с включённым DoH не использует системный резолвер вообще. Он напрямую отправляет зашифрованный DNS-запрос на 1.1.1.1 или 8.8.8.8 через HTTPS. Роутер видит только HTTPS-трафик на порт 443 — подменить его без сертификата невозможно. Злоумышленник управляет DNS-сервером который раздаёт роутер, но браузер этим DNS-сервером не пользуется. Именно поэтому DoH в браузере — полезная привычка даже в доверенной сети.

ЧЕКЛИСТ

Определите уровень блокировки перед выбором инструмента:

# DNS-блокировка?
dig @1.1.1.1 сайт.com
dig @провайдерский_dns сайт.com

# IP доступен?
curl -v --connect-timeout 5 https://сайт.com

# Трассировка где обрывается
traceroute сайт.com

Выберите инструмент:
— DNS-блокировка → смените DNS на 1.1.1.1 или включите DoH
— IP-блокировка → Smart DNS или VPN
— DPI → VPN с обфускацией (Shadowsocks, VLESS, Trojan)

Дополнительно:
— DoH включите в любом случае — шифрует DNS независимо от блокировок
— Для серверов пропишите резервный DNS чтобы не зависеть от одного провайдера
— При использовании VPN проверьте DNS leaks на dnsleaktest.com

ИТОГ

Блокировка блокировке рознь. DNS-решения — быстрые, лёгкие, без инфраструктуры — закрывают большинство случаев в странах с умеренной цензурой. Там где стоит DPI, DNS бессилен, и нужны другие инструменты.

Правило простое: сначала поймите как именно заблокировано. Потом выбирайте инструмент. Не наоборот.