Linux настройка роутера nat dhcp squid

Обновлено: 08.01.2025

Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3

Более четырех лет назад мы опубликовали материал посвященный настройке роутера на базе Ubuntu Server. Тема оказалась весьма востребованной и популярной, но за прошедшее время некоторые настройки успели измениться, пусть и незначительно. В связи с этим мы решили вернуться к этой теме и опубликовать современную версию популярной статьи.

Мы не будем подробно останавливаться на установке системы и назначении тех или иных компонентов, об этом достаточно сказано в исходном материале, а уделим основное внимание отличиям в современных версиях Ubuntu Server и настраиваемых пакетах.

Настройка сети

В нашем примере внешний сетевой интерфейс - eth0 - имеет статические настройки, если же вы используете PPPoE или PPTP подключение, то для настройки подключения рекомендуем воспользоваться нашими материалами:

Начиная с версии 12.04 (мы рассматриваем только LTS версии и крайне не рекомендуем использовать на серверах промежуточные релизы) все сетевые настройки, в том числе и DNS-сервера указываются в одном месте, конфигурационном файле /etc/network/interfaces. Перед тем как приступать к настройке повысим права до суперпользователя:

затем откроем файл в штатном редакторе nano, работа с ним далека от удобства, но для изменения нескольких строк он вполне подойдет:

Приведем его к следующему виду (настройки внешнего интерфейса приведены исключительно для примера):

Для указания DNS-серверов теперь используется директива dns-nameservers, если серверов несколько, они указываются в одну строку, через пробел.

Если вы получаете сетевые настройки от провайдера по DHCP, то настройки будут иметь вид:

Последней строкой идет автоматическая загрузка правил iptables из файла /etc/nat, который мы создадим позже.

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

Представлять двухпанельный менеджер с удобным редактором Midnight Commander (mc) мы думаем не нужно, как и SSH-сервер, дающий возможность удаленного администрирования.

Настройка NAT и брандмауэра

Технология сетевой трансляции адресов - NAT - позволяет организовать выход в интернет компьютеров локальной сети через один сетевой адрес. Данная технология абсолютно прозрачна для клиентских устройств и способна работать с любыми сетевыми приложениями и протоколами. За функции NAT в Ubuntu отвечает сетевой фильтр iptables, который предоставляет также функции брандмауэра.

В зависимости от политики сетевой безопасности существуют различные подходы к настройке брандмауэра. Мы предпочитаем задавать только базовые правила, исходя внутри сети из принципа: все что не запрещено - разрешено. Это позволяет свободно работать любым сетевым службам во внутренней сети и без помех выходить в интернет, обеспечивая при этом достаточный уровень безопасности. Для внешней сети запрещено все, что не разрешено и доступ к сетевым службам администратор должен разрешать явно.

Создадим файл настроек:

и внесем в него следующее содержимое:

Сохраним изменения и дадим нашему файлу права на исполнение:

Теперь если вручную задать сетевые настройки для рабочей станции, указав в качестве шлюза наш роутер и любой доступный DNS-сервер, то не ней должен появиться доступ в интернет.

Настройка DHCP и кэширующего DNS

В принципе мы уже можем использовать наш роутер по назначению, однако ручное указание сетевых настроек, это даже не вчерашний, а позавчерашний день, поэтому DHCP-сервер является неотъемлемой частью сетей любого размера. Также имеет смысл настроить собственный кэширующий DNS-сервер, который не только снизит нагрузку на вышестоящие сервера и уменьшит время отклика, но также позволит создавать собственные записи для хостов внутренней сети, что может оказаться полезным при развертывании иных сетевых сервисов.

Все эти функции реализованы в одном пакете dnsmasq, который предельно прост в установке и настройке:

Функции кэширующего DNS-сервера становятся доступны сразу после установки и в настройке не нуждаются, однако следует явно указать интерфейсы, которые будет обслуживать dnsmasq. Для этого откроем файл /etc/dnsmasq.conf и изменим следующую строку (не забываем раскомментировать при необходимости):

Для настройки DHCP сервера достаточно указать диапазон пула адресов и срок аренды:

После чего хосты внутренней сети будут получать все сетевые настройки автоматически.

Настройка кэширующего прокси-сервера Squid3

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

