Имея уже сконфигурированный и работающий сервер Squid3 у нас встаёт вопрос об автоматической настройке клиентов локальной сети на использование этого прокси-сервера. Сразу перенаправлять всех клиентов на только что запущенный прокси-сервер не совсем правильно, и поэтому нам сначала потребуется выполнить предварительное тестирование на отдельной группе клиентов, а уже по результатам этого тестирования выполнить плавный перевод всех оставшихся клиентов со старого прокси-сервера на базе Forefront TMG на новый на базе Squid3. Правила того, каких клиентов на какой прокси-сервер направлять мы настроим в файле wpad.dat используемом браузерами и другими приложениями на клиентских компьютерах в рамках технологии Web Proxy Automatic Discovery (WPAD). А так как файл wpad.dat нужно сделать для всех клиентов локальной сети доступным по протоколу HTTP без аутентификации, развернём для этой цели на нашем Linux-сервере веб-сервер Apache2.
Устанавливаем веб-сервер Apache2
Установим Apache2 и php5 (php понадобится нам в одной из следующих частей описания):
sudo apt-get install apache2 libapache2-mod-php5 ... The following NEW packages will be installed: apache2 apache2-bin apache2-data libapache2-mod-php5 libapr1 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap php5-cli php5-common php5-json php5-readline 0 upgraded, 12 newly installed, 0 to remove and 0 not upgraded. Need to get 6,127 kB of archives. After this operation, 25.7 MB of additional disk space will be used. Do you want to continue? [Y/n] Y ...
После завершения установки открываем на редактирование конфигурационный файл сетевых настроек Apache2 /etc/apache2/ports.conf (этот файл включен для обработки по умолчанию в основной конфигурационный файл Apache2 - /etc/apache2/apache2.conf) и меняем настройки параметра Listen таким образом, чтобы порты веб-сервера (80/443) прослушивались только на стороне интерфейса локальной сети:
# If you just change the port or add more ports here, you will likely also # have to change the VirtualHost statement in # /etc/apache2/sites-enabled/000-default.conf Listen 10.160.0.2:80 <IfModule ssl_module> Listen 10.160.0.2:443 </IfModule> <IfModule mod_gnutls.c> Listen 10.160.0.2:443 </IfModule> # vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Перезапускаем веб-сервер и убеждаемся в том что TCP-прослушиватель доступен только на интерфейсе локальной сети:
sudo invoke-rc.d apache2 restart sudo ss -lntu | grep :80 tcp LISTEN 0 128 10.160.0.2:80 *:*
Создаём файл авто-конфигурации прокси wpad.dat
Создадим в корневом каталоге веб-сервера Apache2 файл авто-конфигурации wpad.dat и откроем его на редактирование
sudo touch /var/www/html/wpad.dat sudo nano -Y sh /var/www/html/wpad.dat
Наполним файл примерно следующим содержимым:
function FindProxyForURL(url, host) { $OldProxy = "PROXY KOM-AD01-TMG.holding.com:8080"; $NewProxy = "PROXY KOM-AD01-SQUID.holding.com:3128"; $TestProxy = "PROXY KOM-AD01-TEST.holding.com:3128"; // // URLs for localhost if (shExpMatch(host, "127.0.0.1" )) {return "DIRECT";} if (shExpMatch(host, "*/localhost*" )) {return "DIRECT";} //
// Local sites by IP
if (isInNet(host, "10.0.0.0", "255.0.0.0")) {return "DIRECT";}
// // If URL has no dots in host name, send traffic direct if (isPlainHostName(host)) {return "DIRECT";} //
// URLs mathing mask - single host URLs in some domain
if (shExpMatch(url, "*/app1.local2.com*")) {return "DIRECT";}
if (shExpMatch(url, "*/portal.sub-local.su*")) {return "DIRECT";}
if (shExpMatch(url, "*/test-billing.holding.com*")) {return $NewProxy;}
//
// URLs mathing mask - all URLs in some domain if (shExpMatch(url,"*holding.com*")) {return "DIRECT";} if (shExpMatch(url, "*second.local.ru*")) {return "DIRECT";} if (shExpMatch(url,"*.third.local.org*")) {return "DIRECT";} // // Testing clients if (isInNet(myIpAddress(), "10.160.100.20", "255.255.255.255")) {return $TestProxy;} if (isInNet(myIpAddress(), "10.160.200.15", "255.255.255.255")) {return $TestProxy;} // // Clients for new proxy if (isInNet(myIpAddress(), "10.160.0.0", "255.255.0.0")) {return $NewProxy;} // //Return old proxy for EVERYTHING return $OldProxy; }
Как видим, в начале файла мы выполняем объявление трёх разных прокси-серверов. Предполагается что основной сервер, который используют в данный момент клиенты - это сервер на базе Forefront TMG (переменная $OldProxy). Новый прокси-сервер (переменная $NewProxy) - это сервер на базе Squid3, и на него будут попадать клиенты только из сети 10.160.0.0/16. Есть ещё третий сервер ($TestProxy) на котором мы ставим всяческие эксперименты и на него должны перенаправляться только два конкретных компьютера администраторов. После объявления прокси-серверов перечислены правила прямого доступа (в обход прокси) для ряда ресурсов, а затем уже идут директивы перенаправления клиентов на разные прокси.
После сохранения файла попробуем получить к нему доступ по HTTP с любого клиентского компьютера локальной сети набрав в браузере URL http://kom-ad01-squid.holding.com/wpad.dat
Если с доступностью файла по HTTP нет проблем, тогда в зависимости от выбранного метода публикации файла, доводим до клиентов информацию о его новом месторасположении. В нашем случае месторасположение файла wpad.dat доводится док клиентов с помощью DNS, и поэтому нам достаточно лишь изменить в локальной зоне DNS А/CNAME-запись wpad.holding.com. После этого с любого клиентского компьютера локальной сети проверяем доступность файла набрав в браузере URL http://wpad.holding.com/wpad.dat
При открытии на клиентском компьютере под управлением Windows файла wpad.dat отредактированного под Linux в редакторе nano мы увидим, что форматирование файла может отображаться (визуально) не верно. Это происходит из-за различия используемых символов для обозначения переноса строки в Linux (LF) и Windows (CR LF). Для браузеров использующий такой файл авто-настройки на самом деле это не является проблемой, но исключительно для удобства чтения такого файла в Windows, мы можем при его сохранении в редакторе nano выполнить конвертацию переносов строк в так называемый формат DOS.
Для этого сначала для сохранения файла в nano нажимаем Ctrl+O, а когда внизу экрана появится надпись говорящая о том где файл будет сохранён, типа…
File Name to Write: /var/www/html/wpad.dat
…нажимаем сочетание клавиш Esc+D и надпись измениться на:
File Name to Write [DOS Format]: /var/www/html/wpad.dat
После этого нажимаем Enter и файл будет сохранён в DOS формате, при котором переносы строк будут преобразованы в CR LF, в отличие от формата по умолчанию, где переносы строк сохраняются в виде LF.
Тестирование и отладка файла авто-конфигурации
В процессе настройки правил описанных в файле wpad.dat могут быть допущены разного рода ошибки (как синтаксические так и логические), что может помешать корректному применению правил на клиентах и получению желаемого результата. При отладке файла автоконфигурации весьма полезным может оказаться инструмент pacparser, загрузить который можно по ссылке. Это простая CLI-утилита позволяющая показать предполагаемый результат обработки того или иного URL клиентскими браузерами при использовании правил описанных в нашем wpad.dat. Рассмотрим пару простых примеров использования этой утилиты.
Проверим куда нас отправят правила нашего файла автоконфигурации прокси, если клиент идёт из одной из локальных подсетей на определённый локальный веб-узел:
pactester.exe -p C:\Temp\wpad.dat -c 10.160.50.10 -u https://sub-web.third.local.org/sub-folder DIRECT
Как видим, получена директива DIRECT, которая говорит о том что в данном случае клиент будет направлен на ресурс напрямую минуя прокси.
Теперь проверим куда нас отправят правила нашего файла автоконфигурации прокси, если это один их тестовых клиентов и он пытается попасть на внешний веб-узел:
pactester.exe -p C:\Temp\wpad.dat -c 10.160.200.15 -u http://ya.ru PROXY KOM-AD01-TEST.holding.com:3128
Из этого ответа очевидно, что для доступа к указанному ресурсу клиент будет направлен на тестовый прокси-сервер.
Таким образом эта утилита позволит нам тщательно протестировать каждое созданное нами правило автоконфигурации прокси.
***
Предыдущие части цикла заметок:
Часть 1. Установка ОС на ВМ Hyper-V Gen2
Часть 2. Настройка диска для кэша Squid
Часть 3. Конфигурация DNS , NTP и установка Squid
Часть 4. Конфигурация Kerberos и NTLM
Часть 5. Конфигурация Squid 3
Следующие части цикла заметок:
Часть 7. Кастомизация страниц ошибок
Часть 8. Конфигурация SqStat
Часть 9. Конфигурация LightSquid
Часть 10. Отключаем IPv6
Добрый день! Offtop: а какими средствами вы хотите управлять всем хозяйством? Я имею в виду задавать лимиты юзерам, статистика потребления трафика и т.д.
По поводу статистики (в её широко-распространённом виде) далее будет отдельная заметка про настройку и небольшое допиливание LightSquid. По поводу лимитов, несмотря на то, что для нас данная тема не шибко актуальна (сегодня практически у всех анлим в организациях), в планах всё же есть внедрение самописной системы под Linux (свой сборщик и анализатор логов squid) над которой в данный момент трудится один наш специалист. Если всё получится как задумано, то разумеется я опишу это дело.
Касательно затеи с лимитами для пользователей, любопытно, удалось ли Вам решить задачу, и если "да", то планируется ли статья?
У нас не было задачи лимитирования трафика пользователей. Речь шла про централизованный сбор и анализ логов. Про ограничение скорости через Delay pools была отдельная заметка: https://blog.it-kb.ru/2015/10/28/internet-speed-limitation-for-different-categories-of-users-on-the-proxy-server-squid-via-delay-pools/
Не смотрели в сторону SAMS? http://sams.perm.ru Мы широко используем, правда для NCSA авторизации, очень довольны.
Насчет SAMS я могу рассуждать исключительно исходя из той скудной информации, которой обладаю. Начнём с того, что, насколько я знаю, SAMS заточен под Squid2. Под Squid3 предполагается использовать SAMS2, который всё ещё в стадии beta (по крайней мере на сайте релиза я не увидел). Но это не главное, главным минусом этого зверя является отсутствие поддержки Кerberos, а попытки использовать NTLM аутентификацию в связке со Squid при большом количестве одновременно работающих пользователей имеют свои отрицательные побочные эффекты.
Добрый день!
Алексей, большое спасибо за цикл статей!
Возник вопрос: Если указывать IP прокси и порт в настройках браузера вручную, то авторизация проходит без проблем, но если указать ссылку на wpad.dat, то при переходе на любой сайт выходит к окно с предложением ввести имя пользователя и пароль. В чем кроется секрет?
Трудно сказать. Причины могут быть разные. Можете более подробно описать ситуацию на форуме, и тогда возможно смогу что-то подсказать.
Вроде разобрался.
Если в wpad.dat возвращать FQDN прокси-сервера, то запрашивает имя пользователя и пароль, если указать IP:port, то все ок.
Добрый день. Спасибо за статью очень помогла!
У меня вопрос .
Почему когда по айпишнику пишу прокси все работает
а стоит прописать имя прокси, спрашивает пароль и не пускает
http://forum.it-kb.ru/viewforum.php?f=52
Алексей, дополните информацию по внесению CNAME записи. Если используется MS DNS на Windows Server 2008 и выше, необходимо отключить блоклист ("Global Query Block List"). Создан он был для того, чтобы компьютеры самовольно не перезаписывали (создавали) служебные записи, как для прокси WPAD.
И соответственно, если блок лист включен имя WPAD.domain.com резолвится не будет.
Для проверки можно выполнить в командной строке (запущенной, естественно, с повышенными привилегиями) команду:
dnscmd /info /enableglobalqueryblocklist
Результат будет таким:
----
C:\Windows\system32>dnscmd /info /enableglobalqueryblocklist
Query result:
Dword: 1 (00000001)
Command completed successfully.
----
Единица означает, что "Global Query Block List" включен.
Чтобы отключить надо воспользоваться командой: dnscmd /config /enableglobalqueryblocklist 0
Результат:
---
C:\Windows\system32> dnscmd /config /enableglobalqueryblocklist 0
Registry property enableglobalqueryblocklist successfully reset.
Command completed successfully.
---
После чего имя WPAD будет резолвится.
Во первых полностью отключать globalqueryblocklist не совсем правильное решение. Во вторых, если бы Вы внимательно читали заметку, то обратили бы внимание на ссылку на более раннюю статью https://blog.it-kb.ru/2012/06/05/forefront-tmg-and-web-proxy-automatic-discovery-wpad/, где указанная проблема освещается. В третьих, это заметка о настройке WPAD на сервере Squid, а не о заморочках в службе DNS на Windows Server.
Через некоторое время компьютеры перестают понимать wpad.dat, приходится удалять и снова писать конфиг, и опять начинает работать. Есть мысли куда копать?? Раздаю wpad.dat через DHCP (Mikrotik)
Обратная ссылка: Пропускаем приложения .NET Framework 4 через HTTP-прокси с аутентификацией | Блог IT-KB /
А если нет тестовых и старых прокси, а сквид это первый, то можно просто эти параметры не учитывать или "закоментить" верно?
Правильнее всего ненужные параметры просто удалить.
Обратная ссылка: Настройка прокси сервера Squid 3.3 на Ubuntu Server 14.04 LTS. Часть 1. Установка ОС на ВМ Hyper-V Gen2 | Блог IT-KB /