Введение
Я успешно разобрался с настройкой sams2 под CentOS 7 и решил проделать то же самое на Freebsd 10.2. Мне нравится эта система. Не могу аргументировать чем именно, просто нравится и все. С нее началось мое первое знакомство с unix системами и с тех пор я стараюсь не забывать о ней, хотя работаю в ней все меньше и меньше.
Sams популярная и в своем роде уникальная система управления конфигурацией squid, которая работает через свой демон и php панель управления. Аналогов по удобству и функционалу я не встречал. Есть что-то похожее, но еще более старое, например STC. Но мне она внешне вообще не нравится, тоже очень старая и давно не развивается.
Можно схожий функционал реализовать отдельными средствами. Например, настроить ту или иную авторизацию в squid, создать списки доступа, списки ресурсов, включить все это. Потом анализировать логи, например, с помощью SARG. По идее, получится то же самое, что и самс, но управлять неудобно, отчеты в SARG не такие красивые и наглядные. В общем, не то.
Так что будем разбираться и настраивать самую последнюю из выпущенных версий самс — sams 2.0 от 1 апреля 2014 года.
Введение
Синдром гамака является одним из ключевых моментов деградации сисадмина. Он начинается с того, что стабильность и неподвижность становятся синонимами. Когда-то, до того, как IPFilter включили в состав FreeBSD, единственным нормальным способом сделать NAT во FreeBSD был natd. Обязательным условием для полноценной работы natd является наличие dummynet(4). natd и до сих пор может быть в некоторых случаях актуален. Мы же рассмотрим использование ipnat из IPFilter в качестве средства для Network Address Translation (NAT).
Этот документ не является пошаговым howto для чайников — подразумевается, что не нужно объяснять, что например после изменения /etc/syslog.conf ему нужно послать сигнал HUP, а файлы, куда он будет писать, создавать нужно самостоятельно и как «применять» изменённые правила. Если Вы считаете, что ещё не совсем освоились с *nix и с FreeBSD в частности, то по этой теме можно почитать:ipnat(1), ipnat(5), ipnat(8)ipf(5), ipf(8), ipfstat(8), ipftest(1), ipmon(8)
Здесь и далее будет считаться, что IPFilter у нас как минимум версии 3.4.29. Если в Вашем случае это не так — то Вы ещё не совсем вылезли из гамака, хотя уже тот факт, что Вы читаете этот текст, является доказательством Вашего на то желания.
Подготовка
Итак, рассмотрим ситуацию: мы имеем 2 интерфейса — fxp0 (200.200.200.1), смотрящий в большой и злой интернет, и dc0 (192.168.0.1), смотрящий во внутреннюю сеть.
Задача: сделать возможность пользователям внутренней сети создавать соединения к внешним хостам без использования socks5/http proxy и т.п.
В ядре нам понадобятся всего 2 строчки:options IPFILTERoptions IPFILTER_LOG
После этого IPFilter доступен нам во всей своей красе.
Также в /etc/rc.conf нужно добавить строчку gateway_enable=»yes» или в /etc/sysctl.conf добавить строчку net.inet.ip.forwarding=1.
Теперь всё готово — пакеты перебрасываются между интерфейсами. Осталось контролировать их переброс и заменять в них IP адрес с внутреннего на внешний и наоборот.
Перенаправление (редирект)
Если существует необходимость безусловно транслировать какие-то пакеты, пришедшие извне (например чтобы WWW/SMTP сервер из внутренней сети) был доступен снаружи – используется редирект (redirect).
Простой вариант: транслировать пакеты от любого хоста.
rdr fxp0 200.200.200.1/32 port 8080 -> 192.168.1.17 port 80 tcp
В данном случае любой пакет, пришедший на порт 8080 внешнего интерфейса 200.200.200.1 будет «проброшен» на 192.168.1.18 порт 80. Естественно, что хост 192.168.1.17 лучше поместить в таблицу трансляций как было описано в «Простеньком stateful NAT» и с учётом того, что инициироваться соединение будет снаружи — добавить правила IPFilter, которые бы разрешали их. В случае, если ipmon протоколирует работу IPFilter, допущенную ошибку можно будет легко увидеть.
Редирект можно делать не всех пакетов, а выборочно на основании их отправителя:rdr fxp0 from 212.118.165.100/32 to 200.200.200.1/32 port = 6000 -> 192.168.1.89 port 6000
Этим правилом будут транслироваться пакеты, пришедшие на 200.200.200.1 порт 6000 только с хоста 212.118.165.100
Не стоит забывать создавать правила IPFilter, разрешающие прохождение таких пакетов. Хотя, если ipmon настроен и запущен, то он быстро об этом напомнит. 
Подмена заголовков в запросе клиента в Squid
Дело было на домашнем Debian-сервере. Один из интернет радио порталов напрочь отказывался воспроизводиться на моем музыкальном центре, настойчиво предлагая закрыть плейер и открыть браузер. К сожалению, не смотря на наличие интернета, браузер в музыкальном центре конструкцией не был предусмотрен. Пришлось замаскировать центр под браузер путем подмены заголовка User-Agent с помощью Squid’а и прозрачного проксирования.
Для подмены HTTP-заголовка, добавляем три опции в squid.conf:
# Подмена HTTP-заголовка User-Agent # Задаем IP-адрес устройства, для которого требуется подмена acl MediaDevice src 192.168.0.3 # Запрещаем передачу HTTP-заголовка User-Agent request_header_access User-Agent deny MediaDevice # Включаем подмену HTTP-заголовка User-Agent, задаем браузер по вкусу ;) request_header_replace User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Перезапускаем Squid:
service squid restart
Поскольку это безобразие нагло нарушает HTTP-стандарт, требуется сборка Squid с параметром LAX_HTTP, он же —enable-http-violations.
Установка прокси сервера squid
Теперь установим сам прокси сервер squid:
# pkg install -y squid
Добавляем squid_enable=»YES» в /etc/rc.conf и запускаем его:
# /usr/local/etc/rc.d/squid start
Сейчас можно проверить работу прокси сервера squid. В дефолтной конфигурации он должен выпускать в интернет по ip, список которых есть в конфигурационном файле — /usr/local/etc/squid/squid.conf. Рекомендую на всякий случай это сделать, чтобы убедиться в корректности работы сквида.
Если вы будете использовать кэш, то перед запуском сквида раскомментируйте в конфигурационном файле соответствующую настройку и выполните команду в консоли:
# squid -z
Чтобы самс корректно добавлял свои изменения в файл конфигурации, в нем должны быть метки, начинающиеся с # TAG:. Раньше дефолтный конфиг сквида уже был с ними, но затем его существенно уменьшили в размере и метки из него исчезли. Нам нужно добавить их самим. Вот необходимый набор этих меток. Между ними обязательно должна быть пустая строка:
# TAG: acl # TAG: url_rewrite_access # TAG: url_rewrite_program # TAG: url_rewrite_children # TAG: delay_pools # TAG: delay_class # TAG: delay_access # TAG: delay_parameters # TAG: http_access # TAG: http_access2 # TAG: icp_access
Предупреждаю, если вы вдруг забудете. Проверьте ротацию логов squid. Если она не будет работать, то есть большая вероятность, что логи займут весь раздел диска. При интенсивном использовании прокси сервера, логи разрастаются очень быстро
Обратите на это внимание.
FTP proxy
Итак, всё работает замечательно, за исключением FTP из внутренней сети. Это обусловлено тем, что в ходе установки соединения, по которому будут передаваться данные, указывается IP-адрес клиента, который в нашем случае принадлежит частной сети.
ipnat способен в таких случаях быть «прокси-сервером» — то есть «ковыряться» в данных, передаваемых FTP-серверу и от него, и транслировать адреса из внутренних во внешние и наоборот. Для этого используется такое правило:map fxp0 192.168.1.149/32 -> 200.200.200.1/32 proxy port ftp ftp/tcp
proxy-правило должно обязательно стоять перед другими правилами (за исключением redirect).
Ротация логов Squid
Проверяем, поддерживается ли вашей системой newsyslog.conf.d
ls /etc/newsyslog.conf.d
Если в вашей системе отсутствует папка newsyslog.conf.d, редактируем newsyslog.conf:
ee /etc/newsyslog.conf
Если папка newsyslog.conf.d имеется, создаем папку с тем же именем в /usr/local/etc:
mkdir /usr/local/etc/newsyslog.conf.d
Создаем файл правил ротации логов Squid:
ee /usr/local/etc/newsyslog.conf.d/squid
Задаем правила ротации логов:
/var/log/squid/access.log squid:squid 600 180 * $D0 JC /var/run/squid/squid.pid 30 /var/log/squid/cache.log squid:squid 600 180 * $D0 JC /var/run/squid/squid.pid 30 #/var/log/squid/store.log squid:squid 600 30 * $D0 JC /var/run/squid/squid.pid 30
Выполняем ротацию ежедневно в полночь, сохраняем логи за последние 180 дней, раскомментируйте store.log, если он используется в вашей системе.
Для корректной ротации логов в squid.conf необходимо добавить следующий параметр:
# Отключить встроенную ротацию логов # При ротации логов средствами newsyslog logfile_rotate 0
Подготовка системы и установка зависимостей
Если вы только знакомитесь с материалом и еще не подготовили свою систему, то рекомендую воспользоваться моей подробной инструкцией с видео по установке freebsd 10.2. Именно на ней я буду производить установку и настройку sams2.
После установки необходимо на всякий случай обновить freebsd до последней версии. Если вы это уже сделали, то рекомендую выполнить предварительную настройку системы, ну или хотя бы установите MC, с ним удобнее.
Теперь установим необходимые пакеты. Можно все собрать из портов, но я буду ставить готовые пакеты, просто потому что так быстрее. Это не принципиально, если вы привыкли собирать из портов, делайте это.
Нам понадобится web сервер для работы панели администрирования. Подробно этот вопрос я уже рассматривал отдельно в статье посвященной настройке web сервера. Можно подсмотреть там, как быстро установить apache + php + mysql + phpmyadmin. Здесь я просто приведу список команд, которые я использовал при установке. За всеми подробностями и комментариями прошу обращаться по приведенной ссылке.
Сервер, с которым будем работать:
# uname -v FreeBSD 10.2-RELEASE-p8
Выполним установку mysql, ее использует самс для хранения данных:
# pkg install -y mysql56-server
Добавляем mysql_enable=»YES» в /etc/rc.conf и запускаем mysql:
# /usr/local/etc/rc.d/mysql-server start
Выполним начальную настройку mysql с помощью скрипта:
# /usr/local/bin/mysql_secure_installation
Устанавливаем web сервер apache, он нам нужен для работы панели администрирования:
# pkg install -y apache24
Добавляем apache24_enable=»YES» в /etc/rc.conf и запускаем:
# /usr/local/etc/rc.d/apache24 start
Устанавливаем все необходимое, связанное с php:
# pkg install -y php56 php56-extensions mod_php56 php56-mysql
Этот шаг не обязательный, можно пропустить. Я просто привык использовать phpmyadmin в работе. С ним удобно. Устанавливаем phpmyadmin:
# pkg install -y phpmyadmin
Редактируем конфиг apache, добавляем в самый конец для работы php скриптов и доступа к phpmyadmin:
<IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps DirectoryIndex index.php index.html </IfModule> Alias /phpmyadmin/ "/usr/local/www/phpMyAdmin/" <Directory "/usr/local/www/phpMyAdmin/"> AllowOverride All Require all granted DirectoryIndex index.php index.html index.htm Order allow,deny Allow from All </Directory>
Создаем файл настроек php.ini, скопировав дефолтный:
# cp /usr/local/etc/php.ini-production /usr/local/etc/php.ini
И устанавливаем там временную зону:
date.timezone = Europe/Moscow
Если не установить, то в веб интерфейсе самса будут постоянно вылезать ошибки, связанные с временной зоной. После всех изменений перезапускаем apache:
# apachectl restart
Все, web сервер готов. Для теста можете зайти на http://ip-сервера/phpmyadmin/ и проверить, все ли в порядке. Если что-то не так, то разберитесь сначала с работой веб сервера, и только потом двигайтесь дальше.
Если веб сервер не работает, то обратитесь либо к моему руководству на тему настройки веб сервера, либо к какому-нибудь другому. Подобного материала в интернете много. Его можно было не включать в эту статью, но я для целостности картины привел краткую настройку. Банального копи паста достаточно, чтобы все заработало.
Кэширование контента в Squid
На современных высокоскоростных безлимитных каналах связи кэширование потеряло свою актуальность. Для ускорения работы YouTube и других сетей доставки контента, кэширование также неэффективно, поскольку контент раздается с различных серверов.
По умолчанию дисковый кэш отключен, но в качестве кэша используется 256Мб оперативной памяти.
Полностью запретить кэширование можно добавив следующий параметр в squid.conf:
# Запретить кэширование cache deny all
Если необходим дисковый кэш, добавляем в squid.conf следующие параметры:
# Кэш: формат, размещение, размер в мегабайтах, число папок первой и второй вложенности # Указанный размер кэша не учитывает издержки файловой системы и должен быть примерно на 20% меньше доступного дискового пространства # Директиву cache_dir, можно указать несколько раз, выделив под кэш дополнительные разделы cache_dir ufs /var/squid/cache 3000 16 256 # Не кэшировать файлы больше заданного размера # По умолчанию 4Мб maximum_object_size 320 MB # Продолжить загрузку при отключении клиента, если осталось загрузить менее указанного объема данных # Позволяет сохранить объект в кэше при отмене загрузки клиентом # Значение 0 для quick_abort_min и quick_abort_max отменяют докачку # Значение -1 включает полную закачку объекта, не зависимо от оставшегося объема, повышает нагрузку на канал # По умолчанию 16 Кб quick_abort_min 5 MB
Если путь к кешу был изменен, создаем папку кэша, задаем права доступа:
mkdir -p /usr/local/squid/cache chown root:squid /usr/local/squid/cache chmod 770 /usr/local/squid/cache
Создаем структуру кэша:
/usr/local/sbin/squid -z
Решение проблем
Предупреждение в cache.log:
WARNING: no_suid: setuid(0): (1) Operation not permitted
Баг Squid появился в версии 3.2, возникает на BSD-системах, из-за некорректного вызова функции setuid.
Баг-репорт: http://bugs.squid-cache.org/show_bug.cgi?id=3785
В зависимости от параметров конфигурации Squid, в некоторых случаях помогает изменение параметра daemon на stdio при указании пути к access.log-у.
Ошибка при запуске Squid:
FATAL: Bungled /usr/local/etc/squid/squid.conf line 64: acl manager proto cache_object
Начиная с версии 3.2 списки контроля доступа: manager, localhost и to_localhost являются предопределенными и создаются сквидом автоматически. При попытке их переопределения в файле конфигурации возникает ошибка. Данные параметры необходимо удалить из конфига.
Ошибка в cache.log:
ERROR: No forward-proxy ports configured.
Не задан порт для входящих подключений. Проверяем наличие в squid.conf директивы:
http_port 3128
В случае с прозрачным прокси, начиная с версии 3.2, необходимо задать две опции http_port. Одина для обычных запросов, вторая для перенаправляемого трафика:
http_port 3128 http_port 127.0.0.1:3128 intercept
При запуске Squid получаем следующие предупреждения:
WARNING: (A) '192.168.0.0/16' is a subnetwork of (B) '::/0' WARNING: because of this '192.168.0.0/16' is ignored to keep splay tree searching predictable WARNING: You should probably remove '192.168.0.0/16' from the ACL named 'all'
В файле конфигурации обнаружена декларация acl all. В третьей версии список контроля доступа all является предопределенным и создается сквидом автоматически. При попытке его переопределения в файле конфигурации возникает ошибка. Удалите или переименуйте acl all.
В cache.log постоянно пишутся предупреждения:
WARNING: transparent proxying not supported
При сборке не была включена поддержка прозрачного прокси для вашего брандмауэра. Переустановите Squid из коллекции портов с включением соответствующих параметров.
Отображение местного времени на страницах ошибок Squid
Из коробки на страницах ошибок Squid отображает время по Гринвичу, для отображения местного времени необходимо скорректировать шаблоны ошибок. Параметр шаблона %T указывает мировое время, %t — местное.
Копируем шаблоны ошибок в папку erros.local:
mkdir -p /usr/local/etc/squid/errors.local/ru cp /usr/local/etc/squid/errors/ru/* /usr/local/etc/squid/errors.local/ru
Заменяем общемировое время (%T), на местное (%t):
sed -i .bak "s/%T/%t/g" /usr/local/etc/squid/errors.local/ru/* && rm /usr/local/etc/squid/errors.local/ru/*.bak
Задаем путь к измененным шаблонам ошибок в squid.conf:
printf "\n\n #Местное время на страницах ошибок\nerror_directory /usr/local/etc/squid/errors.local/ru\n" >> /usr/local/etc/squid/squid.conf
Запуск Squid
Включаем Squid в rc.conf:
squid_enable="YES"
Вручную редактором:
ee /etc/rc.conf
Или командой:
printf '\nsquid_enable=\"YES\"\n' >>/etc/rc.conf
Запускаем Squid:
service squid start
Если при старте получаем предупреждение: «». Задаем имя сервера параметром «» в конфиге.
Проверяем, запущен ли демон:
ps -ax | grep squid
Проверяем, слушается ли порт:
sockstat | grep squid
Проверяем системный лог на наличие сообщений от Squid:
grep squid /var/log/messages
Проверяем cache.log:
cat /var/log/squid/cache.log
В случае успешного старта вывод будет примерно следующим:
2015/03/25 15:29:32 kid1| Set Current Directory to /var/squid/cache 2015/03/25 15:29:32 kid1| Starting Squid Cache version 3.4.12 for i386-portbld-freebsd10.1... 2015/03/25 15:29:32 kid1| Process ID 32795 2015/03/25 15:29:32 kid1| Process Roles: worker 2015/03/25 15:29:32 kid1| With 14148 file descriptors available 2015/03/25 15:29:32 kid1| Initializing IP Cache... 2015/03/25 15:29:32 kid1| DNS Socket created at , FD 7 2015/03/25 15:29:32 kid1| DNS Socket created at 0.0.0.0, FD 8 2015/03/25 15:29:32 kid1| Adding nameserver 8.8.8.8 from /etc/resolv.conf 2015/03/25 15:29:32 kid1| Logfile: opening log daemon:/var/log/squid/access.log 2015/03/25 15:29:32 kid1| Logfile Daemon: opening log /var/log/squid/access.log 2015/03/25 15:29:32 kid1| Store logging disabled 2015/03/25 15:29:32 kid1| Swap maxSize 0 + 262144 KB, estimated 20164 objects 2015/03/25 15:29:32 kid1| Target number of buckets: 1008 2015/03/25 15:29:32 kid1| Using 8192 Store buckets 2015/03/25 15:29:32 kid1| Max Mem size: 262144 KB 2015/03/25 15:29:32 kid1| Max Swap size: 0 KB 2015/03/25 15:29:32 kid1| Using Least Load store dir selection 2015/03/25 15:29:32 kid1| Set Current Directory to /var/squid/cache 2015/03/25 15:29:32 kid1| Finished loading MIME types and icons. 2015/03/25 15:29:32 kid1| HTCP Disabled. 2015/03/25 15:29:32 kid1| Squid plugin modules loaded: 0 2015/03/25 15:29:32 kid1| Accepting HTTP Socket connections at local=:3128 remote= FD 11 flags=9 2015/03/25 15:29:32 kid1| Accepting NAT intercepted HTTP Socket connections at local=127.0.0.1:3128 remote= FD 12 flags=41 2015/03/25 15:29:33 kid1| storeLateRelease: released 0 objects
Настройка ядра (FreeBSD 9.1 и ранее)
Начиная с FreeBSD 9.2 настройка ядра не требуется, форвардинг пакетов отныне включен изначально, параметр IPFIREWALL_FORWARD удален из настроек ядра.
Для работы в режиме прозрачного прокси в версиях системы до 9.2 необходимо обеспечить перенаправление веб-трафика прокси-серверу. Если в качестве брандмауэра используется IPFW, необходимо включить форвардинг пакетов пересобрав ядро с опцией IPFIREWALL_FORWARD.
В ядре GENERIC опция перенаправления по умолчанию отключена. Чтобы проверить, включено ли перенаправление пакетов в вашей системе, выполняем команду:
grep ipfw /var/run/dmesg.boot
Получаем следующий результат:
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled
Если видим: «rule-based forwarding disabled», форвардинг отключен, необходимо пересобрать ядро. Если сообщение отсутствует, значит IPFW не настроен. Если отсутствует параметр «rule-based forwarding», пересборка ядра не требуется.
Получаем идентификатор ядра:
uname -i
Если ранее ядро не изменялось, в результате получаем:
GENERIC
Создаем файл конфигурации ядра IPFORWARD:
ee /usr/src/sys/i386/conf/IPFORWARD
Задаем параметры:
#Импортировать параметры из конфига GENERIC include GENERIC #Идентификатор ядра, должен совпадать с названием файла конфигурации ядра, отображается в процессе загрузки ident IPFORWARD #Включить перенаправление пакетов options IPFIREWALL options IPFIREWALL_FORWARD
cd /usr/src
Если файлы в /usr/src отсутствуют, необходимо установить исходники, соответствующие вашей версии системы.
Собираем и устанавливаем ядро, используя созданный конфиг:
make kernel KERNCONF=IPFORWARD
Перезагружаем систему:
shutdown -r now
Проверяем идентификатор ядра:
uname -i
В случае успешной установки ядра, в ответ получаем:
IPFORWARD
Проверяем статус IPFW:
grep ipfw /var/run/dmesg.boot
В случае успеха получаем:
ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to deny, logging disabled
Установка Squid из коллекции портов
Обновляем коллекцию портов:
portsnap fetch update
Если коллекция портов используется впервые, получаем ее актуальную версию:
portsnap fetch extract
Выполняем настройку порта:
cd /usr/ports/www/squid make config
В параметрах сборки проверяем, что включена поддержка прозрачного проксирования для используемого брандмауэра и поддержка больших файлов:
LARGEFILE Support large (>2GB) cache and log files LAX_HTTP Do not enforce strict HTTP compliance ... TP_IPF Enable transparent proxying with IPFilter TP_IPFW Enable transparent proxying with IPFW TP_PF Enable transparent proxying with PF
Если необходима модификация HTTP-заголовков (использование опций via, request_header_access), также включаем LAX_HTTP, для сборки Squid с параметром —enable-http-violations.
Устанавливаем порт:
make install clean
Если параметры сборки были изменены, блокируем переустановку Squid пакетным менеджером:
pkg lock squid
Настройка IPFW
Далее предполагается, что IPFW настроен на примере, предложенном в руководстве FreeBSD.
Открываем rc.conf:
ee /etc/rc.conf
Проверяем, включена ли маршрутизация:
gateway_enable="YES"
Если необходимо, включаем NAT:
natd_enable="yes" # Включить функцию NATD natd_interface="em0" # Название внешнего сетевого интерфейса natd_flags="-dynamic -m" # -m = по возможности сохранить номера портов
Находим параметры IPFW:
firewall_enable="YES" firewall_script="/etc/ipfw.rules"
Запоминаем путь к скрипту с правилами.
Редактируем список правил IPFW:
ee
Добавляем правила, выделенные красным, перед правилом, разрешающим доступ в интернет:
#!/bin/sh cmd="ipfw -q add" skip="skipto 500" # Внешний интерфейс pif=em0 ipfw -q -f flush # Разрешить SSH-доступ администратору с заданного IP-адреса # Раскомментируйте, чтобы не перекрыть себе доступ в случае проблем с настройкой брандмауэра #$cmd 001 allow ip from x.x.x.x to me dst-port 22 in via $pif #$cmd 001 allow ip from me to x.x.x.x src-port 22 out via $pif $cmd 002 allow all from any to any via em1 # разрешаем трафик на локальном интерфейсе $cmd 003 allow all from any to any via lo0 # разрешаем трафик на интерфейсе loopback $cmd 100 divert natd ip from any to any in via $pif $cmd 101 check-state # Разрешаем доступ пользователю Squid $cmd 124 allow all from me to any out via $pif keep-state uid squid # Отправляем http-запросы на порт прозрачного прокси $cmd 125 fwd 127.0.0.1,3128 tcp from 192.168.0.0/16 to any 80 out via $pif keep-state $cmd 130 $skip all from any to any out via $pif keep-state # Запрещаем весь входящий трафик с немаршрутизируемых адресных пространств #$cmd 300 deny all from 192.168.0.0/16 to any in via $pif #RFC 1918 для локальных IP $cmd 301 deny all from 172.16.0.0/12 to any in via $pif #RFC 1918 для локальных IP $cmd 302 deny all from 10.0.0.0/8 to any in via $pif #RFC 1918 для локальных IP $cmd 303 deny all from 127.0.0.0/8 to any in via $pif #loopback $cmd 304 deny all from 0.0.0.0/8 to any in via $pif #loopback # Закомментировать, если внешний интерфейс использует DHCP $cmd 305 deny all from 169.254.0.0/16 to any in via $pif #DHCP авто-конфигурации $cmd 306 deny all from 192.0.2.0/24 to any in via $pif #Зарезервировано для документации $cmd 307 deny all from 204.152.64.0/23 to any in via $pif #Sun cluster $cmd 308 deny all from 224.0.0.0/3 to any in via $pif #Class D & E multicast # Разрешаем входящие пакеты #$cmd 400 allow udp from xx.70.207.54 to any 68 in keep-state #$cmd 420 allow tcp from any to me 80 in via $pif setup limit src-addr 1 $cmd 450 deny log ip from any to any # Раздел skipto для правил с сохранением состояния для исходящих пакетов $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any ######################## Окончание файла правил ##################
Если менялись параметры rc.conf, включаем маршрутизацию и NAT. Будьте осторожны при настройке брандмауэра с внешнего IP, есть риск перекрыть себе доступ.
service routing restart service natd start
Загружаем обновленный список правил:
Инициируем веб-трафик с клиентского компьютера, проверяем лог доступа:
tail -f /var/log/squid/access.log
В случае проблем проверяем, работает ли правило брандмауэра:
ipfw show
Счетчик для правила перенаправления (fwd 127.0.0.1,3128) не должен быть нулевым.
Если перенаправление работает, но сайты не открываются, проверяем cache.log на предмет ошибок:
cat /var/log/squid/cache.log
Заключение
Поле завершения установки и настройки sams2, а затем и реальной эксплуатации у меня ложилось двоякое впечатление. С одной стороны вроде работает, но как-то криво. В программе баги, в логи она во время работы постоянно сыпет сообщениями:
Dec 27 01:20:08 freebsd samsdaemon: ***ERROR: squidlogparser.cpp:445 Unknown cache result Dec 27 01:20:08 freebsd samsdaemon: +++WARNING: Unknown cache result TCP_TUNNEL
Хотя на работу это вроде как не влияет. В инет пускает, статистику считает. Я еще не настраивал редиректор и списки запрета доступа, но по отзывам, там тоже есть проблемы и работает все нестабильно. Начиная с версии 3.4 поменялся формат ответа редиректора и он стал несовместим с самсовским. Нужно править исходники и собирать с исправлениями. На CentOS я обошелся просто более старой версией squid, чтобы не разбираться с этой проблемой. Думаю, можно вообще без запретов обойтись, это сейчас не актуально из-за большого развития мобильных гаджетов и хорошего доступа в интернет с них
Но если вам это важно, имейте в виду
Несмотря на все проблемы, я не нашел замены, которая была бы такой же удобной и наглядной, как sams. Придется пока с ним дружить и находить общий язык. Надеюсь, что кто-нибудь возьмется за его развитие и поддержку.
