Прозрачный Squid

Зачем нужен прозрачный Squid

Для начала представим, что у нас есть обычная сеть, выходящая в интернет через один шлюз (прокси-сервер Squid установлен здесь же). Предположим, IP-адрес шлюза 192.168.1.1 . Все остальные компьютеры в сети получают настройки IP по DHCP. Компьютеры в сети разные, Windows XP/7, Ubuntu, да моло ли еще какие. За всеми не углядишь. Но мы должны считать трафик, ускоряя при этом доступ в интерент, должны контролировать (хотя бы от «дурака») доступ в интернет и пр. Squid обладает широкими возможностями по логированию, ограничению доступа и пр. Поэтому нам нужно, чтобы все компьютеры в сети не могли миновать нашего прокси-сервера Squid. Поэтому нам надо в любом случае направить (завернуть, пробросить) запрос клиентских компьютеров только через прокси-сервер Squid.

Настройка переадресации портов

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

Переадресация портов в FreeBSD

Если на нашем шлюзе установлена FreeBSD и брандмауэр по-умолчанию — IPFW, то для выполнения этой задачи мы должны на шлюзе установить переадресацию (проброс) портов:

# Redirect to local proxy
/sbin/ipfw add 0170 fwd 127.0.0.1,3128 tcp from 192.168.1.0/24 to any 80

• 0170 — номер правила (в вашем случае может быть любой).
• fwd 127.0.0.1,3128 — куда будем направлять пакеты, — в нашем случае нашему любимому Squid, запущенному на порту 3128 на шлюзе, — .
• from 192.168.1.0/24 — . отправленные компьютерами локальной сети.
• to any 80 — . на какой-либо сайт в интернете

