Настройка wpad windows server 2012

Обновлено: 06.07.2024

Протокол автоматического обнаружения веб прокси (Web Proxy Autodiscovery Protocol или WPAD) может использоваться для того, чтобы все браузеры и клиентские брандмауэры смогли автоматически обнаруживать адрес брандмауэра ISA firewall. После этого клиент сможет загрузить информацию с автоматической конфигурацией с брандмауэра после того, как веб прокси или брандмауэр клиента обнаружит этот адрес.

Клиентский брандмауэр также может использовать запись wpad для обнаружения брандмауэра ISA firewall и загрузки информации с конфигурацией для брандмауэра клиента.

В этой статье мы обсудим следующие процедуры:

Настройка поддержки DHCP WPAD
Настройка поддержки DNS WPAD

После того, как wpad информация введена в DHCP и DNS, веб прокси (Web Proxy) и брандмауэрам клиентов не нужна ручная настройка для подключения к Интернет через брандмауэр ISA firewall.

Настройка поддержки DHCP WPAD

Выполните следующие шаги на сервере DHCP, чтобы создать специальную настройку DHCP:

Откройте консоль DHCP из меню Administrative Tools (Администрирование) и выберите название вашего сервера в левой части консоли. Выберите команду Set Predefined Options (задать предопределенные настройки) .
В диалоговом окне Predefined Options and Values (предопределенные параметры и значения), нажмите на кнопку Add (добавить) .

В диалоговом окне Option Type (тип настройки) введите следующую информацию:

Name (название): wpad

Data type (тип данных): String (строка)

Description (описание): wpad entry

Нажмите на кнопку OK .

В окне Value (значение) введите URL брандмауэра ISA firewall в текстовом поле String (строка) . Формат следующий: http://ISAServername:AutodiscoveryPort Number/wpad.dat По умолчанию порт для автоматического определения (autodiscovery port) - TCP 80. Вы можете изменить это значение в консоли ISA Firewall . Мы расскажем об этом более подробно позднее в этой статье. В текущем примере введите следующее значение в текстовое поле String (строока) : http://isalocal.msfirewall.org:80/wpad.dat Убедитесь, что вводите буквы wpad.dat в нижнем регистре . Для получения более подробной информации по этой проблеме обратитесь к статье "Automatically Detect Settings" Does Not Work if You Configure DHCP Option 252 Нажмите на кнопку OK .

Щелкните правой кнопкой мыши на узле Scope Options (параметры области) в левом окне консоли и выберите команду Configure Options (настройка параметров) .
В диалоговом окне Scope Options (параметры области) прокрутите список Available Options (доступные параметры) и поставьте галочку в поле 252 wpad . Нажмите на кнопку Apply (применить) , а затем на кнопку OK .

Теперь запись 252 wpad появится в правой части консоли ниже списка Scope Options (параметры области) .

Закройте консоль DHCP .

Теперь клиенты DHCP смогут использовать DHCP wpad поддержку для автоматического обнаружения брандмауэра ISA firewall и последующую собственную автоматическую настройку. Однако, брандмауэр ISA firewall должен быть настроен на поддержку публикации информации для автоматического обнаружения (autodiscovery), что мы сделаем позднее в этой статье.

Настройка DNS WPAD поддержки

Еще один метод, который мы можем использовать для доставки информации для автоматического обнаружения для веб прокси (Web Proxy) и брандмауэров клиентов, это DNS. Мы можете создать заголовок wpad в DNS и позволить клиентским браузерам использовать эту информацию для собственной автоматической настройки. DNS – это важная вещь, но вы должны знать, что если у вас несколько сетей, у каждой из которых есть собственный брандмауэр ISA Firewall, то у вас должно быть различные записи для wpad для каждой из сетей. Т.к. вы можете поддерживать несколько сетей и несколько ISA Firewalls с помощью DNS, используя возможности упорядочивания сетевых масок (netmask ordering), большинство компаний используют DHCP wpad для поддержки локальных сетей, т.к. для них необходимо использовать локальный сервер DHCP для присвоения адресов локальным клиентам.

Распознавание имен – центральный компонент для обеспечения правильной работы этого метода для автоматической настройки веб прокси и клиентских брандмауэров. В этом случае, операционная система клиента должны быть с состоянии правильно определить полное имя wpad . Причина этого заключается в том, что веб прокси и брандмауэры клиентов знают лишь, что им необходимо распознать название wpad; они не знают, какое конкретное название домена они должны добавить к запросу, чтобы распознать название wpad. Мы расскажем об этой проблеме подробнее позднее в этой статье.

Примечание: В отличие от DHCP метода по получению информации для автоматической настройки веб прокси и брандмауэров клиентов, у вас нет возможности использования произвольного порта для публикации информации для автоматической настройки при использовании DNS метода. Вы всегда должны публиковать информацию для автоматической настройки по TCP 80, если используете DNS метод.

Вы должны выполнить следующие шаги для настройки DNS поддержки для автоматического обнаружения веб прокси и брандмауэрами клиентов брандмауэра ISA firewall:

Создайте запись wpad в DNS
Настроите клиента на использование заголовка wpad
Настройте браузер клиента на использование автоматического обнаружения

Создание записи Wpad в DNS

На первом этапе необходимо создать заголовок wpad в DNS. Этот заголовок (также известный, как запись CNAME) указывает на запись Host (A) для брандмауэра ISA Server 2004 firewall. Запись Host (A) преобразует название брандмауэра ISA Server 2004 firewall во внутренний IP адрес брандмауэра. Я должен упомянуть, что вы не обязаны использовать CNAME запись, если хотите, вы можете использовать запись A, но записи CNAME обладают некоторыми преимуществами в управлении.

Запись Host (A) должна быть создана прежде, чем вы создадите CNAME запись. Если вы включили автоматическую регистрацию в DNS, то название и IP адрес брандмауэра ISA уже будет введено в запись DNS Host (A). Если вы не включили автоматическую регистрацию, то вы должны самостоятельно создать запись Host (A) для брандмауэра.

Выполните следующие шаги на сервере DNS на контроллере домена во внутренней сети:

Если вы настраиваете параметры прокси сервера в веб-браузере Internet Explorer (IE) с помощью групповых политик, и тем более делаете это с запретом изменений настроек для пользователя, то рано или поздно может возникнуть ситуация, когда пользователь выехавший в командировку не сможет воспользоваться на служебном ноутбуке браузером для доступа в интернет где-нибудь в гостинице или аэропорте из-за невозможности отключения этих самых жёстко заданных настроек прокси.

Файл Wpad.dat это файл Java-script в котором задаются настройки параметров расположения имени и порта прокси сервера, а также список исключений для обхода прокси. В случае недоступности данного файла браузер будет выполнять попытку прямого подключения к Интернет-ресурсам через настроенный в свойствах сетевого адаптера шлюз по умолчанию. При этом в настройках самого браузера в явном виде параметры прокси не указываются, а включается соответствующая опция авто-обнаружения. Механизм WPAD поддерживают браузеры Internet Explorer, Mozilla Firefox, с некоторыми ограничениями Opera и др.

Для того чтобы клиентский браузер узнал о том, где в локальной сети расположен сервер с опубликованным файлом wpad.dat, может использоваться механизм обращения в DNS или получения настроек с сервера DHCP. Эти оба метода можно применять как раздельно, так и совместно и каждый из этих методов имеет свои достоинства и недостатки.

WPAD и DHCP

Метод настройки сервера DHCP для использования WPAD можно найти здесь: TechNet Library - Creating a WPAD entry in DHCP

Его основа сводится к добавлению на сервер DHCP дополнительной опции 252, в которой указывается URL файла авто-настройки. Эта опция назначается на сервер или отдельную область и передается клиентам DHCP вместе с основными настройками IP.

Итак, для настройки сервера DHCP на Windows Server 2008 R2 откроем консоль управления этой ролью (Start -> Programs -> Administrator Tools -> DHCP) и в свойствах сервера выберем пункт управления опциями - Set Predefined Options.

