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


20

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

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

Любая обратная связь будет наиболее ценной.

Ответы:


21

Не совсем: это зависит от того, как настроен клиент. Давайте использовать 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)

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

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

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

    а. либо «DIRECT» , в этом случае клиенту необходимо разрешить само имя и подключиться напрямую, как в случае обхода выше

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

    • В качестве примера : если функция сценария вернула «PROXY yourProxy: 8080; DIRECT», который говорит клиенту подключиться к вашему прокси через TCP-порт 8080, чтобы запросить этот URL, и если это соединение не может быть установлено, попробуйте перейти напрямую. Обратите внимание, что сбой настройки сеанса TCP не совсем быстрый, так что это вряд ли будет приятным переключением при сбое для пользователя, но ничего не сравнится. Может быть.

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

WinSock Proxy / ISA Firewall Client / TMG Client :

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

Клиенты могут быть действительно Clingy:

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

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

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

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

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

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


Существует ли стандарт или часть RFC, в котором говорится, что клиенты не должны выполнять разрешение DNS перед подключением через прокси-сервер?
Уилер

Просто условность и / или эффективность, насколько я понимаю. Старый Microsoft Winsock Proxy Client использовался, чтобы позволить вам играть с опциями разрешения имен. И ничто не помешает вам написать PAC, который выполняет разрешение имен, а затем использует прокси-сервер ... это просто не так, как это было сначала.
TristanK

0

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


Я знаю, что клиент веб-прокси ISA Server использует DNS-сервер ISA для разрешения адресов назначения, но я почти уверен, что базовый HTTP-прокси, заданный в параметрах Интернета на машине с XP / Win7, разрешается, как указано выше ...
orange_aurelius

... и упс. Я только что сделал тест, который показал себя неправильно, по крайней мере, в IE. Итак, я думаю, что мой следующий вопрос будет, как тогда разрешается DNS для адресов, которые находятся в списке исключений прокси? Может быть, пришло время вытащить сниффер.
orange_aurelius

0

Я пытаюсь в 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-имя


0

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.