Корпоративные альтернативы конфигурации прокси WPAD?
У нас более 40 сайтов в более чем 20 странах. Мы используем выходную фильтрацию и заставляем большинство пользователей через прокси-серверы через WPAD.
WPAD великолепен и работает для нас на 99,9%. Однако у нас было несколько случаев, когда из-за проблем с поддержкой WPAD браузеры (только MSIE - в редких случаях) или сторонние приложения (WebEX voip) не работали, так как они не могли правильно определить, где находится локальный прокси-сервер - попробуйте прямой - и не получится.
Так есть ли какие-либо другие механизмы, позволяющие предприятиям с множеством выходных точек / прокси поддерживать все браузеры (т.е. не только MSIE) и другие веб-клиенты, кроме WPAD? Как я уже говорил, WPAD на самом деле работает для нас на 99,9%, но проблема в том, что люди только "видят" сбои - и начинается гризли...
PS: нет, "использовать DHCP" - это не другой вариант. Это всего лишь альтернативный механизм доставки WPAD (основным из которых является DNS). Просто подумал, что я отвечу, прежде чем кто-то другой;-)
Спасибо
Джейсон
1 ответ
Ваш единственный выбор, о котором я знаю:
Настройте клиентское программное обеспечение так, чтобы оно "знало", где находится прокси-сервер "вручную". Вероятно, это проигрышная битва, так как вы не можете предвидеть все потенциальные клиентские программы. В итоге вы получаете кучу сценариев, слияния реестра, преобразования MSI и целую кучу клея и ленты для предварительной настройки клиентского программного обеспечения, а затем что-то новое проскальзывает под радаром и не работает.
Используйте стандартные механизмы автоматической настройки, такие как Windows Proxy Auto-Detect (WPAD). Как видите, это не на 100% надежно.
Используйте клиентскую "прокладку" в стек TCP/IP, такую как Microsoft Firewall Client для ISA Server. Единственный продукт, о котором я знаю, это продукт Microsoft ISA Server / Firewall Client. Это работает очень, очень хорошо, но в высшей степени запатентовано и специфично для Windows.
Используйте прозрачное аппаратное / программное обеспечение для проксирования, чтобы обеспечить передачу трафика. Во многих случаях это хорошо работает (например, используя ebtables в Linux, вы можете создать HTTP-прокси 2-го уровня, который будет полностью прозрачным для клиентов), но побочным эффектом будет предотвращение использования аутентификации HTTP-прокси (так как браузер / клиент не знает, что он проксируется - он не справится с этим должным образом).
Это сценарий типа "выбери свой яд".