В окне опций, чтобы добавить новую опцию нажмём Add и затем укажем параметры опции:

Name – WPAD
Code – 252
Data Type – String
Description - Web Proxy Automatic Discovery

После этого зададим в поле String значение URL по умолчанию и сохраним параметр.

В документации встречается отдельное замечание о том, что имя файла wpad.dat должно быть написано в данном случае в нижнем регистре.

После того как опция создана мы можем сконфигурировать её как для отдельной области так и глобально для всего сервера DHCP:

Как видно, при задании URL размещения файла авто-настройки можно указывать нестандартный порт вместо 80, что является преимуществом в сравнении с методом настройки через DNS где при публикации файла может использоваться только 80 порт. С другой стороны метод настройки через DHCP не поможет нам на системах где используется статическая IP адресация (DHCP клиент не запущен) и при этом требуется настройка браузера, например на терминальных серверах. Более того, по имеющейся информации обрабатывать опцию с DHCP способен только Internet Explorer, то есть говорить об альтернативных браузерах в данном случае не приходится вообще.

WPAD и DNS

В нашем практическом примере мы будем использовать метод с использованием DNS, так как, на мой взгляд, он является наиболее универсальным, хотя и не лишён некоторых недостатков (некритичных в нашей ситуации).

Прежде чем начать использовать наш DNS сервер для WPAD, мы должны убедиться в том, что он не настроен на блокировку обновления/разрешения имён wpad. Такая блокировка по умолчанию защищает сервер от атак по регистрации фальшивых узлов wpad. Во времена Windows Server 2003 такая защита обеспечивалась тем, что в зонах DNS создавалась специальная запись-заглушка с типом TXT. Подробней об этом можно почитать в статье KB934864 - How to configure Microsoft DNS and WINS to reserve WPAD registration . С приходом Windows Server 2008 в роли DNS Server появился встроенный механизм глобальных листов блокировки. В нашем примере используется сервер DNS на базе Windows Server 2008 R2, и для того, чтобы посмотреть задействован ли в данный момент механизм глобальных блокировок выполним команду:

dnscmd /info /enableglobalqueryblocklist

Чтобы получить содержимое блок-листа выполним:

dnscmd /info /globalqueryblocklist

В конфигурации по умолчанию в блок-лист как раз таки включены записи wpad и isatap. Чтобы переписать содержимое блок-листа, исключив оттуда интересующий нас wpad, выполним команду:

dnscmd /config /globalqueryblocklist isatap

По сути в данном случае утилита dnscmd оперирует с параметрами реестра описанными в статье TechNet Library - Remove ISATAP from the DNS Global Query Block List

В ветке реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters

блок-лист хранится в параметре GlobalQueryBlockList

Если есть желание отключить использование блок-листа совсем, можно выполнить:

dnscmd /config /enableglobalqueryblocklist 0

или же в изменить соответствующий параметр реестра EnableGlobalQueryBlockList

После сделанных изменений нужно перезапустить службу DNS

WPAD сервер

Используя TechNet Library - Configuring a WPAD server рассмотрим настройки на стороне сервера Forefront TMG, который будет у нас выполнять роль сервера WPAD с опубликованным файлом авто-конфигурации wpad.dat

В консоли Forefront TMG Management в дереве навигации перейдём в ветку Networking на закладку Networks и выберем сеть, для которой нам нужно создать прослушиватель WPAD (обычно это внутренняя сеть – Internal). Откроем свойства этой сети

На закладке Auto Discovery включим опцию публикации файла wpad.dat - Publish automatic discovery information for this network

В поле где указан номер порта устанавливаем 80 порт. Как уже отмечалось ранее, в силу того, что мы используем связку WPAD/DNS, мы должны использовать именно этот порт.

Переключаемся на закладку Web Browser и настраиваем список исключений для узлов и доменов к которым клиенты должны ходить напрямую минуя прокси.

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

.

DirectNames=new MakeNames();

cDirectNames = 10;

HttpPort = "8080" ;

cNodes = 2;