Squid поддерживает кэширование двух типов, в оперативной памяти и на диске. Сегодня можно встретить рекомендации отказаться от дискового кэша, мол проще скачать объект заново, чем искать его на диске. Однако мы считаем, что разумный размер дискового кэша при большом количестве клиентов позволяет эффективно использовать канал за счет хранения в кэше статических элементов: картинок, скриптов, CSS-файлов для часто посещаемых ресурсов.

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

Но все преимущества Squid раскрываются тогда, когда появляется необходимость тонкой фильтрации трафика, здесь богатые возможности позволяют реализовывать самые разнообразные схемы, которые просто невозможно рассмотреть в рамках одного материала, получить все материалы по данной теме вы можете выполнив поиск по тегу squid.

Внимание! Начиная с Debian 9 и Ubuntu 16.04 вместо пакета squid3 снова используется squid, также аналогичным образом следует изменить все пути, т.е. вместо /etc/squid3 использовать /etc/squid.

Для установки squid выполните команду:

Перейдем к настройкам. Для новичка конфигурационный файл squid может показаться излишне сложным, на самом деле большую часть его занимают подробные комментарии и примеры. Поэтому мы пойдем по файлу от начала к концу, указывая какие строки надо добавить или изменить. Откроем файл конфигурации /etc/squid3/squid.conf и перейдем к указанию группы доступа (acl) для локальной сети. Раскомментируем и исправим или добавим ниже строку:

Затем, спускаясь далее по конфигурационному файлу найдем секцию отвечающую за правила доступа и убедимся, что она содержит следующие правила:

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

Теперь укажем порт, интерфейс и режим работы прокси-сервера.

Параметр intercept указывает, что прокси работает в прозрачном режиме, т.е. не требует прямого указания прокси на клиентах.

Перейдем к указанию параметров кэша. Зададим доступный объем памяти и укажем максимальный объем кэшированного объекта в памяти:

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

После чего укажем размер дискового кэша и его расположение:

Размер кэша указывается в МБ, в нашем случае 2048 МБ - 2 Гб, следующие два числа указывают количество директорий первого и второго уровня, рекомендуем оставтить эти параметры без изменения.

Следующий параметр задает максимальный размер объекта в дисковом кэше:

Далее по файлу укажем место хранения логов и количество ротаций:

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

Внимание! В Ubuntu Server 12.04 (Squid 3.1) указанная выше строка должна иметь вид: access_log /var/log/squid3/access.log squid

Остальные параметры оставляем без изменений, сохраняем файл настроек.

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

Если команда отрабатывает без вывода - ошибок нет, в противном случае изучаем вывод и исправляем допущенные ошибки. После этого перезапустим службу, чтобы применить внесенные изменения.

В том случае, когда были изменены параметры кэша следует его перестроить:

Сохраняем изменения, перезагружаем сервер.

Обращаем ваше внимание, что squid3 в прозрачном режиме, в отличие от предыдущей версии, не принимает соединения, если в настройках прямо указано использование прокси.

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

Наиболее частым применением Linux серверов является организация общего доступа в интернет. Это обусловлено низкой стоимостью такого решения и невысокими требованиями к железу. Во многих случаях это бывает первый Linux сервер в организации, что способно вызвать у администраторов определенные сложности. В данной статье мы пошагово рассмотрим настройку роутера (NAT + DHCP + Squid) на базе Ubuntu Server 9.04

Внимание! Данный материал устарел, при настройке роутера на базе Ubuntu Server 12.04 и старше рекомендуем воспользоваться обновленной статьей.

Установка и первоначальная настройка

Если же это ваш первый сервер, то лучше всего продолжить не выбирая никакого варианта, все необходимые пакеты мы установим позже. Это позволит иметь более четкое представлении о назначении того или иного пакета и позволит успешно справляться с возможными неполадками. По окончании установки система перезагрузится и встретит нас черным экраном командной строки. Непривычного к консоли Windows-администратора это может неприятно удивить, однако ситуация на сегодняшний день такова, что все серверные роли Linux настраиваются исключительно через консоль и файлы конфигурации.

В первую очередь настроим сетевые соединения. Вводим в консоли:

Эта команда откроет в консольном редакторе nano конфигурационный файл с сетевыми интерфейсами, аналогичный рисунку ниже.

Пока там прописан единственный интерфейс eth0, настроенный на работу по DHCP. К eth0 у нас подключен ADSL модем (или любая сеть провайдера), а eth1 смотрит во внутреннюю сеть. IP адрес на внешнем интерфейсе 192.168.1.2, шлюз (ADSL модем) 192.168.1.1, внутренняя сеть лежит в диапазоне 10.0.0.1 - 254. Тогда настройки будут выглядеть следующим образом:

