Настройване на Squid 3 като прозрачен прокси на FreeBSD - Proxy - Laquo; Unix, Linux - Laquo;
Настройте Squid като прозрачен прокси сървър за офис мрежата. Предполага се, че маршрутизирането е конфигурирано на сървъра и достъпът до сайтове от вътрешната мрежа вече работи. Ние използваме прокси сървър за дешифриране на уеб трафик, ограничаване на достъпа до сайтове и филтриране на медийно съдържание.
Настройка на ядрото
За да работите в прозрачен прокси режим, трябва да се уверите, че уеб трафикът е пренасочен към прокси сървър. Ако IPFW се използва като защитна стена, препращането на пакети трябва да бъде разрешено чрез повторно изграждане на ядрото с опцията IPFIREWALL_FORWARD. В GENERIC ядрото опцията за пренасочване е деактивирана по подразбиране.
В ядрото GENERIC опцията за пренасочване е деактивирана по подразбиране. Проверете дали пренасочването на пакети е активирано с командата:
Получаваме следния резултат:
Ако видим: "базираното на правила пренасочване е деактивирано ", препращането е деактивирано, трябва да изградите отново ядрото. Ако няма съобщение, IPFW не е конфигуриран.
Вземете ID на ядрото:
Ако ядрото не е променяно преди, резултатът е:
Създайте IPFORWARD конфигурация на ядрото, базирана на GENERIC
Активирайте препращането на пакети:
Проверете получената конфигурация:
В резултат на това получаваме:
Отидете в папката източник на системата:
Ако няма файлове в /usr/src, трябва да инсталирате изходния код, съответстващ на вашата версия на системата.
Ние събираме и инсталираме ядрото с помощта на създадената конфигурация:
Проверка на ID на ядрото:
В случай на успешна инсталация на ядрото, в отговор получаваме:
Проверка на състоянието на IPFW:
При успех получаваме:
Инсталиране на Squid
Актуализирайте колекцията от портове:
Вземете списък с наличните версии на Squid:
INВ опциите за изграждане ние активираме прозрачно проксииране за използваната защитна стена и поддръжка за големи файлове:
За изграждане на пакета се използват параметри по подразбиране, прозрачният прокси, инсталиран от пакета, няма да работи правилно.
Настройване на Squid
Запазете конфигурационния файл по подразбиране:
Създайте нов конфигурационен файл:
Създайте папка за списъци за контрол на достъпа
Създаваме необходимите списъци, стойностите в списъка са разделени с нов ред.
Някои сайтове използват https протокола, който не може да бъде филтриран с прозрачно прокси. За да ограничите достъпа до такива сайтове, ще трябва да използвате защитна стена или DNS сървър, или прокси https по традиционен, непрозрачен начин.
Създайте папка за кеша, задайте права за достъп:
Създайте структура на кеша:
Създайте папка за регистрационни файлове за достъп, задайте права за достъп:
Регистърът за достъп за един месец може да отнеме доста голямо количество, поради тази причина в разглежданата конфигурация дневникът е поставен в /usr. Ако има достатъчно свободно място в /var, журналът за достъп може да бъде оставен в /var/log/squid.
Показване на местно време на страници с грешки на Squid
По подразбиране Squid показва GMT на страниците с грешки, но трябва да коригирате шаблоните за грешки, за да показват местно време. Параметърът на шаблона %T указва световно време, %t указва местно време.
Копирайте шаблоните за грешки в папката erros.local:
Заменете глобалното време (%T) с местно време (%t):
Задайте пътя към модифицираните шаблони за грешки в squid.conf:
Бягащи калмари
Активирайте Squid в rc.conf:
Проверете дали демонът е стартиран:
Проверете дали гнездото слуша:
В случай на успешно стартиране, резултатът ще бъде нещо подобно:
Относно „ПРЕДУПРЕЖДЕНИЕ: no_suid: setuid(0): (1) Операцията не е разрешена“, проследяваме доклада за грешка: http://bugs.squid-cache.org/show_bug.cgi?id=3785.
В защитната стена разрешаваме изходящи връзки за Squid (номерът на правилото и външният интерфейс трябва да бъдат зададени на вашите):
Пренасочване на уеб трафик от тестовия компютър към Squid:
Инициираме уеб трафик от тестовия компютър и проверяваме регистрационния файл за достъп:
В случай на проблеми, проверете дали правилото на защитната стена работи:
Броячът за правило за пренасочване не трябва да е нула.
Ако не са открити проблеми по време на тестването, ние обвиваме цялата подмрежа в прокси:
Протокол за контрол на кеша
Ако управлението на кеша не е деактивирано в конфигурацията, използвайте squidclient, за да получите статистика и оперативно управление.
Вземете обща статистика на сървъра:
Получете списък с наличните команди:
Ротация на дневника за достъп до Squid
Настройте месечна ротация и архивиране на access.log
Създайте скрипта RotateAccessLog:
Със следното съдържание:
Позволяваме на скрипта да се изпълнява:
Нека направим пробно изпълнение:
Проверете дали архивът е създаден:
Задайте cron да се изпълнява на първо число на всеки месец в полунощ:
Автоматично рестартиране на Squid при повреда
Squid 2.7 претърпя периодични сривове, оставяйки мрежата без достъп до мрежата. Въпреки че в третата версия подобни безобразия вече не се забелязват, допълнителна проверка не боли. Проверяваме със скрипта дали Squid е зареден и го стартираме, ако е необходимо. По пътя почистваме кеша, когато се открие съобщение за липса на дисково пространство.
Създайте скрипт за автоматично рестартиране:
Със следното съдържание:
Позволяваме на скрипта да се изпълнява:
Нека направим пробно изпълнение:
Ние стартирамечрез cron на всеки 15 минути:
В случай на проблеми ще бъде изпратено известие до пощата на root.
Анализ на дневника на Squid
Списък с други анализатори е достъпен на уебсайта на проекта: http://www.squid-cache.org/Misc/log-analysis.html
Разрешаване на проблем
Ако предупрежденията се записват постоянно в cache.log:
Компилацията не включва прозрачна поддръжка на прокси за вашата защитна стена. Преинсталирайте Squid от колекцията от портове, включително подходящите опции.
Ако получим следните предупреждения:
Acl цялата декларация е намерена. В третата версия списъкът за пълен достъп се създава автоматично от squid, неговата декларация не се изисква. Изтрийте или преименувайте acl всички.