function MakeProxies ()
this[0] = new Node( "192.168.0.11" ,2531460408,1.000000);

this[1] = new Node( "192.168.0.12" ,3457248957,1.000000);

>

Proxies = new MakeProxies();

.

Для того чтобы изменить адреса прокси попадающие в wpad с IP на FQDN можно воспользоваться подключением к COM-объекту TMG через Powershell и свойством CarpNameSystem. Чтобы получить текущее значение этого свойства, выполним скрипт:

$ServerName = "TMGCLUSTER"

$FPCRoot = New-Object -comObject "FPC.Root"

$TMGObj = $FPCRoot .Arrays.Connect( $ServerName )

$TMGObj .ArrayPolicy.WebProxy.CarpNameSystem

Установленное по умолчанию значение "2" нам нужно будет заменить на значение "0" следующим образом:

$ServerName = "TMGCLUSTER"

$FPCRoot = New-Object -comObject "FPC.Root"

$TMGObj = $FPCRoot .Arrays.Connect( $ServerName )

$TMGObj .ArrayPolicy.WebProxy.CarpNameSystem = 0

$TMGObj .ApplyChanges()

Для вступления параметров в силу нужно перезапустить сервера TMG.

После перезагрузки снова проверяем содержимое файла wpad.dat и убеждаемся в том, что адреса прокси указаны в виде FQDN серверов.

.

function MakeProxies ()
this[0] = new Node( "TMG01.holding.com" ,2531460408,1.000000);

this[1] = new Node( "TMG02.holding.com" ,3457248957,1.000000);

>

.

WPAD клиенты

Дело осталось за малым – включить настройку WPAD в свойствах клиентских веб-браузеров. В Internet Explorer эта опция включена по умолчанию, и если ранее вы использовали групповые политики для явного задания настроек прокси, то возможно имеет смысл их же использовать для стирания старых настроек и включения авто-определения.

В браузере Mozilla Firefox активация механизма WPAD делается аналогичным образом и работает без нареканий (проверено на текущей версии 12.0)

WPAD или автоматическая настройка параметров прокси

Если автоматическая настройка сетевых параметров сегодня стала "нормой жизни" даже в небольших сетях, то автоматическое получение настроек прокси-сервера по-прежнему вызывает некоторые затруднения. Для этих целей существует протокол автоматической настройки прокси - 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 не найден, то поиск будет произведен в вышестоящем домене, при этом выход за пределы домена организации никак не контролируется.

В связи с этим 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-скриптом, однако количество инструкций в нем жестко ограничено. Разберем некоторые из них.

isPlainHostName(host) - истина если host - "плоское" имя хоста, т.е. обычное NetBIOS-имя и т.п. Позволяет определять обращения к хостам локальной сети по простому имени.

dnsDomainIs(host, domain) - истина, если домен в запросе (host) совпадает с заданным в директиве domain.

isResolvable(host) - истина, если доменное имя удается разрешить. Данную инструкцию следует использовать осторожно, так как она делает дополнительный DNS-запрос, что может увеличить нагрузку на сервера и ухудшить время отклика.

isInNet(host, pattern, mask) - истина, если IP-адрес хоста совпадает с шаблоном, где pattern - шаблон сети, mask - маска. Например, 192.168.0.0, 255.255.255.0.

shExpMatch(str, shexp) - истина, если строка совпадает с шаблоном, в качестве строки можно использовать host или url, при этом следует помнить, что шаблон не является регулярным выражением.

Этих инструкций вполне достаточно, чтобы составить достаточно подробные и разветвленные правила для работы с прокси-сервером. Попробуем составить реальный сценарий.

Прежде всего укажем функцию:

Данная функция получает от браузера URL и host из запроса и в ответ должна вернуть адрес прокси-сервера. Внутри фигурных скобок следует располагать инструкции и условия, в зависимости от выполнения которых браузеру будет возвращен тот или иной результат.

Согласно данной записи, если в поле host запроса содержится "плоское" имя, то возвращаем браузеру директиву DIRECT, что означает, что прокси-сервер для этого соединения использовать не следует.

