Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

Кешуючий проксі-сервер Squid

Особливі типи проксі

Існує два основних види проксі-серверів:

Прозорий проксі – схема зв'язку, при якій трафік, або його частина, перенаправляється на проксі-сервер неявно (засобами маршрутизатора). При цьому клієнт може використовувати всі переваги проксі-сервера без додаткових налаштувань, але з іншого боку, не має вибору.

Прозорий проксі сервер змінює ваш IP адреса на свій, АЛЕ ваш реальний IP все одно присутній у вашому запиті (уявіть що він просто перенесено в інше місце). Таким чином якщо веб сайт (який ви запитуєте) вирішить визначити ваш реальний IP, то він без утруднень зробить це.

Ви можете припустити що прозорі проксі сервера марні, так як вони не забезпечують приватність (приховування вашого IP), але не поспішайте з висновками. У прозорих проксі є інша перевага: вони працюють швидше (швидкість) ніж аналогічні анонімні або елітні проксі. У таких проксі є своє призначення, наприклад – якщо ви хочете обійти локальний фаєрвол який блокує доступ до якогось сайту, прозорі проксі сервера саме ідеальне рішення. Адже в ваше завдання не входить приховування реального IP, а тільки який сайт ви відвідуєте.

Також (правда дуже рідко), прозорі проксі сервера підходять для накрутки лічильників на вашій сторінці.

Зворотний проксі – проксі-сервер, який на відміну від прямого, ретранслює запити клієнтів із зовнішньої мережі на один або кілька серверів, логічно розташованих у внутрішній мережі. Часто використовується для балансування мережного навантаження між декількома веб-серверами і підвищення їх безпеки, граючи при цьому роль міжмережевого екрану на прикладному рівні.

Squid є кешуючого проксі сервером для HTTP, FTP та інших протоколів. Проксі сервер для HTTP - це програма, що виконує HTTP-запити від імені клієнтської програми (будь то браузер або інший софт). Proxy може бути кешуючим або не кешуючим. Кешуючий, відповідно, зберігає всі запити в будь-яке сховище для більш швидкої віддачі клієнтам, а не кешуючий - просто транслює HTTP, ftp або інші запити. Раніше, кешування трафіку дозволяло домогтися досить значної економії трафіку, але в наш час із зростанням швидкостей Інтернету це трохи загубило актуальність. Проксі сервер можна вибудовувати в ієрархії для обробки запитів. При цьому, проксі сервер взаємодіють між собою за протоколом ICP.

Squid розроблений і може працювати на більшості операційних систем (як unix, так і windows). Ліцензується під ліцензією GNU GPL. Здатний обробляти і кешувати HTTP, FTP, gopher, SSL і WAIS (прибрано в 2.6) запити, а також DNS. Найбільш часті запити зберігає в оперативній пам'яті. На поточний момент існують 2 стабільні версії squid: 2.7 та 3.3. З відмінностями осзнайомимось пізніше. Всі залежності при установці з пакетів у них однакові. Конфігураційний файл версії 2 сумісний з версією 3, але в 3 версії додані нові параметри. У статті буде розглянуто версію squid3. Варто так само відмітити, що якщо встановлювати squid3, то він свої конфігураційні файли буде тримати в /usr/local/etc/squid, і так само логи за замовченням в squid3 знаходяться в каталозі /var/log/squid/, а не /var/log/squid3/, як "думає" багато аналізаторів логів.

Купу разів згадане слово "кешування". А що ж це, власне, таке - кешування? Це спосіб зберігання завантажених з Інтернету об'єктів на сервері, що знаходиться ближче до комп'ютера користувача ніж джерело. Інтернет-об'єкт це файл, документ або відповідь на звернення до якого-небудь сервісу надається в Інтернет (наприклад, FTP, HTTP, або gopher). Клієнт запитує інтернет-об'єкт з кешу проксі-сервера; якщо об'єкт ще кешується, то проксі-сервер отримує об'єкт (або від вузла мережі зазначеної за запрошенням адресою URL, або від батьківського чи сусіднього кеша) і доставляє його клієнту.