Сохраняем изменения Ctrl+O и выходим Ctrl+X. Теперь нужно настроить DNS, для этого выполняем:

В этом файле необходимо указать адреса DNS серверов, лучше всего указать DNS провайдера или, как в нашем случае, OpenDNS.

Сохраняем. Теперь нужно перезапустить сетевые службы (либо перезагрузиться):

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

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

Теперь установим Midnight Commander (mc), файловый менеджер по образу и подобию Norton Commander или Far:

Для запуска Midnight Commander достаточно набрать в консоли его краткое имя: mc. Сразу рекомендуем включить встроенный редактор, более удобный чем nano: F9 - Настройки - Конфигурация - Встроенный редактор.

Для удаленного управления сервером (не бегать же к нему каждый раз) установим OpenSSH, что позволит подключаться к нему из любого места, даже из дома, по защищенному протоколу:

Для подключения с Windows станций можно использовать программу PuTTY (скачать), для корректного отображения символов перед подключением необходимо на закладке Window - Translation выбрать кодировку UTF8.

Для ограничения доступа к серверу можно дописать в файл /etc/ssh/sshd_config параметр AllowUsers с указанием пользователя имеющего доступ по SSH, например для пользователя admin:

Также можно разрешить доступ определенной группе пользователей используя параметр AllowGroups, либо запретить доступ определенным пользователям / группам использовав DenyUsers и DenyGroups.

Настраиваем NAT

Для организации общего доступа к интернет необходимо настроить трансляцию сетевых адресов (NAT), что позволит сетевым службам внутренней сети получать доступ к внешней сети. Для этого достаточно выполнить всего одну команду, но есть одна тонкость: все будет работать только для перезагрузки. На настоящий момент в Linux нет механизма, который бы сохранял настойки iptables при перезагрузке сервера или сети. Поэтому мы пойдем другим путем и вынесем эти настройки в отдельный скрипт, запускаемый при загрузке системы. Сначала создадим файл скрипта:

Потом откроем его в редакторе Midnight Commander (F4) и внесем следующий текст:

Сохраняем (F2), для автоматического запуска скрипта снова открываем /etc/network/interfaces и в самый конец файла дописываем:

Также не забываем дать нашему скрипту права на исполнение:

Если нигде не допущено ошибок все должно работать. Для проверки укажем на машинах внутренней сети в качестве шлюза и DNS адрес нашего роутера: 10.0.0.1 и пропингуем любой внешний адрес, например один из OpenDNS серверов: 208.67.222.222. Но интернет пока работать не будет. Почему? Да потому, что мы указали в качестве DNS сервера наш роутер, который пока таковым не является. Можно конечно явно прописать DNS на клиентской машине,однако, это не наш метод, если вдруг DNS сервера изменятся, нам что, бегать перепрописывать?

После установки открываем /etc/dnsmasq.conf, находим, раскомментируем и изменяем следующим образом строку, чтобы разрешить серверу принимать DNS запросы из внутренней сети.:

Перезапускаем DNS сервер:

После чего на клиентских машинах должен заработать интернет.

Настраиваем DHCP

Теперь, когда наш сервер работает, нужно настроить клиентские машины. Можно, конечно, прописать все параметры вручную, но как быть если клиентских машин много и расположены они по всему зданию? Здесь нам на выручку приходит протокол DHCP, который позволяет клиентским машинам получать сетевые настройки автоматически. В качестве DHCP сервера выступит уже установленный Dnsmasq. Настроить его не просто, а очень просто, для чего снова открываем /etc/dnsmasq.conf.

Все что нам надо, это задать диапазон выдаваемых адресов (в нашем случае 10.0.0.100-150), сетевую маску и время, на которое выдается IP адрес:

Адреса DNS сервера и шлюза сервер берет автоматически из системных настроек. Еще раз перезапускаем Dnsmasq:

Теперь можно выставить на клиенте автоматическое получение IP адреса и убедиться, что все работает нормально.

Просмотреть выданные адреса можно командой:

В выдаче будут перечислены выданные IP адреса и MAC адреса которым они выданы.

Настраиваем кеширующий прокси-сервер Squid

