avatar Ubuntu Настройка Squid прокси-сервера + поддержка IPv6 на Ubutnu

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

Собственно история: Попросили меня помочь в одной конторе, в которой было 40 рабочих мест, проблема была в том, что у некоторых сотрудников периодически пропадает интернет, прямо мистика, причем отрубает пользователей в случайном порядке т.е. закономерности им найти не удалось и если 10 мин назад все работало, то после этого может и не пахать, самое обидное что отключает генерального директора, а он такой «несправедливости» стерпеть не мог, как так подчиненные с интернетом, а он нет- не порядок. Похожая ситуация у меня уже была на позапрошлой работе. Придя на место, я обнаружил своего старого знакомого Cisco PIX 501
Фото героя я сделать не удосужился, но на просторах интернета фотку нашел:

Сам агрегат, довольно старый и уже снят с поддержки, но работает до сих пор, и слава богу. Правда он имеет одну отвратительную особенность, а именно-необходимость покупки лицензий на подключение, верх жлобства от Cisco, весь фокус в том что 20 подключений уже включены в прошивку, чтобы снять этот досадный недостаток, нужно заплатить деньги, соответственно, у нас имеется 40 рабочих мест + 4 сервера и того 44 коннекта и тут маршрутизация начинает работать по принципу «Кто первый встал, того и тапки». В прошлый раз проблема была решена довольно легко, я перенаправил пользовательские запросы через прокси-сервер, тогда пользователи будут подключаться через 1 IP адрес, у фирмы был куплен Windows Small Business Server 2003, в котором идет ISA 2004, я установил ее, завернул пользователей домена на работу через прокси-сервер (через групповые политики) и жизнь наладилась. Тут проблема была другая ни ISA ни TMG у конторы куплено не было, а «пиратствовать» мне не хотелось, хотя возможность была. Дополнительным мотивам, в отказе от установки ISA, был предыдущий опыт т.к. после установки, а ставится она в редакции SBS прямо на 1 сервер вместе с контроллером домена, было возникновение непонятных глюков системы с зависаниями и прочими непонятными эксцессами.
В общем, ISA в топку, ставим SQUID, не поймите меня не правильно, ISA и TMG отличные продукты и на отдельно стоящих серверах работают отлично, для тех кто умеет их готовить, но ставить их на контроллеры домена-верх маразма, однако в MS Windows SBS 2003 именно так и предлагается, но тут ни SBS ни других лицензий на Windows Server куплено не было. Выяснив что, требований по ограничению трафика пользователям и доступа к сайтам, у руководства компании нет (повезло людям с начальством), было принято решение взгромоздить виртуальный сервер Ubuntu, со SQUID на борту.
Собственно, идея проста, пользователи подключаются через прокси-сервер, а «прокся» пересылает запрос от своего имени, маршрутизатор видит только 1 IP адрес, в общем все довольны, пользователи пользуются интернетом через Squid, сервера ходят на прямую через PIX и того, в сухом остатке, получаем 4 сервера + прокся со SQUID = 5 использованных подключений, остается еще 15 свободных, а их можно использовать, например для подключения пользователей не из домена, например через WI-FI с операционными системами отличными от MS Windows (пользователи с гостевым доступом), но тут я уже окончательно разошелся… :)

Сформируем требования к прокси-серверу
Требования
Обязательно!
1) Обеспечение доступа в интернет.
2) Увеличение скорости загрузки страниц, путем их кеширования.
3) Легкий «тюнинг» страниц ошибок
4) Настройка доступа пользователей.
Опционально
5) Включение поддержки IPv6.

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

Для начала установим SQUID

sudo apt-get install squid3


Переходим к настройке конфигурационного файла.

nano /etc/squid3/squid.conf


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

Настраиванием кешивание


находим строку и снимаем с нее комментарий:

cache_dir ufs /var/spool/squid3 100 16 256


Настрока страницы ошибок

теперь нам необходимо добавить вывод станицы ошибок на русском языке, иначе пользователи будут бояться.
Добавляем вывод страницы на русском языке:
error_directory /usr/share/squid-langpack/Russian-1251

Но тут есть одна проблема, по умолчанию SQUID выводит на странице с ошибкой время в UTC, что отличается од Московского на 4 часа.
Страница ошибки, по умолчанию, выглядит так (вывод времени обведен красным):

В сети, многие советуют накладывать патчи на SQUID чтобы исправить этот недостаток, но все это ерунда, данная проблема устраняется довольно просто.
как многие из вас догадались, страницы ошибок лежат в:
/usr/share/squid-langpack/Russian-1251


От наст требуется настроить вывод локального времени самого сервера, а не в формате UTC. Открываем первый попавшийся файл, со страницей ошибк, и находим запись %T, нам ее нужно заменить на %t, тогда сервер будет выдавать страницы такого вида (изменения обведены красным):


Если требуется выводить или настроить вывод иных данных, то вы всегда можете посмотреть и в Wiki страниц ошибок

Включаем доступ для пользователей локальной сети
Теперь нам необходимо разрешить доступ в интернет, для пользователей локальной сети, доступ будет у нас предоставляться всем пользователям находящимся в подсети 192.168.1.0/24
Для этого находим блок:
#acl localnet src 10.0.0.0/24 # RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network

И добавляем туда блок IP адресов нашей подсети, чтобы выглядело так:
#acl localnet src 10.0.0.0/24 # RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.1.0/24 # RFC1918 possible internal network

Ну и разрешаем нашей подсети доступ, добавив запись:
http_access allow localnet


Перезапускаем SQUID чтобы изменения вступили в силу
/etc/init.d/squid3 restart


На клиентском ПК в настройках браузера вписываем адрес нашего прокси-серера и порт 3128, если работа происходит в Active Directory, то настройки клиентов можно накатить через групповые политики (на пользователя), если AD нету, то прописываем ручками каждому клиенту, в общем это уже организационные моменты, к теме статьи не относящиеся, но если открыть браузер и произвести настройки, то интернет должен работать. Нам осталось включить поддержку IPv6.

Настройка работы с IPv6

Тут вообще все просто, нам требуется установить пакет Miredo
sudo apt-get install miredo


И перезапустить SQUID, чтобы он увидел новый сетевой интерфейс:
/etc/init.d/squid3 restart


Теперь переходим к клиентскому ПК и пробуем перейти на сайт в IPv6 подсети и тут, внезапно, есть адрес ipv6.howitmake.ru заходим по адресу и если вы все сделали правильно, то видим версию данного сайта для сети IPv6.

На этом все, возникли вопросы/дополнения прошу в комментарии, нашли ошибку пишите в личку…
  • +1
  • avatar     

22 комментария

avatar
Здравствуйте! Можно ли сделать так чтоб пользователь не мог пользователь интернетом, пока не настроит использование прокси в браузере? Т.е. если по какой-то причине пользователь не хочет использовать мой прокси, интернета он не увидит вообще. Пока только запрет на изменение настроек прокси видится выходом, но не для каждого браузера можно это сделать. Оптимально, чтоб просто не работало без прокси. Спасибо!
avatar
Здравствуйте.
Конечно можно, на шлюзе разрешаете маршрутизацию пакетов только от IP адреса сервера на котором крутится squid, от остальных блокируете, тогда все пользователи получат отлуп.
avatar
У меня squid работает на 192.168.0.1, он же шлюз, dns и вообще всё. Т.е. в iptables прописать правило типа iptables -A FORWARD -s 192.168.0.1/24 -j ACCEPT. Сейчас у меня разрешён только сам интерфейс.
avatar
По сути в iptables правило forward, для пакетов, можно совсем убрать т.к. squid принимает соединения и возвращает ответ на запрос. Думаю тут нужно только добавить разрешающее правило input для доступа к порту который слушает suqid и dns
avatar
Фрагмент моих правил, касающиеся входящих и транзитных пакетов:
IPTABLES="/sbin/iptables"
IP6TABLES="/sbin/ip6tables"
...
LAN="br0"
LAN_IP4="192.168.0.0/24"
LAN_IP6="fe80::/10"
...
$IPTABLES  -P INPUT DROP
$IPTABLES  -P FORWARD DROP
$IPTABLES  -P OUTPUT ACCEPT
...
$IP6TABLES -P INPUT DROP
$IP6TABLES -P FORWARD DROP
$IP6TABLES -P OUTPUT ACCEPT
...
$IPTABLES  -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IP6TABLES -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
...
$IPTABLES  -A INPUT -i $LAN -j ACCEPT
$IPTABLES  -A INPUT -i lo -j ACCEPT
$IP6TABLES -A INPUT -i $LAN -j ACCEPT
$IP6TABLES -A INPUT -i lo -j ACCEPT
...
$IPTABLES  -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IP6TABLES -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
...
$IPTABLES  -A FORWARD -i $LAN -j ACCEPT
$IP6TABLES -A FORWARD -i $LAN -j ACCEPT
avatar
Ну удинственная цепочка у вас
avatar
$IPTABLES -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
$IP6TABLES -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -A FORWARD -i $LAN -j ACCEPT
$IP6TABLES -A FORWARD -i $LAN -j ACCEPT
Я так понял эти правила нужны чтобы прокидывать пакеты в br0 но я не вижу правил для NAT, уберите их, сам сервера может ходить наружу т.к. цепочка OUTPUT ACCEPT, а вот пользователи сети не смогут отправить пакеты и будут вынуждены идти через SQUID
avatar
NAT есть как обычно:
$IPTABLES -t nat -A POSTROUTING -o $WAN -j MASQUERADE

Убрать forward? Ещё, в локальной сети есть nas, он так же имеет доступ в интернет (торрент), его так же придётся пускать через прокси? На клиентах, иногда запускают торрент-качалки, так же не будут работать? Если такой вариант, не пускать любые браузеры на компьютерах к порту 80(443), а только через прокси?
avatar
Если убираю все четыре правила forward, теряю доступ к некоторым устройствам в локальной сети, если только первые две, то всё работает, за исключением тех (nas) у кого не настроен прокси. Может можно в первых двух цепочках перенаправлять соединения на squid? Извиняюсь за возможно глупые вопросы, опыта с iptables мало, только базовые и то по примерам которые почти везде есть, а шаг влево, шаг вправо вызывают вопросы.
avatar
Уберите
$IPTABLES -t nat -A POSTROUTING -o $WAN -j MASQUERADE

Чтобы NAS нормально подключался к интернет, а другие нет, то можно разрешить маршрутизацию пакетов в интернет только для определенных IP, а остальным запретить.
Давайте я не буду для вас писать готовое правило, просто сядьте и разберитесь с iptables там не сложно, просто придется потратить несколько сасов на освоение, но в дальнейшем вопрос будет решаться сам намного быстрее.
avatar
Я даже не знаю, какие действия нужно/можно выполнить, только общеизвестные примеры. Правильно ли я понял что нужно убрать все текущие forward, nat, перенаправить (forward) только на нужные мне клиенты (nas)?
avatar
Если у вас клиенты подключаются к NAS через br0 то правило FORWARD можно оставить, а вот NAT надо убрать.
avatar
Когда убираю NAT, c NAS'а не пингуется интернет. Не понимаю, как можно починить?
avatar
Я так понял, что на NAS'е тоже нужно прописывать прокси, так же как в браузерах на компьютерах…
avatar
Сделал так:
$IPTABLES -t nat -A POSTROUTING -s ip_адрес_NAS -j MASQUERADE

Т.е. без маскарадинга никак не получается. Хотел тоже самое сделать, но используя mac-адрес NAS, но в POSTROUTING его нельзя использовать (только ip), а в PREROUTING не получается. В других цепочках как я понял, нет смысла использовать mac-адрес и так всё разрешено.
avatar
Нет, маскарадинг нужен чтобы из вашей локальной подсети перенаправлять пакеты в интернет, тогда заголоках отправителя будет значиться ваш шлюз, соответственно для локальной сети маскарадинг не нужен, у вас настроен мост, а мост передает пакеты как есть, не меняя заголовки.
avatar
Дело в том что без маскарадинга, NAS не имеет интернет, он ему нужен для получения обновлений. А остальные клиенты работают в штатном режиме, на них ведь прокси прописан. В общем теряется функциональность и не ясно как её вернуть не используя маскарадинг.
avatar
Ещё, остаются устройства типа телевизоры со смарт-тв, медиаплееры. В них ведь прокси не настраивается, поэтому пускать их придётся напрямую, через маскарадинг?
avatar
да придется через маскарадинг.
Если у вас это домашняя система, то какой смысл ставить прокси?!
avatar
Банерорезка (privoxy), обход блокировки сайтов (tor+i2p), да и просто, хочу чтоб всё было под контролем.
avatar
какая-то сложная система получается, да и tor, высокой скоростью соединения, не радует.
avatar
Здравствуйте! На самом деле сложного ничего нет. Тор нужен только как прокси, внутренние ресурсы этой сети меня мало интересует, а как прокси (обход блокировок) работает замечательно, скорости хватает. Тем более тема отхода, в последнее время стала актуальной. Сейчас squid получил поддержку прозрачного режима, в итоге можно собрать полностью прозрачную схему с банерорезкой и автоматическим (список блок. ресурсов пополняется автоматом) обходим блокировок. Ну и i2p для общего развития. Тут подробнее (не сочтите за рекламу): sites.google.com/site/rpfteam/
Есть что добавить? Регистрируйся и оставляй комментарии!