доступа к частному dns серверу нет при включении впн

доступа к частному dns серверу нет при включении впн

Title: OpenWrt и DNS через HTTPS: настраиваем без утечек
Description: Пошаговый гайд: https-dns-proxy, dnsmasq, iptables. Настраивай роутер за 30 минут и забудь о перехваченных запросах.
Роутер как последний бастион: поднимаем HTTPS DNS proxy на OpenWrt
Когда речь заходит о приватности на уровне домашней сети, https dns proxy openwrt настройка превращается из сухой строчки в поисковике в реальную линию обороны. Большинство ограничивается тем, что вбивает 1.1.1.1 или 77.88.8.8 в веб-интерфейсе маршрутизатора, и искренне верит, что теперь «всё защищено». На деле провайдер — будь то Ростелеком, МТС или Дом.ру — по-прежнему видит каждый твой DNS-запрос в открытом виде, словно ты отправляешь почтовую открытку без конверта. Разбираемся, как зашифровать этот трафик на роутере под управлением OpenWrt, почему в 2026 году это перестало быть опцией и какие подводные камни ждут тебя на пути от opkg install до реального отсутствия утечек.
Обычный DNS: как ты сам отдаёшь провайдеру карту своей цифровой жизни
Представь: ты сидишь дома, открываешь браузер и переходишь на banki.ru. Прежде чем страница загрузится, твой роутер отправляет запрос на DNS-сервер провайдера: «А покажи-ка мне IP-адрес для banki.ru». Запрос летит по сети в открытом виде — любой, кто стоит между тобой и DNS-сервером (сотрудник кафе на публичном Wi-Fi, админ корпоративной сети, или сам провайдер через DPI-систему), видит, на какой домен ты заходишь.
Провайдеры в России по закону Яровой обязаны хранить метаданные соединений до 3 лет. Это означает, что каждый DNS-запрос — а их у среднего пользователя набегает от 5 до 15 тысяч в сутки — попадает в базу данных. Даже если ты не делаешь ничего противозаконного, эта информация может быть использована для:
* Составления профиля интересов (медицинские сайты, политические ресурсы, конкуренты по работе)
* Таргетированной рекламы на основе посещённых доменов
* Блокировки ресурсов по решению РКН — если ты пытаешься открыть заблокированный Telegram или LinkedIn, провайдер видит сам факт попытки
Добавь сюда WebRTC — технологию, встроенную в браузеры для голосовых звонков. Она умеет «пробивать» твой реальный IP-адрес даже через VPN, если не настроена правильно. В связке с открытым DNS это даёт полную картину твоей сетевой активности.
Три кита шифрованного DNS: DoH, DoT, DNSCrypt
Чтобы закрыть эту дыру, инженеры придумали три основных протокола шифрования DNS-трафика. Каждый со своими нюансами.
DNS-over-TLS (DoT) работает на выделенном порту 853/TCP. Он оборачивает обычные DNS-запросы в TLS-туннель — тот же механизм, что используется в HTTPS. Плюс: трафик шифруется, провайдер не видит содержимое запросов. Минус: порт 853 хорошо известен, и в некоторых корпоративных сетях или странах с жёсткой цензурой его блокируют первым делом. В России случаи блокировки 853 порта пока единичны, но тенденция есть.
DNS-over-HTTPS (DoH) маскирует DNS-запросы под обычный HTTPS-трафик на порту 443. Для наблюдателя это выглядит как очередное обращение к cloudflare.com или google.com — отличить DNS-запрос от загрузки картинки практически невозможно без анализа SNI (Server Name Indication) в TLS-рукопожатии. Это делает DoH самым устойчивым к DPI-системам вариантом. Обратная сторона: SNI всё-таки виден до завершения handshake, поэтому некоторые реализации используют ECH (Encrypted Client Hello) — расширение TLS 1.3, которое шифрует и SNI.
DNSCrypt — более старый протокол, разработанный ещё в 2012 году. Он работает как по UDP, так и по TCP, поддерживает обфускацию трафика и аутентификацию серверов. Минус: менее распространён, меньше публичных ресолверов, сложнее в настройке. Зато даёт дополнительную защиту от подмены DNS-ответов.
Для домашнего роутера на OpenWrt оптимум — DoH. Он маскируется под обычный веб-трафик, работает через стандартный порт 443 и поддерживается большинством крупных провайдеров.
Выбор оружия: https-dns-proxy против Stubby и Stunnel
На OpenWrt есть три основных способа поднять зашифрованный DNS. Разберём каждый.
Stubby — эталонная реализация DoT от getdnsapi. Лёгкий, написан на C, жрёт минимум памяти (около 2-3 МБ). Но работает только с DoT, а не с DoH. Если твой провайдер режет порт 853 — упрёшься в стену.
Stunnel — универсальный туннелизатор, который может обернуть в TLS что угодно, включая обычный DNS. Гибкий, но требует ручной настройки сертификатов и больше ресурсов. На слабом роутере вроде TP-Link Archer C7 v5 с 128 МБ RAM может стать узким местом.
https-dns-proxy — специализированный пакет именно для DoH. Написан под OpenWrt, интегрируется с LuCI (веб-интерфейсом), поддерживает множество провайдеров из коробки, автоматически обновляет списки эндпоинтов. Занимает около 4-5 МБ RAM, что приемлемо для большинства домашних маршрутизаторов. Именно его мы и будем ставить.
Если у тебя роутер с 64 МБ RAM и меньше — смотри в сторону Stubby + DoT. Если 128 МБ и выше — бери https-dns-proxy и не мучайся.
Пошаговая установка на OpenWrt 23.05 и 24.10
Проверено на версиях 23.05.3 и 24.10.0. На более старых сборках (21.02 и ниже) пакет может отсутствовать в репозитории — придётся собирать из исходников.
Шаг 1. Подключаемся по SSH и обновляем списки пакетов:

ssh root@192.168.1.1
opkg update

Шаг 2. Устанавливаем сам пакет и зависимости:

opkg install https-dns-proxy luci-app-https-dns-proxy ca-bundle

ca-bundle — критически важен. Без актуальных корневых сертификатов TLS-соединения с DoH-серверами просто не установятся.
Шаг 3. Настраиваем провайдеров. Открываем /etc/config/https-dns-proxy:

config main 'config'
    option enabled '1'
    option port '5053'
    option bootstrap_dns '9.9.9.9,149.112.112.112,2620:fe::fe'
config https-dns-proxy
    option name 'Cloudflare'
    option enabled '1'
    option resolver_url 'https://cloudflare-dns.com/dns-query'
    option listen_addr '127.0.0.1'
    option listen_port '5053'
config https-dns-proxy
    option name 'Quad9'
    option enabled '0'
    option resolver_url 'https://dns.quad9.net/dns-query'
    option listen_addr '127.0.0.1'
    option listen_port '5054'

Обрати внимание на bootstrap_dns — это обычные DNS-серверы, которые используются для резолвинга доменных имён самих DoH-серверов (например, cloudflare-dns.com). Если указать сюда DNS провайдера, возникает парадокс: чтобы зашифровать DNS, нужно сначала сделать нешифрованный запрос. Поэтому ставим Quad9 (9.9.9.9) или любой другой независимый ресолвер.
Шаг 4. Запускаем сервис:

/etc/init.d/https-dns-proxy start
/etc/init.d/https-dns-proxy enable

Проверяем, что процесс слушает порт:

netstat -tlnp | grep 5053

Должно быть что-то вроде:

tcp  0  0  127.0.0.1:5053  0.0.0.0:*  LISTEN  1234/https-dns-prox

DNSMasq: заставляем роутер слушать только прокси
По умолчанию DNSMasq (встроенный в OpenWrt DHCP/DNS-форвардер) пересылает запросы на апстрим-серверы провайдера. Нужно переориентировать его на наш локальный прокси.
Открываем /etc/config/dhcp и находим секцию dnsmasq:

config dnsmasq
    option domainneeded '1'
    option localise_queries '1'
    option rebind_protection '1'
    option local '/lan/'
    option domain 'lan'
    option expandhosts '1'
    option authoritative '1'
    option readethers '1'
    option leasefile '/tmp/dhcp.leases'
    option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
    option port '53'
    list server '127.0.0.1#5053'
    list server '::1#5053'
    option nonwildcard '0'

Ключевые строки — list server '127.0.0.1#5053'. Они говорят DNSMasq: все внешние запросы отправляй на локальный порт 5053, где сидит https-dns-proxy.
Перезапускаем DNSMasq:

/etc/init.d/dnsmasq restart