В любой большой сети определенная часть трафика повторяется от пользователя к пользователю и порой его доля доходит до 50%. Логично бы было кешировать наиболее повторяющиеся запросы и тем самым снизить нагрузку на канал, сэкономить входящий трафик и ускорить выдачу страниц конечному пользователю. Для этих задач мы используем Squid - кеширующий прокси с широчайшими возможностями.

Останавливаем прокси-сервер и приступаем к настройке:

Открываем /etc/squid/squid.conf, находим и корректируем следующие строки, не забыв их раскомменитровать:

Указываем порт и адрес на котором squid будет принимать соединения:

Указываем внутренние сети, лишние комментируем:

Разрешаем доступ из внутренних сетей (найти и раскомменитровать):

Устанавливаем лимит использования памяти:

Задаем язык вывода ошибок для пользователя

Важное замечание! В Ubuntu 9.10 эта строка может выглядеть так, рекомендуем проверить правильность пути: error_directory /usr/share/squid/errors/ru

Сохраняем файл конфигурации. Теперь строим кэш и запускаем:

Частым применением Linux серверов является организация общего доступа в интернет. Это обусловлено низкой стоимостью такого решения и невысокими требованиями к железу. Во многих случаях это бывает первый Linux сервер в организации, что способно вызвать у администраторов определенные сложности. В данной статье мы пошагово рассмотрим настройку роутера (NAT + DHCP + Squid) на базе Ubuntu Server

Установка Ubuntu Server и первоначальная настройка

Ubuntu Server отличается от своей настольной версии отсутствием графической оболочки и пользовательских приложений, а также возможностью предустановки заранее выбранных ролей сервера. Несмотря на это, все сказанное будет справедливо для любой версии Ubuntu и, с некоторыми поправками, для любого Linux дистрибутива. Установка Ubuntu Server происходит в текстовом режиме на русском языке и, как правило, не вызывает сложностей. Отдельно стоит только остановится на списке ролей: из предложенного нас, пожалуй, может заинтересовать только OpenSSH, для удаленного доступа, однако воспользовавшись пунктом Manual package selection опытный пользователь может сразу установить необходимые ему пакеты.
Если же это ваш первый сервер, то лучше всего продолжить не выбирая никакого варианта, все необходимые пакеты мы доустановим позже. Это позволит иметь более четкое представлении о назначении того или иного пакета и позволит успешно справляться с возможными неполадками. По окончании установки система перезагрузится и встретит нас черным экраном командной строки. Непривычного к консоли Windows-администратора это может неприятно удивить, однако ситуация на сегодняшний день такова, что все серверные роли Linux настраиваются исключительно через консоль и файлы конфигурации.

Настройка сети

В первую очередь настроим сетевые соединения. Вводим в консоли:

Сохраняем изменения Ctrl+O и выходим Ctrl+X. Теперь нужно настроить DNS, для этого выполняем:

Сохраняем. Теперь нужно перезапустить сетевые службы (либо перезагрузиться):

Собственно сеть настроена, можно переходить к следующему этапу, однако мы рекомендуем установить еще несколько пакетов для удобства администрирования.

Обновление пакетов Ubuntu

Сначала обновим список доступных пакетов:

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

Установка дополнительных пакетов

Теперь установим Midnight Commander (mc), файловый менеджер по образу и подобию Norton Commander или Far:

Настройка SSH

Ограничение доступа к серверу

Для ограничения доступа к серверу можно дописать в файл /etc/ssh/sshd_configпараметр AllowUsers с указанием пользователя имеющего доступ по SSH, например для пользователя admin:

Настрайка NAT

Потом откроем его в редакторе Midnight Commander (F4) и внесем следующий текст:

Сохраняем (F2), для автоматического запуска скрипта снова открываем/etc/network/interfaces и в самый конец файла дописываем:

Также не забываем дать нашему скрипту права на исполнение:

Перезапускаем DNS сервер:

После чего на клиентских машинах должен заработать интернет.

Настройка DHCP

Теперь, когда наш сервер работает, нужно настроить клиентские машины. Можно, конечно, прописать все параметры вручную, но как быть если клиентских машин много и расположены они по всему зданию? Здесь нам на выручку приходит протокол DHCP, который позволяет клиентским машинам получать сетевые настройки автоматически. В качестве DHCP сервера выступит уже установленныйDnsmasq. Настроить его не просто, а очень просто, для чего снова открываем/etc/dnsmasq.conf.

Адреса DNS сервера и шлюза сервер берет автоматически из системных настроек. Еще раз перезапускаем Dnsmasq:

Просмотреть выданные адреса можно командой:

В выдаче будут перечислены выданные IP адреса и MAC адреса которым они выданы.

Кэширующий прокси-сервер Squid

Останавливаем прокси-сервер и приступаем к настройке:

Открываем /etc/squid/squid.conf, находим и корректируем следующие строки, не забыв их раскомменитровать:

Указываем внутренние сети, лишние комменитруем:

Разрешаем доступ из внутренних сетей (найти и раскомменитровать):

Устанавливаем лимит использования памяти:

Важное замечание! В Ubuntu 9.10 эта строка может выглядеть так, рекомендуем проверить правильность пути:

Сохраняем файл конфигурации. Теперь строим кэш и запускаем:

Решения на базе Squid пользуются заслуженной популярностью у системных администраторов как мощное и гибкое средство контроля за интернет трафиком. Отдельного внимания заслуживают богатые возможности фильтрации, позволяющие ограничить доступ для определенных групп пользователей к нежелательным интернет ресурсам. Широкое внедрение шифрования в последние годы сделало процесс фильтрации несколько затруднительным, но и здесь Squid придет нам на помощь, как это сделать мы расскажем в этой статье.

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

Настройка сети

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

Для настройки сети откроем файл /etc/network/interfaces:

И внесем в него следующие изменения (названия интерфейсов и адреса указаны только для примера):

Если внешний интерфейс получает настройки по DHCP, то используйте следующие настройки:

Сразу создадим файл для хранения настроек брандмауэра и сделаем его исполняемым:

После чего у вас на сервере должен появиться интернет, сразу следует обновить систему и установить необходимый минимум утилит для администрирования:

Настройка NAT и брандмауэра

Существуют разные взгляды на настройку брандмауэра, но общепринятой является схема с нормально открытым брандмауэром для внутренней сети (разрешено все, что не запрещено) и нормально закрытым для внешней (запрещено все, что не разрешено). Ниже будет приведена минимально достаточная конфигурация.

Откроем созданный нами файл /etc/nat и внесем в него следующие строки:

Чтобы применить изменения просто запустим измененный файл:

Убедиться, что правила применились мы можем командами:

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

Настройка DHCP и кеширующего DNS

В наших решениях эту роль обычно исполняет dnsmasq, не будем отступать от традиций и в этот раз. Установим данный пакет:

Для настройки откроем файл /etc/dnsmasq.conf и внесем некоторые изменения. Прежде всего ограничим адреса, которые будут слушать наши службы:

Затем зададим пул для выдачи адресов через DHCP и срок аренды:

Для одноранговой сети будет неплохо указать DNS-суффикс, чтобы избежать сложностей с разрешением плоских имен:

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

Просмотреть список выданных в аренду адресов можно командой:

Настройка прокси-сервера Squid3 с поддержкой SSL

К сожалению, в репозиториях нет пакета squid с поддержкой SSL, поэтому потребуется собрать его самому, как это сделать мы рассказывали в статье Сборка Squid 3.5 с поддержкой SSL из исходных кодов для Debian / Ubuntu, поэтому будем считать, что вы уже выполнили эту процедуру, либо используете уже собранные нами пакеты.

Будем считать, что собранные пакеты squid скачаны и располагаются в отдельной директории. Перейдем в нее и установим пакеты командой:

Чтобы наши пакеты не были перезаписаны пакетами из репозитория при обновлении их следует зафиксировать:

Если у вас был уже установлен squid, то просто удалите его и установите наши пакеты, все настройки при этом будут подхвачены автоматически, хотя на всякий случай сохраните куда-нибудь файл конфигурации:

Установив пакеты с поддержкой SSL, перейдем к конфигурированию нашего прокси. Для этого откроем файл /etc/squid/squid.conf, все указанные ниже опции надо либо найти и раскомментировать, приведя к указанному виду, либо создать.

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

В нем мы должны изменить только опцию acl localnet src - указав диапазон собственной локальной сети.

Затем добавим несколько своих списков, прежде всего укажем диапазон адресов офисных ПК, которые мы раздаем по DHCP, это будут основные кандидаты на применение к ним правил фильтрации:

Затем идет элемент со списком значений "черного списка", который хранится в виде regex-выражений в файле /etc/squid/blacklist:

Также помните, что фильтровать защищенные соединения мы можем только по имени домена, никакие параметры URL учитываться не будут. Для того, чтобы заблокировать домен часто используют следующее выражение:

Для проверки созданных вами регулярных выражений мы рекомендуем использовать онлайн-сервис Regex101.

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

Которое запретит для всех ПК офиса доступ к ресурсам перечисленным в черном списке. Далее следует стандартный набор списков доступа:

Это самый простой вариант, но тем не менее достаточный в качестве примера.

Теперь укажем порты для работы с шифрованным и нешифрованным трафиком, для прозрачного режима это должно выглядеть так:

Ниже укажем ряд необходимых опций:

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

Зададим черный список для SSL:

Как было сказано выше, мы будем использовать раздельные списки, данный список будет хранится в файле /etc/squid/blacklist_ssl и также содержать регулярные выражения, описывающие блокируемые домены.

А теперь укажем, что делать с защищенным трафиком:

Действие peek "заглядывает" в соединение на указанную нами глубину, terminate блокирует соединения по совпадению условий (черный список + офисный диапазон адресов) и наконец splice разрешает все остальные соединения, не вмешиваясь в них.

Следующая опция также необходима для работы squid с SSL:

Также обязательно укажем DNS-сервер, который следует использовать squid, он должен обязательно совпадать с DNS-сервером, используемым клиентами, в нашем случае это dnsmasq, в доменной сети следует указать доменные DNS:

Ниже приведены параметры кеша:

И настройка логов:

В нашем случае используется 7 ротаций (неделя), поэтому установите нужное вам значение.

Сохраняем конфигурационный файл, но не будем пока перезапускать squid, так как у нас отсутствуют некоторое объекты, перечисленные в конфигурации. Прежде всего создадим файл черного списка:

Либо можем скопировать уже существующий:

Для примера мы заблокировали две популярные соцсети использовав следующие записи:

Затем создадим сертификат для squid:

Так как он нужен сугубо для прокси и ни на что не влияет, то мы указали срок его действия в 10 лет, что позволит забыть о нем в обозримом будущем (с учетом того, что про него и так забудут).

Вот теперь можем проверить конфигурацию:

Остановим прокси, перестроим кеш (так как мы изменили его параметры) и запустим заново:

Если вы используете прозрачный режим, то в конец файла /etc/nat добавьте следующие строки:

Для непрозрачного режима следует настроить WPAD, для автоматической настройки параметров прокси на клиентах (прописывать настройки руками в 21 веке дурной тон).

Проверим доступ к запрещенному ресурсу, как видим - все работает:

Ошибка "local IP does not match any domain IP"

Коротко суть проблемы состоит в следующем: один и тот же ресурс на клиенте и на сервере разрешается в разные IP-адреса, этому в основном подвержены крупные ресурсы, имеющие несколько адресов для одного домена, а также сайты, использующие различные CDN (например, CloudFlare). Для squid такая ситуация равносильна попытке подмены заголовка, и он разрывает соединение.

Некоторые инструкции в сети советуют при сборке наложить патч client_side_request.patch, который по сути вернет уязвимость обратно. Заявления автора патча, что он не несет угрозы безопасности с отсылкой к одному из разработчиков squid не совсем верно отражают суть проблемы. Действительно, данная уязвимость никак не отражается на безопасности самого прокси-сервера, она позволяет клиентам, при определенных условиях, обойти его систему контроля доступа.

Как избежать данной ситуации? Использовать общий DNS-сервер как для клиента, так для прокси-сервера, мы обращали на это ваше внимание при описании соответствующей опции. Но не все так просто, ситуацию осложняет локальный DNS-кеш, который присутствует на любом клиенте и может содержать иную запись, нежели локальный кеш сервера. И добиться полной синхронизации кешей будет довольно сложно.

Однако данная проблема встречается не так часто, поэтому вполне будет достаточно очистить клиентский кеш и начать использовать общий DNS-сервер, но 100% гарантией избавления от проблемы это не будет.

Как решить вопрос окончательно? Ответ прост: не использовать прозрачный режим. Если трезво глянуть на ситуацию, то его достоинства по большей части преувеличены, у прозрачного прокси нет никаких существенных преимуществ, кроме простоты настройки. Протокол WPAD не только позволяет автоматически настраивать параметры прокси на клиентах, но и предоставляет большую гибкость в определении того, какой трафик пускать через прокси, а какой напрямую, прост во внедрении и поддерживается всеми типами клиентов.

Надеемся, что данная статья окажется вам полезна и поможет начать эффективно фильтровать защищенные соединения при помощи прокси-сервера squid.

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