Таким же образом предписываем обращаться напрямую по запросам с IP-адресами локальной сети:

И локальным адресам:

Кстати, первое правило можно переписать по-другому:

В доменной сети также следует настроить прямое соединение для внутренних ресурсов:

Тоже самое следует сделать и для ftp запросов:

И наконец все, что не попало ни под одно правило отправляем на прокси:

Разобравшись с тем, как устроен PAC-файл перейдем к сценариям практической реализации служб WPAD в сети.

Сети Active Directory

Так как все наши статьи преемственны, то далее будет подразумеваться что WPAD настраивается для работы с роутером в сети Active Directory, описанного нами в цикле Настраиваем Squid для работы с Active Directory, таким образом данный материал может служить его логическим завершением.

Начнем с настройки DHCP, откроем соответствующую оснастку и перейдем к списку серверов, щелкните правой кнопкой мыши на пункт IPv4 и выберите Предопределенные параметры.

В открывшемся окне нажмите Добавить

И заполните поля следующим образом:

Имя - WPAD
Тип данных - строка
Код - 252

После чего перейдите в Область - Параметры области - Настроить параметры и добавьте созданную нами опцию WPAD.

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

Следующим шагом будет настройка DNS, прежде всего откорректируем черный список, для этого на DNS-сервере откроем редактор реестра и перейдем в раздел:

Откроем опцию GlobalQueryBlockList и удалим оттуда значение wpad, после чего службу DNS нужно перезапустить.

Данную операцию следует выполнить на каждом DNS-сервере в вашей сети.

Затем добавьте запись типа A для хоста wpad, которая должна указывать на веб-сервер с PAC-файлом.

После установки роли перейдите в Диспетчер служб IIS - Сайты - Default Web Site в настройках которого выберите Типы MIME.

Для правильной работы с PAC-файлом добавьте новый тип MIME, указав расширение .dat и тип MIME application/x-ns-proxy-autoconfig.

Выполнив данную настройку не забудьте перезапустить веб-сервер и разместите в его корневой директории C:\inetpub\wwwroot файл wpad.dat.

Как правило, дальнейших действий не требуется. Internet Explorer и Edge по умолчанию имеют настройку автоматического определения настройки параметров прокси-сервера. Но можно подстраховаться и создать отдельную политику в GPO, для этого используйте Конфигурация пользователя - Настройка - Параметры панели управления - Параметры обозревателя.

Браузеры на основе Google Chrome (в т.ч. Opera, Яндекс) используют настройки, заданные для IE. Проблемы, как всегда, возникают с Firefox, который с настройкой по умолчанию Использовать системные настройки прокси игнорирует их и ходит напрямую, поэтому данную опцию следует изменить на Автоматически определять настройки прокси для этой сети.

Одноранговая сеть

В одноранговых сетях обычно применяются прозрачные прокси, не требующие настройки параметров браузера, однако в ряде случаев, например, для аутентификации, от прозрачности приходится отказываться, следовательно, возникает потребность в WPAD. Далее мы будем рассматривать настройку на примере роутера, настроенного по нашей статье: Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3.

А теперь вспомним, как происходит поиск PAC-файла. Если браузер не получил нужной опции по DHCP или не умеет ее получать, он делает DNS-запрос для хоста wpad в текущем домене. Мы специально выделили ключевой момент - в текущем домене. А какой текущий домен в одноранговой сети? Правильно, никакого.

Чтобы убедиться в этом, следует проверить DNS-суффикс текущего подключения. Для этого в консоли PowerShell выполните команду:

Ниже показан вывод команды для одноранговой и доменной сетей, разница в отсутствии DNS-суффикса отлично видна "невооруженным глазом".

Если все оставить как есть, то тот же Firefox не сможет получить настройки прокси и будет требовать ручного ввода параметров. Что делать? К счастью в протоколе DHCP есть опция 015, позволяющая передавать клиенту DNS-суффикс подключения.

Откроем /etc/dnsmasq.conf и последовательно изменим в нем следующие опции:

Данная опция указывает, что домен interface31.local - локальный и разрешать его имена на вышестоящих DNS-серверах не следует.

Данная запись в формате dnsmasq является аналогом A-записи для хоста wpad, где 192.168.31.1 - адрес хоста, на котором будет расположен веб-сервер (в нашем случае это роутер).

DNS-имя домена, передаваемое клиенту в опции 015 DHCP.

Задает расположение PAC-файла.

Теперь заново получим IP-адрес и снова проверим DNS-суффикс, также можно попробовать разрешить любое плоское имя (существующего хоста) командой nslookup.

Если все сделано правильно - у подключения появится указанный нами суффикс, а плоские имена будут дополняться до FQDN. Теперь можно переходить к настройке веб-сервера.

Это ограничит работу веб-сервера только локальной сетью.

После чего следует убедиться, что в файле /etc/mime.types присутствует запись:

Если такой записи нет, то ее следует добавить.

На этом настройка сервера закончена, осталось разместить PAC-файл в директории /var/www и проверить работу браузеров.

Поскольку одноранговая сеть не предоставляет таких возможностей по управлению клиентскими ПК как ActiveDirectory, то следует предпринять меры по предотвращению обхода прокси. Это можно сделать через iptables, запретив форвардинг пакетов с назначением на 80-й порт. Но лучше поступить иначе.

В /etc/nat добавим следующее правило:

Данная конструкция перенаправит все запросы к веб-серверам или сторонним прокси на порт 80 нашего роутера, где работает собственный веб-сервер.

Теперь в /var/www создадим файл index.html со следующим содержимым:

В качестве примера мы привели самый простой вариант странички запрета, вам же ничего не мешает сделать ее более информативной, например, разместив на ней краткие инструкции по самостоятельной настройке браузера.

Если вам нужно разрешить работу с некоторыми сайтами напрямую, минуя прокси, то перед запрещающим правилом добавьте:

где xxx.xxx.xxx.xxx - IP-адрес требуемого ресурса.

Как видим, настроить автоматическое получение параметров прокси совсем несложно и можно эффективно применять данную технологию как в крупных, так и в небольших сетях.

1.2 Чем хороша данная технология

— нет необходимости через GPO прописывать всем клиентам адрес-прокси
— Мобильность сотрудников (доступ к интернету вне офиса)
— Чтобы отключить использование данной технологии, достаточно отключить в «Свойствах браузера» — «Автоматическое получение настроек»

— «Автоматическое получение настроек» можно отключить любому пользователю, поэтому данную функцию лучше оставить включенной и запретить ее изменение через GPO

1.3 Squid Peek-n-splice — how to it works

1.4 Плюсы и минусы Peek-n-splice

— К сожалению, нельзя полностью просмотреть какая именно интернет-страница была открыта как при MITM-атаке
— Данная конфигурация хорошо себя показала только на CentOS (на Debian были проблемы, через некоторое время случался kernel-panic)

1.5 И так, теперь стоит отметить что дано

— Хост с Active Directory 2012R2 (метод авторизация пользователей — Kerberos)10.0.0.9
— Хост с CentOS 7 (x64) (он же веб-сервер для отдачи wpad.dat, он же прокси-сервер) 10.0.0.10
— Тестовый хост с ОС Windows для проверки работы 10.0.0.11

2 Конфигурирование операционной системы и установка Squid

2.1 Squid должен быть собран с такими параметрами

