Назад | Перейти на главную страницу

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

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

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

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

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

    Бонусный факт: это использование FQDN в 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)

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

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

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

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

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

    а. либо "НЕПОСРЕДСТВЕННЫЙ", и в этом случае клиенту необходимо разрешить само имя и подключиться напрямую, как описано выше в случае обхода.

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

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

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

Прокси WinSock / Клиент брандмауэра ISA / Клиент TMG:

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

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

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

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

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

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

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

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

Я пробую в 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-имя.

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

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

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