← Назад в базу знаний

- Как DNS-over-HTTPS ломает работу прокси и почему сайты видят ваш реальный IP

- Как DNS-over-HTTPS ломает работу прокси и почему сайты видят ваш реальный IP

DNS-over-HTTPS — штука коварная. Вроде бы создана для защиты от слежки, а на практике превращает вашу работу через прокси в хождение по минному полю. Сайты, которые вы обходите, видят ваш настоящий IP. И самое смешное — виноваты в этом не они, а ваш собственный браузер, который решил быть слишком умным.

Всё дело в том, как устроена маршрутизация трафика. Когда вы подключаетесь через прокси, ваш HTTP-запрос идёт через прокси-сервер. Но DNS-запросы — совсем другое дело. Они могут уходить напрямую, минуя прокси. А с включённым DoH это происходит почти всегда.

Анатомия утечки

Разберём по шагам. Браузер хочет открыть site.com. Он обращается к DNS-резолверу. Если включён DoH, запрос уходит по HTTPS к серверу Cloudflare или Google. Локальный DNS-резолвер вашего провайдера или вашей системы не участвует.

Теперь важный момент: DoH-запрос идёт напрямую от вашего устройства в интернет. Он не проходит через прокси. Прокси-сервер об этом запросе вообще не знает. А дальше начинается цирк.

Вы подключаетесь к site.com через прокси. Прокси передаёт ваш запрос. Но сайт видит, что DNS-запрос пришёл с одного IP, а HTTP-запрос — с другого. Для современной системы защиты это выглядит подозрительно. Многие сайты просто блокируют такие сессии.

Пример: сервер nginx 1.24 с модулем ngx_http_realip_module. Он проверяет соответствие IP в DNS-запросе и IP HTTP-соединения. Несовпадение — 403 Forbidden. Причём без каких-либо объяснений.

Как DoH обходит настройки системы

Самый распространённый сценарий — браузер с включённым DoH по умолчанию. Firefox и Chrome делают это автоматически для своих пользователей. При этом системный DNS вы можете настроить как угодно — хоть на 1.1.1.1, хоть на 8.8.8.8.

Браузер игнорирует системные настройки. Он использует свой собственный DNS-over-HTTPS. Это заложено в архитектуру. Firefox использует Cloudflare, Chrome — свой резолвер. И никакие системные настройки прокси на это не влияют.

Вот как это выглядит на практике. Вы настроили прокси на уровне системы. Все приложения ходят через него. Открываете Firefox — он делает DNS-запрос напрямую к Cloudflare. Потом идёт HTTP-запрос через прокси. Сайт видит несоответствие.

Способы диагностики

Проверить, утекает ли ваш DNS, можно простым способом. Откройте сайт, который показывает ваш IP. Затем посмотрите, какие DNS-серверы видит ваша система.

dig +short myip.opendns.com @resolver1.opendns.com

Эта команда покажет ваш IP, который видит DNS-резолвер OpenDNS. Если он отличается от IP, который видит сайт через прокси — у вас утечка.

Второй способ — посмотреть логи DNS-запросов на прокси-сервере. Если запросы к site.com появляются в логах, значит, они проходят через прокси. Если нет — утечка.

Методы решения

Первый способ — отключить DoH в браузере. В Firefox: Настройки → Приватность и защита → DNS-over-HTTPS → Отключить. В Chrome: Настройки → Приватность и безопасность → Безопасность → Использовать безопасный DNS → Отключить.

Но это не всегда возможно. Корпоративные политики, родительский контроль, требования безопасности — всё это заставляет оставлять DoH включённым.

Второй способ — настроить прокси так, чтобы он перехватывал DNS-запросы. Для этого нужен прокси с поддержкой DNS-перехвата. Например, 3proxy с модулем dns. Или squid с опцией dns_nameservers.

Пример настройки 3proxy:

```

nserver 1.1.1.1

nserver 8.8.8.8

dns

```

Эти строки в конфигурации заставляют прокси-сервер обрабатывать DNS-запросы от клиентов. Браузер будет отправлять DNS-запросы через прокси, а не напрямую.

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

Пример с curl

Проверим, как работает DoH с прокси. Вот команда, которая делает запрос через прокси с использованием DoH:

```

curl --proxy socks5://127.0.0.1:1080 --dns-servers 1.1.1.1 https://api.ipify.org

```

Эта команда заставляет curl использовать DNS-сервер 1.1.1.1 для разрешения имени. При этом запрос идёт через SOCKS-прокси. Если прокси поддерживает DNS-перехват, всё будет работать правильно.