Теперь любое устройство в твоей сети — телефон, ноутбук, умная лампочка — будет делать DNS-запросы через зашифрованный канал. Без необходимости настраивать каждое устройство отдельно.
iptables и nftables: закрываем 53-й порт наглухо
Настройка прокси — это только половина дела. Если какое-то устройство в сети (или вредонос на нём) решит обойти DNSMasq и отправить запрос напрямую на внешний DNS-сервер, вся приватность полетит к чертям. Нужен kill switch на уровне файрвола.
Для OpenWrt 23.05 (iptables):
Создаём файл /etc/firewall.user и добавляем:

Блокируем исходящий DNS (порт 53) для всех, кроме локального прокси
iptables -I zone_wan_forward -p udp --dport 53 -j DROP
iptables -I zone_wan_forward -p tcp --dport 53 -j DROP
Блокируем DoT на всякий случай
iptables -I zone_wan_forward -p tcp --dport 853 -j DROP

Для OpenWrt 24.10 (nftables):
Начиная с версии 24.10, OpenWrt перешёл на nftables. Синтаксис другой:

В /etc/firewall.user
chain zone_wan_forward {
    type filter hook forward priority filter + 1; policy accept;
    oifname "wan" udp dport 53 drop
    oifname "wan" tcp dport 53 drop
    oifname "wan" tcp dport 853 drop
}

Перезагружаем файрвол:

/etc/init.d/firewall restart

После этого ни одно устройство в сети физически не сможет отправить DNS-запрос наружу в обход прокси. Все попытки будут молча дропаться.
Split tunneling по доменам: избирательная маршрутизация
Иногда нужно, чтобы определённые домены резолвились через обычный DNS — например, локальные ресурсы провайдера для IPTV или внутренние сервисы компании. Для этого используется split tunneling.
В /etc/config/dhcp добавляем:

config dnsmasq
    ...
    list server '/local.provider.ru/77.88.8.8'
    list server '/corp.company.com/10.0.0.1'

