☰

Как работают DNS-запросы при использовании HTTP-прокси (или без него) в IE

tag-icon • tag-icon domain-name-system proxy http
Как работают DNS-запросы при использовании HTTP-прокси (или без него) в IE

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

  1. Пользователь запрашивает сайт
  2. Клиент отправляет DNS-запрос на свой настроенный DNS-сервер для разрешения IP-адреса назначения (это делается в первую очередь для обработки HTTP-запросов, настроенных на обход прокси-сервера).
  3. После получения IP-адреса назначения от DNS и непосредственно перед отправкой HTTP-запроса запрос проверяется по списку исключений.
  4. Если сервер назначения не входит в список исключений, запрос пересылается на прокси-сервер.
  5. Если сервер назначения находится в списке исключений, запрос пересылается в соответствии с таблицей маршрутизации клиентского компьютера.

Мы будем очень признательны за любые отзывы.

решение1

Не совсем: это зависит от того, как настроен клиент. Давайте используем IE в качестве базового примера.

Если вы настроите IE с помощьюявныйпрокси:например, не отмечено никаких других опций, прокси-сервер установлен на что-то вроде 8080.

  1. Пользователь вводит адрес

  2. IE проверяет адрес на наличиесоответствие строки списку исключений прокси-сервера IE(т.е. «Обойти прокси для этих адресов:»)

    а.Если он соответствует записи вОбходсписок,клиентиспользуетсвой собственный DNSчтобы разрешить имя, а затемклиент подключается напрямую к целевому IP-адресуна порту 80 (предположительно), затем отправляет запрос вида:

    GET /something.htm HTTP/1.1
    Host: fulldomainame.example.com

    б.Если ни одна запись в списке обхода не совпадает, продолжать:

  3. IE подключается к настроенному прокси-серверу, и отправляет запрос вида:

    GET http://fulldomainname.example.com/something.htm HTTP/1.1

    Бонусный факт: это использованиеПолное доменное имя в URL-адресеэто один из способов узнать, что клиентдумаетон общается с прокси-сервером вместо настоящего веб-сервера

  4. Прокси-сервер разрешает это имя хостас использованиемсвой собственныйDNS, а затем подключается к целевому сайту (действует как клиент на шаге 2 выше) и т. д. и т. п.

При использовании WPAD/PAC:

В случае использования скрипта автоматического обнаружения веб-прокси (WPAD) или автоматической настройки прокси (PAC или Autoconfig), например, предоставляемых ISA/TMG при включенной автоматической настройке, все по-другому:

  1. Пользователь вводит адрес

  2. Клиентзагрузкиэлектрический токwpad.dat/autoproxy.js/.pacфайл из настроенного расположения

  3. Клиент ищет функцию "FindProxyForUrl" в js-файле и выполняет его

  4. Скрипт Autoproxy обрабатываетимя хостаиURL. Это файл JavaScript с ограниченными функциями, но многое все еще возможно:

    а. это может включать в себяразрешение имени(IsInNet, DNSResolve)

    б. это может включатьсопоставление строк(ShExpMatch)

    в. это может включатьсчитаем до миллиона(я++)

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

    • (или просто смешно)
    • ((или отладка))

  5. TheFindProxyForUrlфункция возвращает как минимум одну строку: упорядоченный список лучших прокси-серверов для использования (разделенные точкой с запятой)

    а. либо"ПРЯМОЙ", в этом случае клиенту необходимо самостоятельно разрешить имя и подключиться напрямую, как в случае обхода выше

    б. или"PROXY имя_прокси:8080"или что-то подобное, в этом случае клиент подключается к этому порту на этом прокси-сервере, сообщает емуПОЛУЧИТЬ полный URL, ипрокси выполняет разрешение имен.

    • Какпример: если функция скрипта вернула"ПРОКСИ вашПрокси:8080;ПРЯМОЙ"который сообщает клиенту о необходимости подключения квашпроксина TCP-порту8080чтобы запросить этот URL, и есличтоНевозможно установить соединение, попробуйте подключиться напрямую. Примечаниечто сбой настройки сеанса TCP происходит не совсем быстро, так что это вряд ли будет приятным опытом переключения при сбое для пользователя, но это ничто. Может быть.

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

WinSock Proxy / Клиент брандмауэра ISA / Клиент TMG:

Если вас интересует Winsock Proxy Client (от TMG/ISA Server), то это уже другая история, с большей гибкостью и подвижными частями. Слишком много, чтобы вдаваться в подробности, но есть документы, описывающие, как это работает. Короче говоря: он подключается к сокетам Windows и может перехватывать как трафик на основе TCP/UDP, так и запросы на разрешение имен на уровне приложения и пользователя. Очень мощный, но также устарел и не обновлялся несколько лет.

Клиенты могут быть очень навязчивыми:

Одинзаключительная заметка: Как только HTTP-клиент решил обратиться к прокси-серверу для определенного сайта/URL,у прокси-сервера нет возможности запретить это.

Нет кода статуса HTTP или заголовка для «Я это не обслуживаю, вам следует просто перейти к этому месту»...

Как только клиент решает, что определенный URL-адрес обслуживается через прокси-сервер,прокси-смертельная хватканаступает.

Единственный способ избежать этого — реализовать логику выбора непосредственно перед тем, как клиент установит соединение, в списке PAC или Bypass.

Последнее замечание о зонах и файлах PAC

IE обрабатывает сайты, которыеПРЯМОЙподключены - даже если в URL есть точки - к зоне локальной интрасети (по умолчанию - настраивается в свойствах зоны), и поэтому будут делать такие вещи, как разрешить встроенную проверку подлинности Windows для этих сайтов (т. е. аутентификацию Kerberos и/или NTLM, прозрачно). Таким образом, контроль того, находится ли что-либо в зоне локальной интрасети, определяет, насколько оно доверено с точки зрения автоматической аутентификации. Опять же, по крайней мере, по умолчанию.

решение2

Я не уверен, что ваша часть DNS верна. Я видел, как машина без действительных DNS-серверов прекрасно получала страницы в IE, используя прокси.

решение3

Я пробую в Ubuntu 10.04, Wine, IE 6.0 и Squid 2.7 (в системе один DNS-сервер, а в Squid другой DNS-сервер)

  1. Пользователь отправляет запросы на прокси-сервер
  2. Squid отправляет DNS-запрос на DNS-сервер
  3. Squid получает ответ DNS. Если nxdomain или другая ошибка, отправить страницу ошибки в IE. Если имя разрешено, получить страницу и передать ее в IE.

IE 6.0 не разрешает DNS-имя.

решение4

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

Вполне возможно, что proxy.pac/wpad.dat позволит вам принудительно выйти из этого поведения.

Связанный контент