Проксі-сервер Squid може працювати в наступних трьох основних режимах:

Прозорий режим

У цьому режимі HTTP з'єднання здійснюване клієнтами перенаправляється на проксі-сервер без їх відома або явної конфігурації (див. рисунок 14.2). У цьому режимі не потрібно налаштування клієнтів. Недоліки цього способу: необхідна конфігурація NAT і перенаправлення трафіку, аутентифікація клієнтів не працює, не перенаправляються FTP і HTTPS запити.

Рисунок 14.2 – Transparent режим Squid

Аутентифікуючий режим

Для роботи в цьому режимі клієнти повинні бути налаштовані для роботи з проксі-сервером (у настройках з'єднання повинен бути прописаний адресу проксі-сервера див. рисунок 14.3). Може виконуватися аутентифікація та авторизація клієнтів через Kerberos, Ldap, NTLM, IP і Radius. Можливо побудова взаємодії з серверами Microsoft Active Directory шляхом аутентифікації клієнтів - членів домену, використовуючи протокол Kerberos, і подальшої авторизації членів груп домену використовуючи LDAP у прозорому режимі (користувач вводить свій пароль тільки при реєстрації в домені). Для авторизованих груп можливе застосування різних налаштувань контролю доступу і QoS (delay pools).

Рисунок 14.3 – Режим аутентифікації Squid

Зворотній проксі-сервер

Проксі-сервер кешує вихідні дані. Зворотний проксі-сервер Squid отримує дані у HTTP сервера від імені клієнта і передає їх клієнту (наприклад, в Інтернет див. рисунок 14.4). Цей режим дозволяє здійснити:

- використання кешування, яке знижує навантаження на HTTP сервера;

- розподіл навантаження між HTTP серверами;

- маскування HTTP серверів і їх характеристик;

- запобігання web атак на сервера.

Рисунок 14.4 – Зворотній режим Squid

На наведених схемах стрілками позначені потоки проксіруючого трафіку. Рух даних потоків в FreeBSD найчастіше регулюється силами правил IPFW і настройками браузера. Крім того, дуже часто, функції маршрутизатора і проксі виконує одна машина.

Перед установкою і налаштуванням squid необхідно налаштувати мережу FreeBSD і переконатися, що машина, на якій працюватиме squid має доступ в зовнішню мережу і клієнти, які будуть використовувати даний проксі мають доступ до даної машини. Установка проксі-сервера squid як і іншого ПО в FreeBSD можлива різними способами, описаними в попередніх темах. Найпростішим способом встановлення являються порти. Отже, для встановлення squid необхідно встановити пакет squid3, для цього виконати ось таку команду (налаштування залишаємо за замовченням):

# cd /usr/ports/www/squid33

# make install clean

Як видно, при установці пакету, була спроба створення каталогу кешу, але так як він не налаштований, з’явилось попередження. Так само, squid треба додати в автозавантаження додавши строку squid_enable=yes в rc.conf, коли він запущений то за замовченням приймає підключення на всіх інтерфейсах. Але він не налаштований як треба, доступ до інтернет-сторінок через сервер обмежений. Конфіг сквіду розташований в /usr/local/etc/squid/squid.conf і складається з більш ніж 5500 рядків і синтаксис його практично не відрізняється від конфіга будь-якого іншого сервісу. Кидатися міняти якісь налаштування зрізу - не варто. Потім не розгребе. Давайте розглянемо конфіг, який нам пропонується за замовчуванням без коментарів і порожніх рядків:

# grep -v ^# /usr/local/etc/squid/squid.conf | grep -v ^$

acl localnet src 10.0.0.0/8 # RFC1918 possible internal network

acl localnet src 172.16.0.0/12 # RFC1918 possible internal network

acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

acl localnet src fc00::/7 # RFC 4193 local private network range

acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443

acl Safe_ports port 80 # http

acl Safe_ports port 21 # ftp

acl Safe_ports port 443 # https

acl Safe_ports port 70 # gopher

acl Safe_ports port 210 # wais

acl Safe_ports port 1025-65535 # unregistered ports

acl Safe_ports port 280 # http-mgmt

acl Safe_ports port 488 # gss-http

acl Safe_ports port 591 # filemaker

acl Safe_ports port 777 # multiling http

acl CONNECT method CONNECT

http_access deny !Safe_ports

http_access deny CONNECT !SSL_ports

http_access allow localhost manager

http_access deny manager

http_access allow localnet

http_access allow localhost

http_access deny all

http_port 3128

coredump_dir /var/squid/cache/squid

refresh_pattern ^ftp: 1440 20% 10080

refresh_pattern ^gopher: 1440 0% 1440

refresh_pattern -i (/cgi-bin/|\?) 0 0% 0

refresh_pattern . 0 20% 4320

Як видно, в конфігурації за замовчуванням, проксі-сервер працює і дозволяє звернення тільки з адреси 127.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Слід уважно переглянути весь список і закоментувати рядки з портами не потрібних або не використовуваних сервісів. Тобто якщо ми запустимо консольний браузер lunx з вказівкою на наш проксі, то зможемо побачити задану сторінку:

# # запускаємо браузер із зазначенням сторінки ya.ru:

# http_proxy = http://127.0.0.1:3128 lynx ya.ru

Йде пошук 'ya.ru' спочатку

# # в журналі бачимо звернення до заданої сторінки:

# cat /var/log/squid/access.log

1329527823.407 110 127.0.0.1 TCP_MISS/200 9125 GET http://ya.ru/ - DIRECT/93.158.134.203 text/html

Деякі параметри в конфігураційному файлі squid можуть застосовуватися кілька разів (наприклад acl). Деякі параметри, які особливо мають одне значення можуть використовуватися тільки один раз. При цьому, при використанні такого параметра 2 і більше разів - буде використано останнє значення, наприклад:

logfile_rotate 10

# Кілька значень - дорівнюватиме 5

logfile_rotate 5

Демоном керує sh-скрипт /usr/local/etc/rc.d/squid. Проксі-сервер являє собою процес /usr/local/sbin/squid. Демон підтримує безліч параметрів, з якими можна ознайомитися в man squid, але найчастіше для керування демоном цілком достатньо стандартного sh-скрипта.

Перевірити працездатність сервера squid можна таким чином:

# sockstat | grep 3128

squid squid 83174 10 tcp4 *:3128 *:*

# top -a -Usquid

83174 squid 1 20 0 66400K 16044K kqread 3 0:00 0.00% (squid-1) -f /usr/local/etc/squid/squid.conf (squid)

83176 squid 1 45 0 21868K 3032K sbwait 2 0:00 0.00% (logfile-daemon) /var/log/squid/access.log (log_file_daemon)

83172 squid 1 52 0 50016K 9732K wait 2 0:00 0.00% /usr/local/sbin/squid -f /usr/local/etc/squid/squid.conf

Як видно, при запуску даний демон стартує з параметрами -f /usr/local/etc/squid/squid.conf. Параметр -f задає конфігураційний файл, який використовується для роботи демона.

Програма squid3 з ключем -k і додатковим параметром дозволяє зручно керувати демоном, не перериваючи користувачів. Приклади:

-k - послати команду працюючому серверу:

- reconfigure - посилка сигналу HUP - перечитати і використовувати файл конфігурації;

- rotate - обрізати логи; сигнал USR1;

- shutdown - коректно зупинити squid; сигнал TERM;

- interrupt - вбити squid; сигнал INT;

- kill - жорстко вбити squid; сигнал KILL;

- debug - почати/закінчити повну трасування; сигнал USR2;

- check - перевірити коректність роботи squid (без повідомлень - працює коректно); сигнал ZERO;

- parse - перевірити синтаксис squid.conf.

Власне, змінивши squid.conf, виконавши squid3 -k parse, можна переконатися в коректності внесених змін, далі виконавши squi3 -k reconfigure можна практично не обриваючи користувачів застосувати зміни. Очищення кешу (перестворення) можна виконати командою squid3 -z.

При установці squid з пакетів, а не з портів, пакет є вже налаштованим і має якісь встановлені установки за замовчуванням. Наприклад, розташування каталогу журналу, каталогу конфігураційних файлів, підтримувані методи перевірки автентичності та безліч інших. Які налаштування задавати при складанні бінарного пакета визначається складальником пакету і співтовариством, яке здійснює підтримку дистрибутива. Якщо параметри за замовчуванням Вас не влаштовують, то необхідно буде встановити squid з портів і відповідно налаштувати його при зборці. Параметри, з якими був зібраний squid можна подивитися командою squid -v.

Опис налаштувань squid3 почнеться з основних налаштувань, які бажано провести при налаштуванні будь-якої конфігурації проксі-сервера. Конфіг сквіду розташований в /usr/local/etc/squid/squid.conf, це основний конфігураційний файл, в якому містяться всі налаштування. Так як там більше 5 тисяч рядків і що відразу налаштовувати щось не розібравшись - не варто. Синтаксис конфіга squid3 класичний: рядки з # - це коментарі, параметри представляють собою рядка "параметр значення", можливе використання змінних. Конфігураційний файл розбитий на розділи для зручності, але важливо пам'ятати, що розбір параметрів проводиться "зверху вниз" в порядку черговості. Так само, за допомогою параметра include можна підключати зовнішні конфігураційні файли.

За замовченням дозвіл імені вузла, на якому працює Squid, відбувається за допомогою gethostname(), залежно від налаштувань DNS, він іноді не може однозначно визначити ім'я, яке буде фігурувати в журналах і відповіді про помилки "Generated ... by server.com (squid/3.0.STABLE2)". Для коректного запису імені хоста, необхідно це ім'я (FQDN??) занести в параметр:

visible_hostname myproxy

За замовченням, squid приймає підключення на всіх інтерфейсах. Якщо сервер одним з мережевих інтерфейсів дивиться у зовнішній світ, то бажано обмежити підключення тільки на інтерфейсі локальної мережі (припустимо, 10.0.0.10/24). За це відповідає параметр http_port:

http_port 10.0.0.10:3128

Як працюють дані параметри можна побачити в наступному лістингу:

# sockstat | grep 3128

squid squid 83174 10 tcp4 *:3128 *:*

Після встановлення параметру:

# sockstat | grep 3128

squid squid 83174 10 tcp4 10.0.0.10:3128 *:*

Як видно, тепер демон працює тільки на інтерфейсі заданої мережі. Варто так само відзначити, що нові версії squid (<3.1) підтримують завдання декількох параметрів http_port. При цьому, у різних параметрів можуть бути зазначені додаткові ключі такі як intercept, tproxy, accel та ін., наприклад:

# grep ^http_port /usr/local/etc/squid/squid.conf

http_port 10.0.0.10:3128

http_port 10.0.0.10:3129 tproxy

Дані параметри задають режим роботи проксі-сервера. Наприклад tproxy (старий синтаксис - transparent) задає режим прозорого проксі. Дані режими гідні окремих статей і в майбутньому можливо буде розглянуто.

Тепер необхідно налаштувати клієнтський комп'ютер і користуватися Інтернетом. Але за замовченням, доступ дозволений тільки з локалхоста і при спробі доступу до веб користувач отримає помилку "Доступ заборонено". У журналі /var/log/squid/access.log буде приблизно таке повідомлення:

1329649479.831 0 10.0.1.55 TCP_DENIED/403 3923 GET http://ya.ru/ - NONE/- text/html

Для того, щоб клієнти локальної мережі могли працювати, необхідно налаштувати дозволу за допомогою списків контролю доступу.

Фактично налаштування доступу полягає в описі об'єкта доступу через параметр acl, а потім дозвіл або заборону роботи описаного об'єкту acl за допомогою параметра "http_access". Найпростіший формат даних налаштувань має наступний вигляд:

acl ім’я_списку тип_відбору характеристики_типу_відбору

де acl - параметр описує список контролю доступу, ім'я якого задається значенням ім’я_списку. Ім'я чутливо до регістру букв. тип_відбору задає тип, якому буде відповідати задана далі характеристики_типу_відбору. Дана характеристика може приймати такі часто використовувані значення, як src (від source) - джерело запиту, dst - адреса призначення, arp - МАС-адреса, srcdomain і dstdomain - доменне ім'я джерела і призначення відповідно, port - порт, proto - протокол, time - час і багато інших. Відповідно, значення характеристики_типу_відбору будуть формуватися в залежності від тип_відбору.

Можна вказувати кілька рядків acl з однаковими іменами і тип_відбору, в такому випадку, дані acl будуть об'єднані в один список з логічною операцією АБО. Наприклад:

acl site dstdomain site.com

acl site dstdomain site.org

# аналогічно запису:

acl site dstdomain site.com site.org

Словами це звучить так: списком доступу з ім'ям site належать всі запити, надіслані на сайт site.com АБО site.org. Крім того, ім’я_списку чутливі до регістру, тобто acl site і acl Site це 2 різних списку доступу.

Коли списки доступу сформовані, за допомогою параметра http_access дозволяємо або забороняємо доступ вказаному ACL. Загальний формат виклику такою:

http_access allow|deny [!]ім’я_списку

де, http_access - параметр задає наступне правило дозволу (allow) або заборони (deny) доступ, вказаному далі ім’я_списку. При цьому, необов'язковий знак оклику інвертує значення імені списку. Тобто при Знак оклику значення ім’я_списку буде звучати як всі, крім тих, хто в належить даному списку. Крім того, можна задавати декілька списків через пробіл, тоді доступ буде дозволений за умови приналежності до всіх заданих списками. При цьому, всі дозвільні правила необхідно вказувати до заборонного ВСІ правила:

http_access deny all

Може виникнути резонне питання: навіщо задавати дане правило, якщо ми, наприклад, дозволимо доступ до сквіду тільки обраним acl? Адже інші, хто не потрапляють в даний acl також "проходять повз"... Все просто. За замовчуванням, squid використовує дозволяюче/забороняє правило протилежне останньому. Наприклад:

# у нас є єдине дозволяюче правило для деякого acl user:

http_access allow user

# якщо при доступі до squid, клієнт не потрапив у цей acl, то до нього буде застосовано дію deny.

# а якщо у нас є два правила

http_access allow user

http_access deny user2

# і клієнт не входить ні в acl user, ні в acl user2, то до нього застосується allow.

# тобто дія протилежне останнього http_access deny user2

Саме тому скрізь рекомендується завершувати дозволяючі правила - заборонним для всіх.

Це, як говориться - основи основ. Давайте розглянемо простий приклад. Припустимо, у нас є 2 мережі 10.0.1.0/24 і 10.0.0.0/24, а так само хост 10.0.4.1, яким необхідно дозволити доступ до Інтернету. Для дозволу доступу необхідно створити опис нового списку доступу в секції "ACCESS CONTROL" файлу squid.conf:

acl lan src 10.0.1.0/24 10.0.0.0/24

acl lan src 10.0.4.1

Для більшої зручності, можна задати ці правила в окремому файлі, вказавши шлях до нього в місце характеристики_типу_відбору. Ось:

# # створимо окремий каталог для зберігання списків доступу

# mkdir /usr/local/etc/squid/acls/

# занесемо наші підмережі та хости в окремий файл

# ee /usr/local/etc/squid/acls/lan.acl

# cat /usr/local/etc/squid/acls/lan.acl

10.0.1.0/24

10.0.0.0/24

10.0.4.1

# # опишемо створений файл в конфігураційному файлі (шлях потрібно взяти в лапки)

# grep lan.acl /usr/local/etc/squid/squid.conf

acl lan src "/usr/local/etc/squid/acls/lan.acl"

Дозволимо створеному списку доступу lan доступ в Інтернет і скажемо сквид перечитати конфігураційний файл:

# grep lan /usr/local/etc/squid/squid.conf | grep acce

http_access allow lan

# /usr/local/etc/rc.d/squid restart

Reloading Squid HTTP Proxy 3.x configuration files.

done.

У двох словах можна сказати, що acl ідентифікує Web запит, а http_access дозволяє або забороняє ідентифікований запит.

Важливим моментом налаштування squid є налаштування параметрів кешування в squid. Місце розміщення кешу задається параметром cache_dir в squid.conf. Формат параметр наступний:

cache_dir тип шлях розмір L1 L2 [options]

де, тип - це алгоритм формування кешу, може бути: ufs (unix file system), aufs (async ufs), diskd (зовнішні процеси для уникнення блокування squid на дисковому введенні/виведенні). Рекомендується використовувати ufs, хоча деякі хвалять aufs. Шлях - задає місце розміщення кешу в файлової системі (повинен існувати і мати права доступу на запис для користувача, під яким працює squid - зазвичай proxy). Розмір - задає максимальний розмір, після якого кеш почне очищатися. У мережі існує безліч холіварів за цим параметром. Ідеальний розмір кеша - від 2 до 10 ГБ залежно від числа клієнтів. Приблизно 1 ГБ кеша на кожні 100 тисяч запитів/день. Я дотримуюся значення в 5 Гб. У Squid кожен кешуючий об'єкт розташовується в окремому файлі, звукові файли не звалюються в одне місце, а використовується дворівнева ієрархія каталогів. Кількість каталогів 1 і 2 рівнів і визначають параметри L1 і L2. Ці значення можна залишити за замовчуванням. Але для орієнтування в ситуації наведу цитату з bog.pp.ru:

Експеримент показав, що при кеші в 700 МБ використовується тільки 2 директорії першого рівня. Тобто для при стандартній структурі директорій кеша в нього "з комфортом" влазить мільйон об'єктів (9 GB), якщо їх більше, то треба збільшити число директорій верхнього рівня

Можна використовувати декілька cache_dir. Це позитивно позначається на продуктивності, особливо, якщо розмістити кеш на різних дисках. Ще більше прискорити роботу кеша можна, розмістивши кеш в tmpfs. Для кожного параметра cache_dir можна в розділі options визначити параметр read-only (тільки читання) і max-size (максимальний розмір об'єкта).

Максимальний розмір об'єкта в кеші визначається параметром maximum_object_size, значення за замовчуванням - 4 Мб. Іноді значення необхідно збільшити до 60 Мб, якщо, наприклад, співробітникам в локальній мережі часто доводиться викачувати однотипні файли до зазначеного розміру:

maximum_object_size 61440 KB

Аналогічно є і параметр minimum_object_size відповідає за мінімальний розмір об'єкта, за замовчуванням його значення "0" тобто вимкнено. Рекомендується значення цього параметра збільшити до 2-3 Кб, що знизить навантаження на диск при пошуку маленьких об'єктів.

Об'єм ОЗУ, використовуваний сквидом задається в параметрі cache_mem, значення за замовчуванням 256 Мб (у версії 3.1). Міняти це значення варто лише в тому випадку, якщо сквід вас про це попросить в логах. Після даних змін, необхідно перезапустити сквід, при цьому буде створено структуру каталогів.

Що є прозорий проксі? Це режим роботи проксі сервера, коли клієнт не налаштовується на роботу через проксі і посилає запити в мережу по протоколу HTTP, як якби клієнт браузер працював безпосередньо з веб-сервером. При цьому, силами firewall (у FreeBSD - IPFW) вихідні запити на HTTP направляються на порт, на якому запущений проксі. Проксі-сервер ж, у свою чергу, перетворює HTTP запити в запити протоколу проксі-сервера і посилає відповіді клієнту, як веб сервер. Тобто для клієнта прозоро відбувається взаємодія з проксі-сервером.

Важливо розуміти і знати! Даний метод підтримує тільки HTTP протокол, і не підтримує gopher, FTP або інше проксінг. А так само, Squid не вміє одночасно працювати в прозорому режимі і в режимі аутентифікації.

Для налаштування прозорого режиму, необхідно:

1. Задати прозорий режим в налаштуваннях проксі. Це робиться в параметрі http_port, наприклад:

http_port ip:port transparent

2. Загорнути користувачів відповідним правилом на потрібний порт силами IPFW:

ipfw add 100 fwd SQUIDIP,3128 tcp from any to any 80 recv IFACE

Все. Можна насолоджуватися загорнутими і нічого не підозрюють користувачами на наш проксі-сервер.

Діагностика роботи squid полягає в перегляді журналів, розташованих в /var/log/squid. Більшість проблем вирішується даними способом. Якщо це не допомогло вирішити проблему, то переключивши демона в дебагом режим командою squid -k debug проблему буде знайти простіше. Власне, що з себе представляє лог сквіду? Файли логів містять різну інформацію про завантаження і продуктивності Squid. У log пишуться окрім інформації про доступ, /preе ще і системні помилки і інформація про споживання ресурсів, таких, наприклад, як пам'ять або дисковий простір.

Формат log файлів Squid представляє собою рядок із значень, розділених одним або декількома пропусками:

час.мс час_відгуку ip_src Squid_req_status/HTTP_status byte_snd метод URL user squid_her_status/ip_dst MIME

- час - час у форматі unix (Кількість секунд від 00:00 1970.01.01);

- мс - мілісекунди з точністю до 3х знаків;

- час_відгуку - час відгуку, мілісекунд;

- ip_src - IP адреса джерела;

- Squid_req_status - статус запиту у squid (наприклад, TCP_HIT для раніше кешіруемих об'єктів, TCP_MISS якщо запитуваний об'єкт узятий не з локального кеша, UDP_HIT і UDP_MISS те ж для братських запитів);

- HTTP_status - статус http протоколу (200 для вдалих, 000 для UDP запитів, 403 для перенаправлень, 500 для помилок);

- byte_snd - передано, байт у відповідь включаючи HTTP заголовок;

- метод - метод запиту GET або POST;

- URL - запитаний url-адресу;

- user - ім'я авторизованого користувача;

- squid_her_status - статус ієрархії squid - Результат запитів до братських/батьківським кешам;

- ip_dst - IP адреса запитуваного вузла;

- MIME - mime-type.

Розглянемо на прикладі:

1329732295.053 374 10.0.1.55 TCP_MISS/200 1475 GET http://www.youtube.com/live_comments? - DIRECT/173.194.69.91 text/xml

Як видно, запит зроблено у 1329732295.053, відповідь віддаленого сервера склав 374 мс, хост, що запитав сторінку має IP 10.0.1.55, запитаний об'єкт був переданий не з локального кешу (TCP_MISS), код відповіді сервера - 200, клієнту передано 1475 байт методом GET, був запитаний URL http://www.youtube.com/live_comments?, ім'я користувача не визначено, об'єкт був отриманий безпосередньо від сервера з IP 173.194.69.91, був переданий текст, тому що mime - text/xml.

Читайте також:

Поняття проксі-серверу

<== попередня сторінка	\|	наступна сторінка ==>
Поняття проксі-серверу	\|	Журналювання в ОС FreeBSD

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.025 сек.