Теперь запросы к local.provider.ru пойдут напрямую на DNS Яндекса, а всё остальное — через зашифрованный прокси.
Более продвинутый вариант — использовать ipset для маркировки трафика по доменам и маршрутизировать его через разные интерфейсы (например, основной канал и VPN-туннель). Это требует настройки nftables sets и policy routing, но даёт полный контроль над тем, какой трафик куда идёт.
Чего вам НЕ говорят в других гайдах
Большинство туториалов в интернете заканчиваются на фразе «готово, теперь ваш DNS зашифрован». За кадром остаётся масса нюансов, которые превращают красивую схему в решето.
Бесплатные VPN продают твой трафик. Сервисы вроде Hola VPN, Betternet или SuperVPN не берут с тебя денег не из альтруизма. Они монетизируют твой канал, продавая его как «резидентный прокси» корпоративным клиентам. В 2015 году исследователи показали, что через сеть Hola запускали DDoS-атаки. Если ты используешь бесплатный VPN — ты не клиент, ты товар.
Тесты на утечки врут. Сайты вроде dnsleaktest.com или ipleak.net показывают, что видит удалённый сервер. Но они не показывают, что видит твой провайдер на промежуточных узлах. Более того, некоторые «тесты» сами по себе являются трекерами — собирают отпечаток браузера и IP. Используй их как первичную проверку, но не как истину в последней инстанции.
Логи по решению суда. Даже провайдеры с «no-log policy» в юрисдикциях 14 Eyes (США, Великобритания, Германия и др.) обязаны выдавать данные по запросу суда. Вопрос не в том, ведутся ли логи постоянно, а в том, могут ли они быть собраны точечно. Mullvad, например, физически не имеет данных для выдачи — они сжигают логи при каждом перезапуске сервера и принимают оплату в BTC/XMR. Но это скорее исключение.
Отсутствие независимых аудитов. Многие VPN-сервисы заявляют об аудитах, но на деле это self-reported отчёты без публичной методологии. Нормальный аудит — это когда Cure53, Quarkslab или PwC публикуют полный отчёт с найденными уязвимостями и их исправлением. Если ты не можешь найти PDF отчёта на сайте провайдера — аудита не было.
Поддельный kill switch. Некоторые роутерные прошивки рекламируют «kill switch», но на деле он срабатывает только при разрыве VPN-соединения, а не при падении самого туннеля. Если WireGuard-сервер завис, но TCP-соединение формально активно, kill switch не сработает, и трафик пойдёт в обход. Проверяй это вручную: убей процесс VPN на роутере и попробуй открыть сайт. Если открылся — kill switch не работает.
Bootstrap DNS — скрытая утечка. Как я уже упоминал выше, для резолвинга доменных имён DoH-серверов нужен обычный DNS. Если ты оставил тут DNS провайдера — он видит каждый твой «запрос к запросу». Всегда ставь независимый bootstrap: Quad9, Cloudflare или свой собственный рекурсор.
Сравнение провайдеров зашифрованного DNS
| Провайдер | Юрисдикция | Политика логов | Протоколы | Фильтрация | Стоимость |
|-----------|------------|----------------|-----------|------------|-----------|
| Cloudflare (1.1.1.1) | США (14 Eyes) | Аудит KPMG, минимум метаданных | DoH, DoT | Нет | Бесплатно |
| Quad9 | Швейцария | Нет логов, аудит Deloitte | DoH, DoT, DNSCrypt | Блокировка угроз (IBM X-Force) | Бесплатно |
| AdGuard DNS | Кипр / РФ | Частичные логи (24 часа) | DoH, DoT, DNSCrypt | Реклама + трекеры | Бесплатно / €2/мес |
| NextDNS | Германия / США | Логи по запросу, 3 месяца | DoH, DoT, DNSCrypt, DoQ | Полностью настраиваемая | Бесплатно до 300k запросов/мес |
| Mullvad DNS | Швеция | No-log, физически невозможно | DoH, DoT | Нет | Включён в подписку (€5/мес) |
| Control D | Канада (5 Eyes) | Аудит Deloitte, минимум | DoH, DoT, DoQ | Настраиваемая | От $2/мес |
Обрати внимание: «бесплатно» не значит «безопасно». Cloudflare и Quad9 — хорошие варианты, но они находятся в юрисдикциях с разведывательными альянсами. Mullvad и NextDNS дают больше контроля, но стоят денег.
Проверка на утечки: три уровня диагностики
Настроил? Теперь проверь, что всё работает.
Уровень 1. Базовая проверка DNS. Заходи на browserleaks.com/dns или dnsleaktest.com и запускай «extended test». Должен видеть только IP-адреса своего DoH-провайдера (например, Cloudflare), а не провайдера домашнего.
Уровень 2. Проверка WebRTC. На browserleaks.com/webrtc смотри, не светится ли твой реальный IP. Если да — отключай WebRTC в настройках браузера или ставь расширение.
Уровень 3. Сниффер на роутере. Самый надёжный способ. Поднимаешь tcpdump на WAN-интерфейсе:

tcpdump -i eth0.2 -n port 53

И параллельно делаешь DNS-запросы с клиента. В выводе tcpdump должны быть только обращения к bootstrap DNS (9.9.9.9) и к DoH-серверу на порт 443. Любые запросы на 53 порт в вывод — это утечка.
Типичные грабли, на которые наступают 9 из 10
Не обновлён ca-bundle. TLS-соединение не устанавливается, https-dns-proxy молча падает обратно на bootstrap DNS. Решение: opkg install ca-bundle && /etc/init.d/https-dns-proxy restart.
Забыли перезапустить DNSMasq. Изменили конфиг, а старый процесс продолжает форвардить на провайдера. Всегда делай /etc/init.d/dnsmasq restart после правок.
IPv6 утекает. Настроил IPv4 DNS, а IPv6 продолжает использовать DNS провайдера. В /etc/config/dhcp добавь list server '::1#5053' и убедись, что https-dns-proxy слушает и на IPv6.
MTU и WireGuard. Если ты используешь VPN-туннель поверх DoH, добавляется двойная инкапсуляция. Стандартные 1500 байт MTU могут не пролезть. Уменьшай MTU на WireGuard-интерфейсе до 1380-1420:

ip link set mtu 1400 dev wg0

DNS rebinding атаки. Если ты используешь DoH для резолвинга локальных доменов (.lan, .local), DNSMasq может отбрасывать такие запросы из-за rebind_protection. Для локальных зон добавь list rebind_domain 'lan' в конфиг.

Вопросы и ответы

Замедлит ли DoH интернет и на сколько реально?

Задержка увеличивается на 10-30 мс на каждый DNS-запрос из-за TLS-рукопожатия. Но современные реализации используют сессионные тикеты и 0-RTT, так что повторные запросы идут почти без задержки. На практике ты заметишь разницу только при первом открытии нового домена — страница загрузится на 0.03 секунды дольше. Скорость скачивания файлов не страдает, потому что DNS участвует только в начале соединения.

Можно ли обойтись без VPN, используя только DoH на роутере?

DoH шифрует только DNS-запросы. Он скрывает от провайдера, на какие домены ты заходишь, но не скрывает IP-адреса этих доменов и сам трафик. Провайдер всё равно видит, что ты соединяешься с 149.154.167.99 (Telegram), даже если не знает, что это Telegram. Для полной приватности нужен VPN или Tor. DoH — это защита от пассивного наблюдения, а не от активного.

🚀Начать защиту

WireGuard или OpenVPN — что безопаснее в 2026?

WireGuard использует современные алгоритмы: ChaCha20-Poly1305 для шифрования, Curve25519 для обмена ключами, BLAKE2s для хеширования. Код — около 4000 строк, что позволяет провести полный аудит. OpenVPN — 100 000+ строк, поддерживает больше алгоритмов (включая устаревшие), но сложнее в анализе. WireGuard быстрее (на 10-15% на слабых CPU), проще в настройке, но не поддерживает perfect forward secrecy из коробки — ключи статичны, требуется дополнительная настройка через wg-dynamic. Для большинства задач WireGuard оптимален.

Найдут ли меня спецслужбы, если я использую DoH + VPN?

Зависит от юрисдикции VPN-провайдера и его политики логов. Если провайдер находится в стране без обязательств по хранению данных (Панама, Британские Виргинские острова, Швейцария) и реально не ведёт логи (подтверждено независимым аудитом) — вычислить тебя крайне сложно. Но «крайне сложно» не значит «невозможно». Утечки через WebRTC, ошибки конфигурации, корреляция по времени, судебные запросы к платёжным системам — всё это реальные векторы. Абсолютной анонимности не существует.

Как DPI-системы реагируют на зашифрованный DNS?

DPI (Deep Packet Inspection) анализирует содержимое пакетов. С DoH DNS-запросы выглядят как обычный HTTPS-трафик на порт 443. DPI видит только SNI (например, `cloudflare-dns.com`) и объём данных, но не конкретные запрашиваемые домены. Некоторые продвинутые DPI-системы пытаются блокировать DoH по сигнатурам — например, по характерному паттерну TLS-рукопожатия или по размеру пакетов. В России такие системы (ТСПУ) теоретически способны блокировать DoH, но на практике это делается точечно и не массово.

🔑Приватность онлайн

Нужно ли регулярно менять провайдера DoH?

Нет технической необходимости ротировать провайдера, если тебя устраивает его политика. Но с точки зрения приватности — чем меньше информации сосредоточено у одного игрока, тем лучше. Можно настроить ротацию: утром запросы идут через Cloudflare, днём через Quad9, вечером через NextDNS. Это усложняет построение полного профиля твоей активности. В https-dns-proxy это делается через несколько инстансов с разными listen_port и round-robin в DNSMasq.

Работает ли split tunneling с https-dns-proxy?

Да, через dnsmasq. Ты можешь указать, что определённые домены (например, `*.lan` или `*.corp.company.com`) должны резолвиться через обычный DNS, а всё остальное — через DoH-прокси. Это полезно для доступа к локальным ресурсам провайдера или корпоративным сервисам, которые не работают через зашифрованный DNS. Конфигурация описана в разделе про split tunneling выше.

Вывод
https dns proxy openwrt настройка — это не просто техническая exercise, а базовый уровень гигиены в мире, где каждый твой запрос может быть записан, продан или использован против тебя. Шифрование DNS на уровне роутера закрывает одну из самых очевидных дыр — открытые запросы к провайдеру — и делает это прозрачно для всех устройств в сети. Но важно понимать: DoH — это не серебряная пуля. Без VPN он не скроет IP-адреса, без файрвола возможны утечки, без понимания юрисдикций ты можешь доверять данные тем, кому не следует. Настройка https-dns-proxy на OpenWrt занимает 30 минут, но требует вдумчивого подхода: выбор провайдера, настройка bootstrap DNS, блокировка 53 порта, проверка на утечки. Если ты прошёл все эти шаги — твой домашний роутер стал на порядок безопаснее, чем у 95% пользователей. Это не паранойя, это разумная предосторожность.