Автоматическое обнаружение прокси-сервера
В ходе автоматического обнаружения прокси-сервера система определяет сервер веб-прокси, который используется для отправки запросов от имени клиента. Эта функция также называется автообнаружением веб-прокси (WPAD). Если автоматическое обнаружение прокси-сервера включено, система пытается обнаружить скрипт конфигурации прокси-сервера, возвращающий набор прокси-серверов, который можно использовать для обработки запросов. Если такой скрипт обнаружен, он скачивается, компилируется и запускается на локальном компьютере при получении информации о прокси-сервере, потока запроса или ответа для запроса, который использует экземпляр WebProxy.
Автоматическое обнаружение прокси-сервера реализуется с помощью класса WebProxy. Параметры этого процесса могут задаваться на уровне запроса, в файлах конфигурации, а также в диалоговом окне Локальная сеть (LAN) браузера Internet Explorer.
Чтобы открыть диалоговое окно Параметры локальной сети Internet Explorer, выберите Сервис в главном меню этого браузера, а затем пункт Свойства браузера. Перейдите на вкладку Подключения и выберите Параметры локальной сети.
Если автоматическое обнаружение прокси-сервера включено, класс WebProxy пытается найти скрипт конфигурации прокси-сервера следующим образом:
Функция WinINet InternetQueryOption используется для поиска скрипта конфигурации прокси-сервера, который был обнаружен браузером Internet Explorer в последний раз.
Если найти этот скрипт не удается, класс WebProxy использует для его поиска протокола DHCP. DHCP-сервер может вернуть в ответе расположение (имя узла) скрипта или полный URL-адрес скрипта.
Если с помощью DHCP не удалось определить узел автообнаружения веб-прокси (WPAD), выполняется запрос узла DNS, в качестве имени или псевдонима которого используется WPAD.
Если обнаружить узел не удается и расположение скрипта конфигурации прокси-сервера задается в файле конфигурации или параметрах локальной сети браузера Internet Explorer, используется это расположение.
Приложения, выполняемые как службы NT или в составе ASP.NET, используют параметры прокси-сервера, задаваемые Internet Explorer (если доступны), вызывающего пользователя. Эти параметры могут быть доступны не для всех приложений службы.
Прокси-серверы настраиваются отдельно для каждого устройства подключения. Устройство подключения — это элемент в диалоговом окне сетевого подключения, который может быть как физическим сетевым устройством (модем или плата Ethernet), так и виртуальным интерфейсом (например, VPN-подключение, работающее через сетевое устройство). При изменении устройства подключения (например, при смене точки доступа для беспроводного подключения или включении VPN) алгоритм обнаружения прокси-сервера запускается снова.
По умолчанию для обнаружения прокси-сервера используются параметры прокси, задаваемые браузером Internet Explorer. Если приложение выполняется под учетной записью, не являющейся интерактивной (не поддерживает удобный способ настройки параметров прокси-сервера в Internet Explorer), или требуется использовать другие параметры прокси-сервера, вы можете настроить собственный прокси-сервер, создав файл конфигурации, в котором определены элементы (параметры сети) и
Для создаваемых вами запросов можно отключить автоматическое обнаружение прокси-сервера на уровне запроса, указав в нем Proxy NULL, как показано в следующем примере.
Для обработки запросов, не указывающих прокси-сервер, используется прокси-сервер по умолчанию домена приложения, который доступен в свойстве DefaultWebProxy.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
WPAD или автоматическая настройка параметров прокси
Прежде всего немного теории. Давайте разберемся, как работает протокол и какие сетевые службы нужны для этого.
Автоматическая настройка системы на работу с прокси-сервером производится специальным набором инструкций на JavaScript, который называется PAC-файл (Proxy Auto Configuration), для нахождения его расположения в локальной сети используется протокол WPAD (Web Proxy Auto-Discovery Protocol).
Рассмотрим следующую схему:
Получив запрос от пользователя браузер пытается найти расположение PAC-скрипта используя различные сетевые механизмы. В первую очередь отправляется DHCP-запрос, ответ на который должен содержать URL PAC-файла в специальном поле ответа, для этого используется опция 252 протокола DHCP.
Если в ответе DHCP-сервера искомый адрес не найден, то посылается DNS-запрос для хоста wpad в текущем домене. Некоторые браузеры, например, Firefox, не используют DHCP-запросы, а сразу обращаются к DNS. С механизмом поиска службы WPAD через DNS связана одна серьезная уязвимость. Если в текущем домене хост с именем wpad не найден, то поиск будет произведен в вышестоящем домене, при этом выход за пределы домена организации никак не контролируется.
Что это значит? Допустим клиент расположен в домене office.spb.example.com, то поочередно будет произведен поиск следующих хостов:
Пользуясь этим, злоумышленники могут расположить PAC-файл по адресу за пределами домена предприятия и направить весь трафик на свои прокси сервера, в том числе и зашифрованный, в отношении которого можно осуществить атаку типа «человек посередине» с подменой сертификата.
В связи с этим DNS-сервер от Microsoft начиная с Windows Server 2008 содержит хост wpad в черном списке и не разрешает данное имя, даже если соответствующая запись на данном сервере существует.
В среде OC Windows, если предыдущие попытки не принесли результата, производится поиск хоста WPAD на WINS-сервере и посредством широковещательных протоколов LLMNR ( Link-Local Multicast Name Resolution) и NBNS (NetBIOS Name Service).
Поэтому, если данный веб-сервер использует виртуальные хосты, хост wpad должен являться хостом по умолчанию (или корневым хостом), т.е. его содержимое должно отдаваться при обращении к данному серверу без указания имени хоста, просто по IP-адресу.
Также, в целях безопасности, PAC-файл не должен быть доступен за пределами локальной сети.
PAC-файл
Как мы уже упоминали, PAC-файл является JavaScript-скриптом, однако количество инструкций в нем жестко ограничено. Разберем некоторые из них.
Этих инструкций вполне достаточно, чтобы составить достаточно подробные и разветвленные правила для работы с прокси-сервером. Попробуем составить реальный сценарий.
Прежде всего укажем функцию:
Данная функция получает от браузера URL и host из запроса и в ответ должна вернуть адрес прокси-сервера. Внутри фигурных скобок следует располагать инструкции и условия, в зависимости от выполнения которых браузеру будет возвращен тот или иной результат.
Начнем с того, что не следует направлять на прокси. Прежде всего это «плоские» имена, когда к какому-либо ресурсу пытаются обратиться по короткому имени, например, http://server, так как это однозначно ресурс локальной сети.
Согласно данной записи, если в поле host запроса содержится «плоское» имя, то возвращаем браузеру директиву DIRECT, что означает, что прокси-сервер для этого соединения использовать не следует.
Таким же образом предписываем обращаться напрямую по запросам с IP-адресами локальной сети:
И локальным адресам:
Кстати, первое правило можно переписать по-другому:
В доменной сети также следует настроить прямое соединение для внутренних ресурсов:
Аналогичным образом можно направить мимо прокси какие-либо критичные внешние ресурсы, например, интернет-банки или площадки электронных торгов.
Если ваш прокси не обрабатывает https запросы, то их тоже следует направить мимо, обратите внимание, что вместо host в данном правиле мы используем url:
Тоже самое следует сделать и для ftp запросов:
И наконец все, что не попало ни под одно правило отправляем на прокси:
Разобравшись с тем, как устроен PAC-файл перейдем к сценариям практической реализации служб WPAD в сети.
Сети Active Directory
Так как все наши статьи преемственны, то далее будет подразумеваться что WPAD настраивается для работы с роутером в сети Active Directory, описанного нами в цикле Настраиваем Squid для работы с Active Directory, таким образом данный материал может служить его логическим завершением.
Начнем с настройки DHCP, откроем соответствующую оснастку и перейдем к списку серверов, щелкните правой кнопкой мыши на пункт IPv4 и выберите Предопределенные параметры.
В открывшемся окне нажмите Добавить
И заполните поля следующим образом:
Если в вашей сети более одного DHCP-сервера, то аналогичные настройки нужно выполнить на каждом их них.
Следующим шагом будет настройка DNS, прежде всего откорректируем черный список, для этого на DNS-сервере откроем редактор реестра и перейдем в раздел:
Откроем опцию GlobalQueryBlockList и удалим оттуда значение wpad, после чего службу DNS нужно перезапустить.
Данную операцию следует выполнить на каждом DNS-сервере в вашей сети.
Затем добавьте запись типа A для хоста wpad, которая должна указывать на веб-сервер с PAC-файлом.
Закончив настройки DHCP и DNS следует наконец установить на выбранный хост веб-сервер и разместить на нем wpad.dat. Никаких ограничений здесь нет, вы можете настроить любой веб-сервер на любом узле сети. В нашем случае напрашиваются два варианта: веб-сервер непосредственно на роутере, мы рекомендуем для этих целей простой и легкий lighttpd или веб-сервер на одном из контроллеров домена, в этом случае предпочтение следует отдать IIS.
В данной части статьи мы рассмотрим вариант с IIS, а к lighttpd вернемся чуть позже, когда будем говорить об одноранговых сетях. Мы не будем подробно останавливаться на установке роли Веб-сервер (IIS), достаточно просто пройти все шаги мастера со значениями по умолчанию.
Для правильной работы с PAC-файлом добавьте новый тип MIME, указав расширение .dat и тип MIME application/x-ns-proxy-autoconfig.
Выполнив данную настройку не забудьте перезапустить веб-сервер и разместите в его корневой директории C:\inetpub\wwwroot файл wpad.dat.
Браузеры на основе Google Chrome (в т.ч. Opera, Яндекс) используют настройки, заданные для IE. Проблемы, как всегда, возникают с Firefox, который с настройкой по умолчанию Использовать системные настройки прокси игнорирует их и ходит напрямую, поэтому данную опцию следует изменить на Автоматически определять настройки прокси для этой сети.
Одноранговая сеть
Одноранговая сетьВ одноранговых сетях обычно применяются прозрачные прокси, не требующие настройки параметров браузера, однако в ряде случаев, например, для аутентификации, от прозрачности приходится отказываться, следовательно, возникает потребность в WPAD. Далее мы будем рассматривать настройку на примере роутера, настроенного по нашей статье: Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3.
Так как в большинстве случаев лишних серверов в небольших сетях нет, то все службы будем располагать в пределах роутера. DHCP и кэширующий DNS у нас уже есть, в виде пакета dnsmasq, а в качестве веб-сервера можно установить легковесный lighttpd. На первый взгляд все необходимое имеется и особых проблем возникнуть не должно.
Чтобы убедиться в этом, следует проверить DNS-суффикс текущего подключения. Для этого в консоли PowerShell выполните команду:
Ниже показан вывод команды для одноранговой и доменной сетей, разница в отсутствии DNS-суффикса отлично видна «невооруженным глазом».
Если все оставить как есть, то тот же Firefox не сможет получить настройки прокси и будет требовать ручного ввода параметров. Что делать? К счастью в протоколе DHCP есть опция 015, позволяющая передавать клиенту DNS-суффикс подключения.
Откроем /etc/dnsmasq.conf и последовательно изменим в нем следующие опции:
DNS-имя домена, передаваемое клиенту в опции 015 DHCP.
Задает расположение PAC-файла.
Теперь заново получим IP-адрес и снова проверим DNS-суффикс, также можно попробовать разрешить любое плоское имя (существующего хоста) командой nslookup.
Установим lighttpd:
Затем откроем его конфигурационный файл /etc/lighttpd/lighttpd.conf и добавим туда опцию:
Это ограничит работу веб-сервера только локальной сетью.
После чего следует убедиться, что в файле /etc/mime.types присутствует запись:
Если такой записи нет, то ее следует добавить.
На этом настройка сервера закончена, осталось разместить PAC-файл в директории /var/www и проверить работу браузеров.
Поскольку одноранговая сеть не предоставляет таких возможностей по управлению клиентскими ПК как ActiveDirectory, то следует предпринять меры по предотвращению обхода прокси. Это можно сделать через iptables, запретив форвардинг пакетов с назначением на 80-й порт. Но лучше поступить иначе.
В /etc/nat добавим следующее правило:
Данная конструкция перенаправит все запросы к веб-серверам или сторонним прокси на порт 80 нашего роутера, где работает собственный веб-сервер.
В конфигурацию lighttpd добавим опцию (не забудьте перезапустить веб-сервер):
Теперь в /var/www создадим файл index.html со следующим содержимым:
После чего при попытке обхода прокси пользователь увидит сообщение:
В качестве примера мы привели самый простой вариант странички запрета, вам же ничего не мешает сделать ее более информативной, например, разместив на ней краткие инструкции по самостоятельной настройке браузера.
Если вам нужно разрешить работу с некоторыми сайтами напрямую, минуя прокси, то перед запрещающим правилом добавьте:
Как видим, настроить автоматическое получение параметров прокси совсем несложно и можно эффективно применять данную технологию как в крупных, так и в небольших сетях.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Windows не удалось автоматически обнаружить параметры прокси этой сети
Количество разных ошибок в Windows конечно же поражает. Я уже написал инструкции с решениями большинства популярных ошибок, которые связаны с подключением к интернету. Но как оказалось, об ошибке «Windows не удалось автоматически обнаружить параметры прокси этой сети» я еще не рассказывал. Поэтому решил подготовить небольшую инструкции с несколькими решениями, которые помогут избавится от этой проблемы в Windows 10, Windows 8 и Windows 7.
Саму ошибку с текстом «Windows не удалось автоматически обнаружить параметры прокси этой сети» можно увидеть запустив диагностику неполадок при возникновении проблем с подключением к интернету. Когда подключение пропадает, а возле иконки появляется желтый восклицательный знак. Бывают так же случаи, когда эта ошибка появляется в то время, когда интернет по Wi-Fi, или по кабелю нормально работает. Выглядит она вот так:
Есть несколько проверенных решений, которые работают во всех версиях Windows. Сейчас я о них расскажу.
Но для начала:
Возможно, простая перезагрузка устройств решит проблему. Если нет, следуем инструкции.
Решение ошибки с обнаружением прокси в Windows 7 и Windows 8
Сначала я советую сделать сброс сетевых настроек, а затем проверить настройки прокси-сервера.
1 Сброс настроек сети. Нам нужно запустить командную строку от имени администратора. Для этого в меню «Пуск», в строке поиска напишите cmd. В результатах поиска нажмите на командную строку правой кнопкой мыши и выберите «Запуск от имени администратора». В Windows 8 можно найти и запустить ее через поиск.
Дальше копируем, и по очереди выполняем такие команды:
Должно получится вот так:
Перезагрузите свой компьютер, или ноутбук и проверьте решена ли проблема. Если это не помогло, есть еще один способ.
2 Проверяем настройки прокси-сервера. Для этого зайдите в панель управления, переключите отображение иконок на «Крупные значки» и запустите «Свойства образователя». В Windows 8 эти настройки можно еще найти по запросу «Свойства браузера» (настройка прокси-сервера) через поиск.
В новом окне нажмите на кнопку «Настройка сети», и проверьте, чтобы были убраны все галочки кроме «Автоматическое определение параметров». Вот так:
Думаю, запустив после этого диагностику сетей Windows ошибка не появится.
Проблема с автоматическим обнаружением параметров прокси в Windows 10
Для решения этой ошибки в Windows 10 можно использовать те же советы, о которых я писал выше. Но так как интерфейс и настройки в «десятке» немного изменились, все эти действия можно выполнить другим способом.
Дальше просто нажимаем на «Сбросить сейчас».
2 Чтобы проверить, нет ли ненужных настроек в свойствах прокси-сервера, нужно снова же зайти в параметры, в раздел «Сеть и Интернет» на вкладку «Прокси». Проверьте, чтобы там все было отключено, кроме одного пункта. Как на скриншоте:
Если вам удалось решить эту проблему, то обязательно напишите в комментариях, какой способ вам помог. Всего хорошего!
Мне тоже помогла последняя галка. Но… Помогла только избавиться от ошибки «Не удалось автоматически обнаружить прокси…». Но теперь при проверке появляется сообщение о том, что у меня проблемы с роутером (скриншот не сделала). Но у меня от этого роутера куча устройств прекрасно работает, включая допотопный ноут, планшеты и телефоны разных моделей и систем.
Эта ошибка появляется при запуске диагностики неполадок? Как компьютер к роутеру подключен? Какой статус подключения на компьютере?
Спасибо. Провел Сброс сети через параметры. все заработало.
Перепробовал все способы но помог лишь один сброс сети.Спасибо огромное автору.
Так же, Сброс настроек сети помог! Спасибо.
Спасибо, помогло)) а я уже начал кричать на сотрудников (ссылка на сайт с арендой прокси) что прокся не пашет)) вынес весь мозг им. А проблема вот в чём была. Автору респект!
ааа, спасибо тебе большое, 2 дня искал решения и вот, ОГРОМНОЕ СПАСИБО
Ничего не помогло,сделал все пункты
Была та же проблема. Поменяла роутер, не помогло. Все решилось звонком на тех.поддержку и изменений настроек на самом роутере.
Спасибо большое. Помог сброс сети настроек
Ничего не помогло. Кнопка «Сохранить» не активна при включении «Определять параметры автоматически». Параметр «Вкл.» не сохраняется.
Можете скриншот прикрепить? Не понял о чем вы пишете.
Когда нажимаю на кнопку Сохранить, позиция Вкл. не сохраняется
У меня так же. Не нужно сохранять. Кнопка «Сохранить» там нужна для сохранения адреса сценария.
Так у меня все время Определять параметры автоматически, все время ВЫКЛЮЧЕНО. Не включается.
Включаешь. Выходишь. Заходишь заново — Выключено.
Может какая-то программа меняет настройки. VPN установлен?
VPN есть, но выключен.
Так программа все равно может менять сетевые настройки. У вас ошибка как в статье? Может причина в другом. Нужно больше информации.
Ошибка, как в статье: «Windows не удалось автоматически обнаружить параметры прокси этой сети».
VPN удалил. Перезагрузил. Ничего не изменилось.
Проделал все действия, описанные в этой статье.
На втором способе «Проверяем настройки прокси-сервера»
Галочку «Автоматическое определение параметров» тоже убери.
Автору спасибо за статью!
Сергей здравствуйте! После всех манипуляций ошибка ушла, но я не могу зайти в браузеры, пишет что невозможно установить безопасное соединение
Пожалуйста, опишите проблему более подробно.
Да не стоит там галочка, И не устанавливается.
Комп подключен напрямую, не помог ни один способ
Если я выполню сброс сети то настройки собьются и на компьютере и на роутере?
Если вы сделаете сброс сети на компьютере, то настройки будут сброшены только на компьютере.
У меня такая проблема,пользуюсь модемом подключённым к роутеру и к всему этому от роутера идёт кабель к компьютеру,перестал работать интернет я перезапустил роутер и модем всё нормально,заработало везде кроме как у компьютера,то есть вай фай раздаёт интернет,а подключения через кабель к компьютеру не идёт,проблема не в компьютере так как подключал кабель и к ноутбуку,всё тоже самое,перепробовал уже всё что только можно,и кабель менял и миллионы раз перезапускал модем с роутером,ничего не помогает.
Какой статус подключения на компьютере после подключения кабеля? Он как-то меняется?
На роутере индикатор LAN загорается?
без кабеля «нет подключения, вы не подключены ни к одной сети.
с кабелем «без доступа к интернету»
да индикатор Lan горит
Но подключение устанавливается. Попробуйте прописать в свойствах подключения по локальной сети (Ethernet) DNS по этой инструкции.
Увы не помогло,есть ещё какие то варианты решения моей проблемы?Буду премного благодарен.
Ничего больше не могу подсказать. Очень странная проблема. Если действительно по Wi-Fi все раздает, то и по кабелю должно работать. Нужно смотреть оборудование.
Просто спас, 1ый вариант помог в Windows 7.
Спасибо большое
Поверьте-эту проблему можно решить только скачав самому драйвер нужного адаптера с официального сайта производителя. Установить его. Перезагрузить ноутбук. И проблемы не будет.
Спасибо за статью, полезно и помогательно!
Прочитал статью. Вроде бы все подходит под описание, но проблема осталась. Опишу полностью. Был роутер zycel keneetic lite 1 и недавно поненял на новый кинетик модели 1311 из-за зависания первого и больше не растормаживался. Роутер настроился быстро и подключился к провайдеру, но пк подключения не видел. При диагностике давал ошибку определения прокси сети. Подключение происходило только после отключения/включения сетевого контроллера и сразу появлялся доступ в Интернет, браузеры работают. Как только перезагружаешь пк все снова начинается с ошибки прокси. Самое интересное все выше описанные действия проводил и без результата. Но заметил что при выборе протокола ip4 и отключении протокола ip6 в свойствах — роутер определяется и ошибка уходит и при перезагрузке пк не выскакивает, но выхода в интернет нет и браузеры не загружают страницы. Заходим в свойства контроллера выставляем галку протокола ip6 и все работает. В состоянии пишет по ip4 интернет,а по ip6 без доступа интернет, но страницы грузятся. Делаем перезагрузку и все по обоим протоколам в состоянии — пишет без доступа. И опять неопозная сеть. Круг замыкается. Как исправить все это безобразие- подскажите. На старом роутере вообще проблем небыло при тех же настройках пк.
А прокси отключены? Я бы начал со сброса сетевых настроек и переустановки драйвера сетевой карты. Или просто удалить сетевой адаптер с диспетчера устройств и перезагрузить компьютер.