$ squid -v
Squid Cache: Version 3.5.16
Service Name: squid
configure options: '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--verbose' '--exec_prefix=/usr' '--libexecdir=/usr/lib64/squid' '--localstatedir=/var' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--with-logdir=$(localstatedir)/log/squid' '--with-pidfile=$(localstatedir)/run/squid.pid' '--disable-dependency-tracking' '--enable-follow-x-forwarded-for' '--enable-auth' '--enable-auth-basic=DB,LDAP,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,getpwnam,fake' '--enable-auth-ntlm=smb_lm,fake' '--enable-auth-digest=file,LDAP,eDirectory' '--enable-auth-negotiate=kerberos,wrapper' '--enable-external-acl-helpers=wbinfo_group,kerberos_ldap_group,LDAP_group,delayer,file_userip,SQL_session,unix_group,session,time_quota' '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' '--enable-delay-pools' '--enable-epoll' '--enable-icap-client' '--enable-ident-lookups' '--enable-linux-netfilter' '--enable-removal-policies=heap,lru' '--enable-snmp' '--enable-storeio=aufs,diskd,ufs,rock' '--enable-wccpv2' '--enable-esi' '--enable-ssl-crtd' '--enable-icmp' '--with-aio' '--with-default-user=squid' '--with-filedescriptors=16384' '--with-dl' '--with-openssl' '--with-pthreads' '--with-included-ltdl' '--disable-arch-native' '--enable-ecap' '--without-nettle' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'CXXFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' —enable-ltdl-convenience

Либо же можно скачать архив с собранным squid и его зависимостями.

2.2 Установка необходимых пакетов из официальных репозиториев

Стоит отметить, что для установки кальмара нужны некоторые зависимости. К сожалению, у CentOS довольно скудные официальные репозитории, поэтому некоторые пакеты надо качать с неофициальных. Установка необходимых пакетов из оф.репозиториев:

2.3 Ручная установка Squid и дополнительных пакетов

Если что-то не так, в терминале отобразится чего не хватает.

2.4 Установка прав доступа для каталога swap

2.5 конфигурационный файл /etc/squid/squid.conf

acl localnet src 10.0.0.0/24
acl localnet src 192.168.0.0/24

acl my_full external inet_full
acl my_medium external inet_medium
acl my_low external inet_low
acl auth proxy_auth REQUIRED

always_direct allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

acl blocked ssl::server_name "/etc/squid/blocked_https.txt"
acl step1 at_step SslBump1
ssl_bump peek step1

coredump_dir /var/spool/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern. 0 20% 4320

cache_dir aufs /var/spool/squid 20000 49 256
maximum_object_size 61440 KB
minimum_object_size 3 KB

cache_swap_low 90
cache_swap_high 95
maximum_object_size_in_memory 512 KB
memory_replacement_policy lru
logfile_rotate 4

2.6 Предварительно необходимо привести файл /etc/hosts к такому содержанию

2.7 Настраиваем selinux

В файле /etc/selinux/config должно быть значение:

Устанавливаем пакет для работы с selinux:

Добавляем правила selinux

Разрешаем подключения к кальмару:

Разрешаем подключения к кальмару на 3130 порту:

После изменения параметров selinux, необходимо перезагрузить систему для их применения.

2.8 генерация swap

2.9 Включение демона squid, проверка конфигурационного файла

Варнингов и эрроров не должно быть. Если же что-то есть — необходимо проверить настройки.

2.10 Разрешаем форвардинг трафика

Применяем настройку налету:

3 Интеграция с контроллером домена Active Directory 2012R2

Интеграция с контроллером домена необходима для того, чтобы пользователи домена могли авторизовываться на прокси-сервере по протоколу Kerberos. Самое разумное решение — оставить только Kerberos ввиду того, что данный метод самый безопасный, авторизация происходит автоматически. Что же касается клиентских машинах которые вне домена, то и здесь нет проблем, логин и пароль можно ввести вручную во всплывающем окне авторизации. Проверено, работает.

3.1 Конфигурационный файл /etc/krb5.conf

Конфигурационный файл /etc/krb5.conf необходимо привести к следующему виду:

3.2 Создание DNS-записи

3.3 Варианты интеграции с доменом

И так, ~~есть два стула~~ варианта интеграции с доменом. Первый вариант — средствами Windows (ktpass), второй вариант — средствами Linux (Msktutil). Windows вариант хорош тем, что можно отключить срок действия пароля для пользователя squid. Версия Linux хороша тем, что можно вводить в домен через создание учетной записи компьютера.

3.3.1 Интеграция средствами Windows

Создаем пользователя в AD, например squid
Теперь генерируем krb5.keytab. В командной строке на контроллере домена с правами администратора необходимо выполнить данную команду:

3.3.2 Интеграция средствами Linux

В архиве со сквидом и зависимостями также приложен msktutil, устанавливаем его:

Теперь выполняем следующую команду:

В случае успеха, вывод команды будет большим, копировать сюда не вижу смысла. Ошибок и варнингов быть не должно. Стоит обратить внимание на --computer-name sq-k это не опечатка. Имя хоста должно отличаться.

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

В него необходимо добавить задание:

3.4 Рекомендуемые права на файл krb5.keytab

После перемещения krb5.keytab, рекомендуется понизить права доступа к файлу

3.5 Группы доступа AD

В ActiveDirectory в OU Users необходимо создать три группы, согласно которых будет распределен доступ в Интернет: Internet-full, Internet-medium, Internet-low.

3.6 Проверка авторизации

Проверка авторизации в Active Directory при помощи файла /etc/krb5.keytab

Вывод команды должен быть примерно такой:

А klist должен отобразить следующее:

4 WPAD

4.1 Установка и конфигурирование web-сервера apache2

После установки включаем в автозагрузку:

Далее необходимо создать /var/www/html/wpad.dat файл со следующим содержанием:

4.2 Описание файла wpad.dat

По дефолту в каталоге /var/www/html/wpad.dat файл отдается всем без дополнительных настроек apache2, а это как раз необходимо для корректного взаимодействия с клиентскими машинами на ОС Windows.

Если запрашиваемый ресурс не попадает под вышеперечисленные условия, выполняется следующее:

4.3 Создание CNAME

Для проверки необходимо открыть в браузере wpad/wpad.dat и файл wpad.dat должен автоматически скачаться. Таким образом, все хосты скачивают данный файл, и исходя из содержимого действуют. Рекомендуется сделать релог или перезагрузить все компьютеры в домене на ОС Windows, чтобы произошло скачивание файла.

5 Статистика

5.1 Установка SARG из исходников

Если не был установлен gcc ранее, сейчас самое время:

В файле po/Makefile.in.in указана версия gettext как 0.18, чтобы не было ошибки при make install, необходимо изменить на 0.19:

5.2 Конфигурирование SARG

Стандартный файл конфигурации /usr/local/etc/sarg.conf лучше забекапить:

Теперь создаем файл sarg.conf со следующим содержанием:

5.3 Расписание генерации отчетов при помощи cron

Данная строчка указывает, что отчеты будут генерироваться каждый день и за текущий день в 23:55

5.4 Конфигурация web-сервера

Alias /reports /var/www/html/squid-reports/

5.5 Авторизация на сайте со статистикой

Генерация файла логина и пароля для авторизации

Перезапуск apache2:

6 Групповые политики

Здесь все неоднозначно и может зависит, от каких-то особенностей. В текущей задаче было разумным решением исключить возможность установки прокси-сервера пользователя, или же отключения «Автоматического определения параметров».

6.1 Редактирование GPO

Для запрета ввода прокси-сервера или изменения настроек по автоматическому определению параметров, можно воспользоваться групповой политикой. Создаем и связываем групповую политику с OU например, office.

Редактируем групповую политику:

Пользователь → Политики → Административные шаблоны → Компоненты Windows → Internet Explorer

В данном каталоге найти параметры и перевести в статус «Включено»:

«Запретить изменение параметров прокси»
«Отключить изменение параметров автоматической»

В заключение сказать могу вот что, данная конфигурация успешно работает по настоящее время с весны 2016-го, и отлично себя зарекомендовала. На все вопросы буду рад ответить.

UPD №1: 12.11.16
1 Были убраны из конфига сквида лишние строки портов 3128 и 3129.
2 включил selinux и добавил правила.
3 Была убрана генерация сертификата из мануала(без него работает)
4 Мелкие исправления
UPD №2: 20.11.16
1 Были убраны из конфига krb5.conf лишние строки
2 Добавлен метод интеграции с AD через Msktutil
3 Добавлен форвардинг
4 Обновлен архив со сквидом и зависимостями

Читайте также: