Настраиваем Squid для работы с Active Directory. Часть 1 - базовые настройки
Материалы о построении роутера на базе Squid - одни из самых популярных на нашем сайте. Такое решение позволяет с минимальными затратами (прежде всего на программную часть) организовать и упорядочить доступ к сети интернет на предприятии. Но рассматриваемые нами варианты предназначались преимущественно для работы в составе рабочей группы. Отсутствие интеграции с Active Directory резко снижало удобство применения такого роутера в доменных сетях, поэтому мы решили исправить это упущение.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе
"Архитектура современных компьютерных сетей"
вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов.
На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
В процессе подготовки данного материала мы не планировали отдельно останавливаться на подготовке сервера, намереваясь использовать для этого уже существующий материал: Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3. Однако, когда количество уточнений и отличий стало превышать разумные пределы, мы решили посвятить этому вопросу отдельную статью. В тоже время мы предполагаем, что читатель знаком с вышеуказанным материалом и поэтому не будем объяснять подробно многие используемые нами настройки и не будем останавливаться на второстепенных деталях.
Особенности интеграции с Active Directory
В чем смысл интеграции прокси-сервера Squid в Active Directory? Скажем сразу, что если ваша основная цель - просто раздать интернет всем и без ограничений, ну разве что закрыв социальные сети, то дальше можно не читать, уже описанная нами конфигурация полностью удовлетворит ваши потребности. Основное преимущество интеграции роутера в Active Directory - это использование единой точки аутентификации и управление доступом к сети интернет на базе уже существующих в домене учетных записей и групп безопасности.
Отсюда следуют некоторые особенности. Так прозрачный режим не поддерживает аутентификацию и от него придется отказаться, указывая настройки прокси непосредственно в настройках браузера. Этот процесс несложно автоматизировать при помощи DHCP-сервера и протокола WPAD.
В качестве DNS-серверов, в том числе и на роутере, должны обязательно указываться только доменные DNS, по умолчанию DNS-сервером является каждый контроллер домена. По этой причине роутер не должен иметь роли DNS-сервера. Также, для обеспечения интеграции с AD, роль DHCP-сервера также следует передать Windows Server, обычно на один или несколько контроллеров домена.
Теперь подходим к тому, ради чего все это затевалось. Аутентификация по доменным учетным записям позволяет использовать единую точку входа (SSO, Single Sign-On), когда пользователь вводит логин и пароль один раз - при входе в систему. Это достигается применением протокола Kerberos, который является способом аутентификации в AD по умолчанию. В отличии от авторов иных руководств, мы не видим смысла настраивать NTLM или Basic-аутентификацию, в первую очередь по соображениям безопасности. Тем более Kerberos поддерживают все современные операционные системы.
Следующим шагом является авторизация на основе существующих групп безопасности, это особенно актуально при переходе с Forefront TMG или ISA Server. Это позволяет один раз настроив Linux-сервер дальнейшее управление доступом осуществлять привычным способом - через группы Active Directory, что позволяет снизить порог вхождения для администраторов.
Так как Active Directory имеет более сложную структуру и большее количество "действующих лиц", то чтобы вы не запутались в используемых нами адресах и именах хостов мы подготовили небольшую схему:
В наших примерах будет использоваться домен Active Directory с FQDN именем interface31.lab, за который отвечают два контроллера домена SRV-DC01 и SRV-DC02 с адресами 192.168.31.101 и 102 соответственно. Оба контроллера реализованы на базе Windows Server 2012 R2.
Роутер выполнен на базе Ubuntu Server 14.04 (Debian 7/8) и имеет имя SRV-GW01 с адресом 192.168.31.100. Также в сети имеется группа серверов со статическими адресами 192.168.31.103-105 и клиентские ПК, адреса которым выдаются DHCP сервером из диапазона 192.168.31.111-199.
Настройка сети
Сеть настраивается традиционным образом, посредством правки конфигурационного файла /etc/network/interfaces. Примем что внешней сети соответствует интерфейс eth0, а внутренней eth1. В результате настройки у нас должно получиться примерно следующее:
1auto lo
2 iface lo inet loopback
3
4auto eth0
5 iface eth0 inet static
6 address 172.18.0.106
7 netmask 255.255.240.0
8 gateway 172.18.0.1
9 dns-search interface31.lab
10 dns-nameservers 192.168.31.101 192.168.31.102
11
12auto eth1
13 iface eth1 inet static
14 address 192.168.31.100
15 netmask 255.255.255.0
16
17post-up /etc/nat
Обратите внимание, что несмотря на то, что в настройках внешнего интерфейса использован внешний адрес и шлюз, адреса DNS-серверов указаны внутренние. Также указана опция dns-search, которая определяет домен для разрешения не FQDN-имен. Это означает, что к каждому короткому имени будет автоматически добавлен указанный домен, например, srv-dc01 будет дополнено до srv-dc01.interface31.lab.
Если вас смущает указание внутренних DNS в настройках внешней сетевой карты, то можете перенести эти строки в секцию eth1, на работу сервера это не повлияет.
DNS-сервера провайдера или публичные DNS следует указать в разделе Серверы пересылки внутреннего DNS-сервера на любом из контроллеров домена.
Если вы получаете сетевые настройки от провайдера по DHCP, то для использования внутренних серверов имен, вместо DNS провайдера секция eth0 должна иметь вид:
1auto eth0
2 iface eth0 inet dhcp
3 dns-search interface31.lab
4 dns-nameservers 192.168.31.101 192.168.31.102
Таким образом явно указанные настройки перекроют полученные автоматом от провайдера.
Сохраняем содержимое файла, перезагружаемся. Проверяем наличие интернета на сервере и разрешение имен. Например, выполните команду:
1nslookup srv-dc02
Ответить вам должен первый указанный доменный сервер имен, в нашем случае 192.168.33.101 и выдать полное FQDN-имя хоста и его IP-адрес.
1nslookup ya.ru
Вы также должны получить ответ от внутреннего сервера. На этом настройку сети можно считать законченной.
Настройка NAT и брандмауэра
Базовая настройка брандмауэра принципиально ничем не отличается от варианта роутера для рабочей группы, за одним исключением. Так как наш прокси является непрозрачным, то существует возможность выхода напрямую через NAT, если по какой-то причине браузер не будет настроен на работу с прокси-сервером. Поэтому ограничим доступ по HTTP (порт 80) для всех клиентов локальной сети, за исключением серверов и отдельных хостов, которым может потребоваться прямой доступ.
Мы считаем, что прокси-сервер нужен в первую очередь для контроля пользователей, поэтому заворачивать на него сервера и служебные хосты, которые не предоставляют доступ к интернет пользователям, не видим никакого смысла.
Создадим и откроем файл /etc/nat
1touch /etc/nat
внесем в него следующее содержимое:
1#!/bin/sh
2
3# Включаем форвардинг пакетов
4echo 1 > /proc/sys/net/ipv4/ip_forward
5
6# Сбрасываем настройки брандмауэра
7iptables -F
8iptables -X
9iptables -t nat -F
10iptables -t nat -X
11
12# Разрешаем доступ из локальной сети
13iptables -A INPUT -i eth1 -j ACCEPT
14
15# Разрешаем инициированные нами подключения извне
16iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
17
18# Разрешаем подключения по SSH
19iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
20
21#Запрещаем входящие извне
22iptables -A INPUT -i eth0 -j DROP
23
24# Разрешаем инициированные нами транзитные подключения извне
25iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
26
27#Разрешаем HTTP серверам
28iptables -A FORWARD -i eth1 -s 192.168.31.101 -p tcp --dport 80 -j ACCEPT
29...
30iptables -A FORWARD -i eth1 -s 192.168.31.105 -p tcp --dport 80 -j ACCEPT
31
32#Запрещаем HTTP
33iptables -A FORWARD -i eth1 -p tcp --dport 80 -j DROP
34
35# Запрещаем транзитный трафик извне
36iptables -A FORWARD -i eth0 -o eth1 -j DROP
37
38# Включаем NAT
39iptables -t nat -A POSTROUTING -o eth0 -s 192.168.31.0/24 -j MASQUERADE
Секция #Разрешаем HTTP серверам подразумевает набор идентичных правил для каждого хоста, которому мы разрешаем выход в интернет в обход прокси. В нашем случае это адреса от 192.168.31.101 до 192.168.31.105, чтобы не загромождать пример мы написали первый и последний, разделив их многоточием (которого в реальном конфиге быть не должно).
Сохраним файл и дадим ему права на исполнение:
1chmod +x /etc/nat
Перезагрузимся:
1reboot
После чего можно проверить интернет на клиентах, на тех, которые входят в список исключений - он будет, на остальных нет. Другие протоколы: почта (SMTP, POP3, IMAP), FTP, HTTPS и т.п. должны работать на всех клиентах.
Настройка синхронизации времени
Для успешной работы с доменом Active Directory и прохождения Kerberos-аутентификации важно чтобы часы роутера были синхронизированы с часами контроллера домена.
Установим NTP-клиент:
1apt-get install ntp
Затем откроем файл конфигурации /etc/ntp.conf и закомментируем все строки, начинающиеся на server. После чего добавим две свои записи:
1server srv-dc01.interface31.lab
2server srv-dc02.interface31.lab
Как вы уже, наверное, догадались, мы закомментировали записи сторонних серверов времени и добавили в этом качестве контроллеры домена.
1interface ignore wildcard
2interface listen eth1
Сохраняем файл и перезапускаем службу:
1service ntp restart
Чтобы убедиться, что NTP работает только на внутреннем интерфейсе, выполните:
1ss -l | grep 123
В выводе команды должны быть только внутренние адреса и адреса локальной петли (localhost):
Проверить синхронизацию можно командой:
1ntpq -p
В выводе обращаем внимание на колонки: when -время с последнего ответа сервера, pool - время опроса сервера, offset - разница времени в секундах.
Если ваш роутер расположен в виртуальной среде, то при загрузке, пока система не знает с кем синхронизировать время, время внутри виртуальной машины синхронизируется с временем гипервизора. Поэтому либо отключите эту функцию в настройках виртуальной машины, либо синхронизируйте часы гипервизора с часами домена.
Настройка кеширующего прокси-сервера Squid3
Внимание! Если вы перенастраиваете сервер для рабочей группы, то обязательно удалите пакет dnsmasq или иные DNS и DHCP сервера!
Важно! Начиная с Debian 9 и Ubuntu 16.04 вместо пакета squid3 снова используется squid, также аналогичным образом следует изменить все пути, т.е. вместо**/etc/squid3** использовать /etc/squid.
Установим прокси-сервер squid3 командой:
1apt-get install squid3
Откроем конфигурационный файл /etc/squid3/squid.conf и зададим минимальную конфигурацию, добавив или раскомментировав в соответствующих секциях указанные строки.
Укажем acl элемент для локальной сети:
1acl localnet src 192.168.31.0/24
Минимальный набор списков доступа:
1http_access allow localnet
2http_access allow localhost
3http_access deny all
Интерфейсы, порты и режимы работы прокси:
1http_port 192.168.31.100:3128
2http_port 127.0.0.1:3128
Настройки кеша:
1cache_mem 1024 MB
2maximum_object_size_in_memory 512 KB
3
4cache_dir ufs /var/spool/squid3 2048 16 256
5
6maximum_object_size 4 MB
Настройки лога:
1access_log daemon:/var/log/squid3/access.log squid
2logfile_rotate 31
Для squid 3.1 и ниже первая строка должна выглядеть так:
1access_log /var/log/squid3/access.log squid
Сохраните и проверьте конфигурацию:
1squid3 -k check
Если нет ошибок, то перезапускаем squid:
1service squid3 restart
Перестраиваем кэш:
1service squid3 stop
2squid3 -z
3service squid3 start
На DNS-сервере домена добавьте A-запись для нашего роутера:
Теперь в настройках браузера укажите полное FQDN имя сервера и порт 3128:
Так как никаких ограничений пока не установлено, то вы должны получить доступ в интернет.
На этом базовую настройку будем считать законченной. Следующим этапом будет настройка Kerberos-аутентификации и автоматического распространения настроек прокси, о чем мы расскажем в следующей статье.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе
"Архитектура современных компьютерных сетей"
вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов.
На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще: