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

Его проблема в том что он работает годами и лазить в него практически не приходится, а то с чем давно не сталкивался, имеет обыкновение забываться.
Вот я и решил обновить статью, которая будет являться заготовкой для написания последующих материалов. На написание этой статьи меня натолкнула недавняя подработка.
Собственно история: Попросили меня помочь в одной конторе, в которой было 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.
На этом все, возникли вопросы/дополнения прошу в комментарии, нашли ошибку пишите в личку…
22 комментария
Конечно можно, на шлюзе разрешаете маршрутизацию пакетов только от IP адреса сервера на котором крутится squid, от остальных блокируете, тогда все пользователи получат отлуп.
$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
Убрать forward? Ещё, в локальной сети есть nas, он так же имеет доступ в интернет (торрент), его так же придётся пускать через прокси? На клиентах, иногда запускают торрент-качалки, так же не будут работать? Если такой вариант, не пускать любые браузеры на компьютерах к порту 80(443), а только через прокси?
Чтобы NAS нормально подключался к интернет, а другие нет, то можно разрешить маршрутизацию пакетов в интернет только для определенных IP, а остальным запретить.
Давайте я не буду для вас писать готовое правило, просто сядьте и разберитесь с iptables там не сложно, просто придется потратить несколько сасов на освоение, но в дальнейшем вопрос будет решаться сам намного быстрее.
Т.е. без маскарадинга никак не получается. Хотел тоже самое сделать, но используя mac-адрес NAS, но в POSTROUTING его нельзя использовать (только ip), а в PREROUTING не получается. В других цепочках как я понял, нет смысла использовать mac-адрес и так всё разрешено.
Если у вас это домашняя система, то какой смысл ставить прокси?!