DNS через прокси: где разрешается имя сайта и какой режим выбрать

Короткий ответ

Имя сайта может разрешаться со стороны приложения на вашем устройстве или со стороны прокси, которому передано это имя. Конкретный вариант зависит от программы, протокола и настроек. Само включение прокси еще не означает, что поиск имен выполняется на его стороне.

Разрешение через прокси выбирайте, если имя сайта не должно попадать в DNS-запросы со стороны клиента. При этом проверьте, не запрашивает ли приложение то же имя отдельно. Локальный поиск может понадобиться для внутреннего сервиса, адрес которого известен только DNS вашей организации. В любом режиме найденный IP должен быть доступен из сети прокси.

Главное

• Внешний IP показывает, откуда пришел веб-запрос. По нему нельзя определить, кто разрешил имя сайта.
• Одинаковые параметры прокси не означают одинаковое поведение программ: Chrome и curl могут по-разному обрабатывать имя назначения.
• Поиск адреса самого прокси и поиск адреса открываемого сайта – разные запросы. При проверке важно различать эти имена.

Кому и когда полезна такая проверка?

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

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

Что меняется при разрешении имени через прокси?

Меняется сторона, которая узнает адрес сайта, а иногда и сам ответ. Допустим, вы открываете shop.example через SOCKS5. Приложение может сначала узнать IP и отправить его прокси. Другой вариант – передать shop.example, чтобы адрес нашли на стороне сервера.

«На стороне прокси» не означает, что на нем обязательно запущен DNS-сервер: за ответом он может обратиться к отдельному резолверу. При локальном разрешении приложение ищет адрес со своей стороны – через системный резолвер или DNS over HTTPS.

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

Что приложение отправляет HTTP- и SOCKS5-прокси?

HTTP-прокси обычно получает имя сайта в запросе, а SOCKS5 допускает и имя, и готовый IP. Здесь важны правила конкретного клиента.

При обычном HTTP/1.1-запросе через HTTP-прокси приложение передает полный адрес страницы. Для HTTPS оно обычно просит открыть туннель командой CONNECT, указывая имя сайта и порт. Некоторые программы заранее ищут IP для своих задач, но затем все равно передают прокси домен. По одному предварительному DNS-запросу нельзя определить, передало ли приложение прокси имя сайта или готовый IP.

В SOCKS5 клиент явно указывает тип адреса: доменное имя или IP. В curl схема socks5:// означает локальный поиск, а socks5h:// – передачу имени на сторону прокси. Chrome тоже использует запись socks5:// в настройке, но отправляет SOCKS5-серверу имя сайта. Правило curl нельзя переносить на браузер только из-за похожей записи.

Какой режим выбрать для вашей задачи?

Выбор зависит от того, какая DNS-служба знает нужное имя и допустим ли его поиск со стороны клиента. Учитывайте три ситуации:

• Внутренний сервис известен только DNS организации. Может понадобиться локальное разрешение через эту службу. Однако прокси все равно должен иметь маршрут к полученному адресу; иначе нужен предусмотренный организацией способ доступа.
• Локальная DNS-служба не находит внешний домен. Разрешение на стороне прокси стоит проверить как другой вариант: там может быть доступен ответ, которого нет у клиента. Само переключение еще не гарантирует, что сайт откроется.
• Имя сайта не должно запрашиваться со стороны устройства. Выберите в приложении передачу имени прокси и проверьте, не выполняет ли оно отдельный поиск того же имени.

Если обе стороны находят нужный адрес, соединение работает и специальных требований к DNS-маршруту нет, текущий режим можно сохранить.

Где проверить текущий режим?

Проверьте DNS-настройки программы, в которой выполняете запрос. В Firefox и Proxifier для этого есть отдельные параметры.

Firefox

В Firefox разрешением имен при SOCKS5-подключении можно управлять отдельно. Начиная с версии 128, для SOCKS5 по умолчанию используется поиск на стороне прокси; раньше он был локальным. Сверьте выбранный протокол и DNS-параметр в своем профиле. Статья «Как настроить прокси в Mozilla Firefox: пошаговое руководство» поможет найти настройки подключения и исключения.

Proxifier

В Proxifier 4 для Windows автоматический режим учитывает доступность системного DNS. Если тот недоступен, программа может включить разрешение через прокси. На результат также влияют правила для отдельных имен. Проверьте текущий режим, а не только адрес сервера; расположение нужных разделов показано в статье «Как настроить прокси-сервер в Proxifier: пошаговое руководство».

Почему после включения прокси остаются DNS-запросы?

Устройству может понадобиться адрес самого прокси. Например, в настройках указан proxy.example: прежде чем подключиться, приложение должно узнать его IP. Такой запрос еще ничего не говорит о том, как оно нашло shop.example.

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

Как проверить DNS после настройки прокси?

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

Дополнительная проверка в браузере

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