Если прокси не перехватывает DNS, запрос уйдёт напрямую. Сайт api.ipify.org вернёт ваш реальный IP. И вы увидите утечку.

Как работает DNS через SOCKS

SOCKS5-прокси поддерживают два режима работы с DNS. В первом случае клиент сам разрешает имя и передаёт прокси IP-адрес. Во втором — клиент передаёт имя, а прокси сам делает DNS-запрос.

Второй режим — это то, что нам нужно. Он называется SOCKS5h. В curl это флаг --socks5-hostname. В Python это параметр proxy_socks5h в библиотеке requests.

```python

import requests

proxies = {

'http': 'socks5h://127.0.0.1:1080',

'https': 'socks5h://127.0.0.1:1080'

}

response = requests.get('https://api.ipify.org', proxies=proxies)

print(response.text)

```

Этот код передаёт имя хоста прокси-серверу. Прокси сам делает DNS-запрос. Браузер не участвует в разрешении имени. Утечки нет.

Настройка Firefox для работы через прокси

Firefox имеет собственную систему DNS. Она работает независимо от системной. Чтобы заставить Firefox использовать прокси для DNS, нужно изменить несколько настроек.

Откройте about:config. Найдите параметр network.proxy.socks_remote_dns. Установите его в true. Это заставит Firefox передавать DNS-запросы через SOCKS-прокси. Но учтите: это работает только для SOCKS-прокси. Для HTTP-прокси такой настройки нет.

Если вы используете HTTP-прокси, придётся отключить DoH в браузере. Или использовать прокси, который поддерживает DNS-перехват на уровне протокола.

Прокси с DNS-перехватом

На рынке есть прокси, которые умеют перехватывать DNS-запросы. Например, сервис lexic.ml предоставляет прокси с встроенной обработкой DNS. Это решает проблему автоматически: все DNS-запросы от браузера обрабатываются прокси-сервером, и утечки не происходит.

Такие прокси работают на уровне протокола. Они анализируют трафик и определяют, какие запросы являются DNS. Затем обрабатывают их самостоятельно, не передавая клиенту.

Проблемы с HTTP-прокси

HTTP-прокси — это отдельная история. Они не поддерживают DNS-перехват на уровне протокола. Клиент всегда сам разрешает имя хоста. Поэтому при использовании HTTP-прокси DoH будет всегда утекать.

Решение — либо отключать DoH, либо использовать SOCKS-прокси. Либо использовать прокси, который работает на уровне TCP-соединений, а не на уровне HTTP-протокола.

Кейс: корпоративная сеть

Представьте: компания использует прокси для контроля доступа в интернет. Сотрудники работают через браузеры с включённым DoH. Внезапно половина сайтов перестаёт открываться.

Диагностика показала: сайты возвращают ошибку 403. Причина — несоответствие IP в DNS-запросе и IP в HTTP-соединении. DNS-запросы уходят напрямую к Cloudflare, а HTTP-трафик идёт через прокси компании.

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

Кейс: домашний прокси

Домашний пользователь настроил прокси на роутере. Пользуется им для обхода блокировок. Включает DoH в браузере — и все заблокированные сайты перестают открываться.

Причина та же: DNS-запросы идут напрямую, минуя прокси. Сайты видят реальный IP и блокируют доступ. Решение — отключить DoH или использовать прокси с DNS-перехватом.

Кейс: публичный Wi-Fi

В общественном Wi-Fi включён DoH. Прокси настроен на уровне системы. Браузер отправляет DNS-запросы напрямую. Wi-Fi-провайдер видит все запросы.

Это не просто утечка IP. Это утечка всей истории посещений. Провайдер видит, какие сайты вы посещаете, даже если трафик зашифрован. Решение — использовать SOCKS-прокси с передачей имени хоста на прокси.

Что делать, если ничего не помогает

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

В Windows это делается через реестр. В Linux — через настройки systemd-resolved. В macOS — через профили конфигурации. Каждый случай требует индивидуального подхода.

Резюме

DoH ломает работу прокси, потому что DNS-запросы идут в обход прокси-сервера. Сайты видят несоответствие IP и блокируют доступ. Решение — либо отключать DoH, либо использовать прокси с поддержкой DNS-перехвата. SOCKS5-прокси с передачей имени хоста решают проблему автоматически. HTTP-прокси — нет.

Проверяйте свои настройки. Тестируйте утечки. И помните: прокси без DNS-перехвата — это прокси с дырой.

✔️Купить прокси