Теперь внимание! Это правило нужно добавить ДО того, как правила NAT (Network Address Translation) получат этот запрос. Объясню немного неакадемично: что делает NAT? В нашем случае NAT изменяет адрес источника (заменяет локальный IP клиента на внешний IP шлюза и запоминает, от какого внутреннего клиента был запрос. Для того, чтобы Squid обработал запрос от клиента, ему не нужно ничего преобразовывать — он и сам с этим справится. Поэтому Squid должен получить пакет в первозданном виде и сам решить, что делать дальше.

К тому же NAT и Squid — все-таки разные вещи, и пакет, адресованный, скажем к 2.3.4.5:80 , не содержит информации, как попасть в Squid (на порт 3128 шлюза). И пакет будет обрабатываться только средствами NAT. Squid пакет так и не увидит. Поэтому наша задача — просто отдать Squid-у тот пакет, который отправил броузер пользователя. Объясню на примере части конфига ipfw:

В конфиге выше запрос открыть сайт сначала обрабатывается правилом 0170 , которое заворачивает запрос в Squid. Squid (как и любая другая программа) также выполняет требования брандмауэра — только для него правило 0170 не действует, а вот правило 0350 разрешает Squid отправить запрос в интернет. Для того, чтобы выходить в интернет без Squid, необходимо закоментировать правило 0170 . В этом случае Squid не получит ничего, а все запросы броузеров из локальной сети будут обрабатываться правилом 0350 .

Переадресация портов в Linux

Если на нашем шлюзе установлена Linux и iptables, то вышеуказанная команда будет выглядеть так:

iptables -t nat -A PREROUTING -i eth0 -p tcp —dport 80 -j REDIRECT —to-port 3128

где eth0 — внутренний интерфейс.

В остальном смысл переадресаций и пр. аналогичен тому, как это объяснялось для ipfw . Разнятся только правила постороения конфигурационных файлов ipfw и iptables . Пример правил iptables можно изучить здесь.

С этим разобрались. Теперь надо дать указание Squid о том, что он должен обрабатывать пакеты, изначально на него не направленные. Переходим к включению режима прозрачности Squid.

Прозрачный Squid в squid.conf

Теперь дело осталось за малым — настроить Squid в режим невидимки, т.е. принимать автоматически перенаправленные пакеты и обрабатывать их. В разных версиях Squid за это отвечали разные команды. Настройка Squid версии 2.6.* выглядит так:

http_port 127.0.0.1:3128 transparent # Squid работает в прозрачном режиме

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

http_port 3128 # Squid работает в обычном режиме

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

Плюсы и минусы

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

Из минусов можно отметить:

• невозможность (по-крайней мере, простым способом) авторизовать пользователей для доступа в интернет;
• если вдруг «упадет» Squid, то доступ к сайтам прекратится. Поэтому админу нужно или быть уверенным, что все будет ОК, или иметь возможность удаленно изменить конфиг брандмауэра, или написать скрипт, автоматом проверяющего, висит ли Squid на порту 3128, и если нет, то запускающего его.

Настройка Squid в прозрачном режиме завершена. Вот теперь — все.

Источник

Маршрутизация локальной сети через прозрачный socks-прокси

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

Советую другой способ с использованием tun2socks.

• маршрутизатор TP-LINK, подключенный к провайдеру.
• смартфоны и ноутбук подключенные к беспроводной точки доступа маршрутизатора.

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

Инструментарий:

openssh-client — стандартный ssh клиент для linux.
autossh — позволяет проверять соединение с ssh сервером, и подключаться при разрыве.
redsocks — прозрачный socks-прокси сервер.
isc-dhcp-server — dhcp сервер.
iptables — думаю, комментарии излишне.

Итак, приступим. Первым делом поднимем DHCP сервер на беспроводном интерфейсе ноутбука.

Настроим нужный интерфейс:

Узнать название необходимого интерфейса можно командой:

Далее настроим сам dhcp сервер:

Должен содержать строчку с указанием необходимого интерфейса:

Пробежимся по главным параметрам:

option domain-name-servers — адреса DNS серверов, которые получат клиенты при подключении. В случае наличия локального DNS сервера (как у меня), необходимо указать адрес интерфейса 192.168.1.100.

range — диапазон присваиваемых IP адресов.

option routers — этот адрес будет служить шлюзом для клиентов.

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

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

Осталось только настроить маршрутизатор на использование нашего DHCP сервера, а именно, переключить режим DHCP, в настройках LAN на «Relay» и указать там, IP адрес нашего DHCP сервера — 192.168.1.100.

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

Установим необходимый инструментарий:

Если мы хотим иметь постоянный ssh туннель, который активируется при загрузки системы, необходимо создать службу systemd и включить ее. Так как мы будем использовать autossh, нужно заметить, что параметр -f (работа в фоне) включающий в себя параметр AUTOSSH_GATETIME=0, не поддерживается в systemd. Поэтому нужно указать использование параметра AUTOSSH_GATETIME=0 явно. Вот так выглядит базовая конфигурация сервиса:

After=network.target — Запуск службы при наличии сетевого подключения.
Environment=«AUTOSSH_GATETIME=0» — указывает systemd работу ssh в фоне.

Отдельно следует рассмотреть параметр ExecStart:

Запуск autossh со следующими параметрами:

-M — порт мониторинга. С этим параметром autossh будет непрерывно посылать запросы на сервер через указанные порты, если от сервера не приходит ответ, autossh подключается заново. Указанный порт мониторинга и порт порядком выше (+1) должны быть свободными в системе. Так как это делает такой мониторинг не практичным, мы отключаем эту функцию указывая значение 0.

«- o ServerAliveInterval» и «-o ServerAliveCountMax» — две опции, указывающие ssh клиенту отправлять запросы серверу непосредственно через туннель (то что нам нужно), чтобы поддерживать соединение, когда оно не активно. Также, если от сервера не следует ответа, соединение будет считаться разорванным и autossh подключается заново.

-N — не отправлять команд на сервер.
-D 1080 — открываем динамический порт на localhost.
user@server — здесь следует указать пользователя и адрес(доменное имя) сервера.
-p 22 — указываем порт подключения.

Включаем запуск во время загрузки:

Итак, запущены DCHP сервер на беспроводном интерфейсе ноутбука и стабильный ssh туннель в системе, осталось только завернуть в него трафик со всех устройств в локальной сети. Сделаем это с помощью redsocks и iptables.

Сохраняем конфиг и перезагружаем службу:

Остался, последний трюк с использование iptables. Предлагаю сразу создать скрипт со следующим содержанием:

Теперь все запросы с локальной сети, включая хост, будут направляться в ssh туннель.

Источник

Настраиваем интернет шлюз с прозрачным обходом блокировок (а рекламу таки будем блокировать)

У вас есть старенький (или не очень) компьютер с двумя сетевыми картами? Вам надоела реклама и лишние телодвижения для обхода блокировок? Вы не хотите с этим мириться? Тогда добро пожаловать под кат.

Настроить интернет шлюз таким образом, чтобы клиенты внутри локальной сети без дополнительных настроек работали с интернетом без ограничений. К заблокированным сайтам доступ будет осуществляться через тор, к остальным через обычное интернет соединение. К .onion ресурсам доступ из любого браузера как к обычным сайтам. В качестве бонуса, настроим блокировку рекламных доменов и доступ к условно заблокированным сайтам через тор (имеются в виду сайты, которые ограничивают функциональность для пользователей из РФ). Мой интернет провайдер чтоб тебе икнулось осуществляет перехват DNS запросов и подмену адресов (т.е. при резольвинге запрещенных сайтов возвращает адрес своей заглушки), поэтому все DNS запросы я отправляю в тор.

Идеи и способы реализации взял отсюда и отсюда. Авторам этих статей большое спасибо.

Итак поехали

Предполагается, что на начальном этапе у вас уже есть установленная ОС (в моем случае Ubuntu server 16.04) на компьютере с двумя сетевыми интерфейсами. Один из которых (у меня это ppp0) смотрит в сторону провайдера, а второй (у меня это enp7s0) в локалку. Внутренний IP шлюза 192.168.1.2. Локальная сеть 192.168.1.0/24.

Как подойти к этому этапу в данной статье не рассматривается, так как информации в сети более чем достаточно. Скажу только, что pppoe подключение к провайдеру удобно настраивать утилитой pppoeconf.

Подготовительный этап

Если вы, как и я, используете н<е|оу>тбук, то возможно вам захочется, чтобы он не засыпал при закрытии крышки.

Разрешаем форвардинг в ядре. Я за одно отключил IPv6.

Применим изменения без перезагрузки.

Настройка DHCP

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

Приводим файл примерно к такому виду.

Настройка TOR

Устанавливаем и открываем настройки.

Настройка DNS

Если вам не нужна блокировка рекламы, то данный пункт можно не выполнять. Если вы хотите просто пользоваться DNS от тора, добавьте в файл /etc/tor/torrc строку DNSPort 0.0.0.0:53 и всё.

Но я буду резать рекламу, а значит устанавливаем и открываем настройки

Приводим файл к следующему виду

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

Теоретически должно работать по шустрее, чем через тор.
К дальнейшей настройке DNS вернемся чуть позже. Пока этого достаточно. А сейчас перезапустим службу.

Настройка iptables

Вся магия будет твориться именно здесь.

1. Формируем список IP адресов на которые мы хотим ходить через тор.
2. Заворачиваем запросы к этим адресам на прозрачный прокси тора.
3. Заворачиваем DNS запросы к ресурсам .onion на DNS тора
4. Тор при резольвинге имен из зоны .onion возвращает IP адрес из подсети 10.0.0.0/8 (которую мы указали при настройке ТОР). Разумеется, эта зона не маршрутизируется в интернете и нам нужно завернуть обращения на эту подсеть на прозрачный прокси тора.

Изначально я полагал, что можно обойтись без перенаправления DNS запросов к .onion в iptables. Что можно настроить bind таким образом, чтобы он перенаправлял запросы на тор DNS и возвращал адреса из 10-й зоны. У меня не получилось так настроить.

Не приводит к желаемому результату, так же как выделение отдельной зоны «.onion» с forwarders на 127.0.0.1 port 5353.
Если кто-нибудь знает почему так происходит и как это исправить, напишите в комментариях.

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

Далее последовательно из под рута выполняем команды по настройке iptables. Разумеется вам нужно заменить имена интерфейсов и адреса на свои. Я поместил эти команды в /etc/rc.local перед exit 0 и они выполняются каждый раз после загрузки.

После перезагрузки мы должны получить шлюз, который:

• Выдает IP адреса и настройки сети клиентам.
• Раздает интернет.
• Резольвит имена через тор DNS.
• Резольвит имена .onion и позволяет посещать эти ресурсы через обычный браузер.
• Закрывает нас от входящих подключений.

Обхода блокировок пока нет, так как несмотря на то, что мы создали blacklist и настроили маршрутизацию, сам blacklist пока пустой. Настало время это исправить.

Заполняем blacklist

Создаем каталог в котором будет лежать скрипт.

Делаем скрипт исполняемым

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

Скрипт работает долго, будь пациентом be patient. Теперь должна открываться флибуста должны работать заблокированные сайты. Добавляем в конец файла /etc/rc.local, но перед exit 0

Настраиваем фильтр рекламы

1. Устанавливаем и запускаем микро HTTP сервер, который слушает 80 порт и на любой запрос возвращает картинку png с одним прозрачным пикселем.
2. Получаем список рекламных доменов.
3. Настраиваем bind как авторитативный сервер для них.
4. Заворачиваем все запросы на рекламные домены на наш HTTP сервер с чудесной картинкой.

Приступим. Займемся севером. Создаем файл

делаем его исполняемым

Создаем файл инициализации сервера

Делаем его исполняемым, регистрируем сервис, запускаем http сервер

Теперь создаем скрипт обновления рекламных доменов

Делаем его исполняемым

Создаем файл зоны

со следующим содержимымсервис

Добавляем в файл

Настраиваем обновление списка доменов при загрузке. Для этого открываем файл /etc/rc.local и добавляем после sleep 60

Последние штрихи

Для периодического обновления списков, создадим файл

Со следующим содержимым

Делаем его исполняемым

Замечание для пользователей десктопных версий Ubuntu

Несмотря на то, что целью было создать шлюз, который не требует настроек клиентов, в моем случае получилось не совсем так. В качестве рабочей операционной системы я использую десктопную Ubuntu 16.04. Для настройки сети в ней используется утилита NetworkManager, которая по умолчанию настроена таким образом, что адрес DN сервера берется не с DHCP сервера, а устанавливается как 127.0.1.1:53. На этом порту висит dnsmasq и только по ему известным правилам резольвит имена. В обычной жизни это никак не мешает, а в нашем случае делает совершенно неработоспособной зону .onion

Чтобы это исправить нужно в файле /etc/NetworkManager/NetworkManager.conf закоментировать строку

После перезагрузки все работает.

Заключение лишь бы не под стражу

Клиенты на андроид работают нормально без дополнительных настроек.
Windows не проверял, так как не использую, но думаю, проблем возникнуть не должно.
Ограничения для firefox и iOs описаны здесь

Прошу прощения за сумбурное изложение. Дополнения, исправления, замечания приветствуются.
Спасибо за внимание.

Источник