1. Откройте инструмент в том профиле браузера, где настроен прокси и выполняется ваша задача.
2. Выполните проверку и дождитесь результата. Для повторного запуска на показанном экране есть кнопка «Повторить тест».
3. Посмотрите карточку внешнего IP и блок «DNS серверы». Если состав найденных серверов отличается от ожидаемого, вернитесь к настройкам DNS и исключениям в этом профиле.

В примере адреса скрыты, поэтому кадр показывает расположение полей, а не принадлежность конкретных серверов. Отметка «Защищено» относится к оценке самого инструмента.

Разбор конкретного запроса

Выберите один сайт и одну программу. Запишите адрес прокси, выбранный DNS-режим и исключения для прямого подключения. Затем сопоставьте три наблюдения:

• Соединение: приложение обратилось к прокси или напрямую к сайту?
• Назначение: прокси получил имя сайта или готовый IP?
• DNS-запрос: есть ли на устройстве запись о поиске именно этого имени?

Первые два пункта проверяйте по журналам клиента или прокси, если у вас есть к ним доступ. Третий – по записям DNS-запросов на устройстве. Если нужных записей нет, результат браузерного теста их не заменит.

Учитывайте кэш и DNS over HTTPS. Если адрес уже сохранен или запрос ушел по HTTPS, отсутствие обычного DNS-пакета само по себе не доказывает поиск через прокси. Для HTTP-клиента также важно различать предварительный поиск и назначение, которое он затем передал серверу.

Пример: внутренний сайт открывается только напрямую

Следующие два сценария условные. Они объясняют возможный сбой, а не описывают тестирование MangoProxy.

Предположим, intranet.example известен только корпоративному DNS. При прямом подключении браузер получает адрес, и страница открывается. Через SOCKS5 он передает домен прокси, но внешний резолвер не находит это имя.

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

Пример: Chrome открывает сайт, а curl – нет

Chrome и curl настроены на один SOCKS5-сервер. Браузер отправляет ему имя сайта, а curl со схемой socks5:// ищет адрес локально. Если DNS-служба клиента не знает домен, скрипт завершится ошибкой еще до подключения прокси к сайту.

Посмотрите, какое имя указано в ошибке: целевого сайта или самого сервера. Если сбой связан с локальным поиском имени сайта, а нужен поиск на стороне прокси, в curl для этого предусмотрена схема socks5h://.

Что сделать дальше

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

Если для вашей задачи также нужен постоянный внешний IP, можно рассмотреть статические датацентровые прокси MangoProxy с подключением по HTTP(S) или SOCKS5. Место DNS-разрешения при этом по-прежнему зависит от настроек приложения.

Глоссарий

DNS – система доменных имен. Доменное имя – текстовое имя ресурса, например shop.example. Поиск IP-адреса для этого имени называют DNS-разрешением.

IP-адрес – сетевой адрес устройства или сервера. Внешний IP в браузерном тесте – адрес, с которого инструмент получил обращение.

Клиент – приложение, которое подключается к прокси и передает ему запрос.

Резолвер – служба, которая обрабатывает DNS-запросы и возвращает ответ. При локальном разрешении поиск организует клиент, при удаленном – сторона прокси.

HTTP и HTTPS – протоколы обмена веб-запросами и ответами; HTTPS защищает соединение с сайтом шифрованием.

SOCKS5 – протокол, по которому клиент просит прокси установить соединение с нужным назначением.

CONNECT – команда HTTP, которой приложение просит прокси открыть соединение с указанным узлом и портом. Созданный канал называют туннелем.

Порт – номер, который помогает направить сетевое соединение нужной службе на устройстве.

DNS over HTTPS – передача DNS-запросов по HTTPS. Само шифрование не определяет, проходит ли это соединение через прокси.

Утечка DNS – запрос имени через DNS-службу или соединение, которые вы не планировали использовать для этой задачи.

Кэш – сохраненные ответы, которые приложение может использовать без нового запроса.

Профиль браузера – отдельный набор его настроек и данных.

Статические датацентровые прокси – прокси с постоянными IP-адресами из сетей датацентров.

Итог

Сначала определите, какой DNS-службе известно нужное имя и какие запросы допустимы в вашей сети. Затем выберите поддерживаемый приложением режим и проверьте результат. Оценивайте отдельно две вещи: удалось ли получить адрес сайта и может ли прокси установить с ним соединение.

Часто задаваемые вопросы

Здесь мы ответили на самые часто задаваемые вопросы. Все равно не можешь найти ответа?

Задать вопрос

Достаточно ли сменить DNS-сервер в системе, чтобы имя сайта разрешал прокси?

Нет. Так вы меняете службу, к которой может обращаться устройство. Чтобы поиск выполнили на стороне прокси, приложение должно передать ему доменное имя.

Что произойдет, если передать прокси готовый IP?

Для этого назначения ему не нужно искать адрес по имени. Клиент мог разрешить домен раньше или получить IP из настроек. Если адрес введен вручную, DNS-запроса об этом сайте могло не быть вовсе.