WPAD: инструкция по эксплуатации

[mikes]

Отключить автоматическое определение настроек в настройках всех браузеров (для IE и Chrome это можно сделать через доменные политики).

тогда конечно теряется часть функционала wpad :(

[z3apa3a]

Если требуется функционал wpad, то лучше всего прописать в настройках браузера или политикой URL сценария автоматической настройки.

[mikes]

да это то оно понятно, тут вопрос больше в том, что теряем именно функционал самостоятельного обнаружения. Тот случай когда клиент получает доступ сразу «из коробки» и не имеет проблем вне офисной сети когда wpad прописан. не очень хочется светить wpad.dat на весь мир то.

[z3apa3a]

Так не светите — на сервере по IP клиента отдавайте или WPAD для локальной сети или пустой, если запрос пришел снаружи.

[mikes]

идея хороша, спасибо за совет :)

[gotch]

В соответствии с RFC 2606 есть всего лишь 4 домена первого уровня для «левых» имен —
.test
.example
.invalid
.localhost

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

Так же не лишним будем подумать об отключении WPAD в групповой политике и включении DHCP опции 252 technet.microsoft.com/ru-ru/library/bb839043.aspx

[z3apa3a]

DHCP опция 252 скорее всего не решает проблемы, фактически она вообща мало на что влияет. Настройки WPAD не получаются одновременно с получением IP. В старых версиях Windows настройки WPAD запрашивались в Internet Explorer отдельным запросом DHCPINFORM при старте браузера, причем только если у пользователя были права администратора, в современных не уверен, что какой-либо браузер вообще ее поддерживает, хотя не проверял и могу ошибаться.

[cdump]

Про поддержку этой опции современными браузерами сказано верно, например в последних на момент исследования Firefox и Chrome эта dhcp опция не учитывалась

[VGusev2007]

Насколько я понял, IE, спрашивает эту настройку в DHCP. Если ограничиться просто DNS, то MS Office, proxy не подхватывает.

[naum]

Отличный пост, крутые изыскания, интересная плюха с пропуском поддомена. Интересно, как изменится ситуация на рынке wpad.* доменов в ближайшие дни.

[ValdikSS]

Кроме браузеров WPAD использует весь софт который использует WinHTTP API (как минимум windows update), по крайне мере пока не отключена служба которая только и занимается что автодетектом прокси.

Не только WPAD, но и сам PAC. И это страшно. Трафик к PAC-файлу антизапрета превышает трафик самого прокси. Я не шучу, 50000 человек способны генерировать по 20 Мбит/с. Неправильно написанные Wininet-приложения, которые, вероятно, создают каждый раз новый контекст для нового запроса, запрашивают PAC-файл каждый раз, совершая запрос!

Вот, полюбуйтесь: valdikss.org.ru/az-proxypac.webm. Приходится отдавать 403 на запросы без User-Agent.

[Bo0oM]

Прикольно)
А по редиректу они пойдут?))

[ValdikSS]

Не пробовал, но, думаю, пойдут.

[cdump]

Насколько я знаю оно в начале шлёт DHCP INFORM и требует опцию 252, и только если ответа нет или опции в ответе нет то начинается брожение где попало.

В реальности все не так хорошо с DHCP 252:
— в firefox это не поддерживается нигде.
— в Windows 7 это поддерживает только IE — см. DHCP WPAD findproxyforurl.com/browser-support

[gotch]

Есть еще такой старый сценарий:

Злоумышленник назначает рабочей станции имя wpad. Вводит в домен (используя привилегию ввести 10 рабочих станций). Автоматически появляется нужная запись в DNS. Profit.

Для этого еще в Windows Server 2008 сделали globalqueryblocklist (https://technet.microsoft.com/ru-ru/library/cc794902(v=ws.10).aspx). Добавить запись wpad можно, но DNS ее не будет разрешать. Но здесь появляется риск поднятия на домены верхнего уровня для поиска wpad.

[rvs2016]

Всем привет через 11 лет после публикации этой статьи!

Поддерживается ли кем-нибудь эта технология автонастройки конфигурации прокси в 2026-м году?

У меня такое впечатление, что браузеры (проверял в файрфоксе и в чроме) не используют wpad уж. Файл wpad.dat по нужному адресу не запрашивал у меня никто, кроме меня самого, руками во время проверки доступености этого файла и выдачи в нём с веб-сервера нужного содержимого браузерам, в качестве которых я для проверки использовал curl да lynx.

UPD:

Проверил сейчас использование wpad на мобилах на примере Андроида в Самсунге.

В настройках wifi-подключения вбил руками (ну ладно, не руками - копированием) адрес своего wpad.dat-файла и запрос к нему на сервер такие отправился.

Значит мобилы эту технологию применяют.

Но есть небольшая кручина - они не могут wpad.dat искать автоматически по правилам поиска этого файла. Пришлось вбивать url этого файла. Кручина, конечно. Ну да ладно. Это всё-равно лучше, чем незапрос wpat.dat-файла файрфоксом да чромом. Причём файрфоксу url указать нельзя. Он предоставляет возможность включения аатоматической настройки конфигурации прокси, но даёт вариант только полной автоматизации (т.е. включая и самостоятельный поиск wpad.dat-файла), а руками (как в wifi-свойствах мобилы) url этого wpad.dat-файла вписать в файрфокс (по кр. мере простыми юзерскими способами) нельзя. Может быть можно где-то в about:config, но это уже менее интересно искать, чем просто настроить так, как оно должно настраиваться нормально и по простому.

UPD2:

Продолжил проверку на мобиле:

Файрфокс не использует данные, которые возвращает из wpad.dat моя функция FindProxyForURL и гонит все запросы напрямую.

Самсунг интернет использует результат работы этой функции.

Остальные браузеры на мобиле не проверял, но надежда на то, что технология wpad в 2026-м году хоть где-то ещё жива, таки замаячила!

Заодно хоть в одном браузере проверил (хоть на мобиле), что функция FindProxyForURL мною написана без ошибок, работает правильно и верные результаты выдаёт. А то её попробуй протлаживай. Если загрузить просто так руками (например в отдельной html-странице) эту функцию в браузер, то в ней будут не доступны всякие служебные для wpda-технологии функции типа shExpMatch и т.п. Понятно, конечно, что не лыком шитые люди и штатные match-функции применят, но зачем, если дл wpad приготовлены спец-функции javascript.