Статьи

Кешуючий проксі-сервер Squid для операційних систем сімейства Linux

  1. Типи проксі-серверів
  2. Проксі-сервер Squid
  3. установка сервера
  4. Параметри для роботи з сусідніми кеш-серверами
  5. Параметри розміру локального кеша
  6. Аутентифікація користувачів сервера
  7. Аналізатор логів проксі-сервера Squid - LightSquid
  8. Висновок

Максим Афанасьєв

Типи проксі-серверів

Проксі-сервер Squid

установка сервера

Параметри для роботи з сусідніми кеш-серверами

Параметри розміру локального кеша

Аутентифікація користувачів сервера

Аналізатор логів проксі-сервера Squid - LightSquid

висновок

Проксі-сервери (proxy server) з'явилися на зорі епохи Інтернету, коли користувачів цієї мережі ставало все більше і більше, а зовнішні IP-адреси коштували чималих грошей. Тоді основним призначенням proxy-серверів була організація доступу в Інтернет локальних користувачів без додавання їх комп'ютерів до Глобальної мережі, тобто без призначення зовнішніх IP-адрес комп'ютерів, а вихід в Інтернет здійснювався тільки з одного зовнішнього IP-адреси. Слово proxy в перекладі з англійської означає «довірена особа» або «представник». Умовно кажучи, проксі-сервер діє від імені клієнта в Інтернеті, і для інших користувачів Мережі видно тільки сам сервер (його IP-адреса), а не клієнт (IP-адреса комп'ютера користувача прихований від сторонніх очей). Таким чином, крім загального доступу в Інтернет локальних користувачів, які не мають прямого виходу в Мережу, такі сервери дозволяють дотриматися приватність роботи в Інтернеті. Внаслідок того що комп'ютери звичайних користувачів не розміщені безпосередньо в Мережі, знижується загроза хакерських атак, оскільки прямого доступу до комп'ютерів локальної мережі немає.

Звичайні, широко застосовуються зараз маршрутизатори по суті є одним з видів проксі-серверів - NAT proxy. Вони теж дозволяють організувати доступ в Інтернет локально підключених до маршрутизатора комп'ютерів шляхом підміни вихідного IP-адреси в IP-пакетах. Але маршрутизатор, який підтримує технологію NAT (Network Address Translation), має деякі мінуси в порівнянні зі звичайним програмним проксі-сервером. Маршрутизатор ніяк не аналізує проходить через нього трафік і типи протоколів, через які користувачі працюють з Інтернетом, тому адмініструвати (в даному випадку обмежувати користувачів за конкретними параметрами при доступі до Мережі) такі пристрої практично неможливо. Проксі-сервер може знаходитися в будь-якій точці Інтернету і, якщо правила доступу дозволяють, дозволяє працювати з будь-яким клієнтом незалежно від його місцезнаходження. Для роботи NAT, як правило, необхідно фізичне підключення локального комп'ютера до маршрутизатора (наприклад, через локальну мережу), оскільки маршрутизатор працює через жорстко встановлені маршрути пакетів. Також варто відзначити, що звичайний маршрутизатор не дозволяє кешувати часто використовувані об'єкти для більш швидкого звернення до них користувачів, оскільки він тільки перенаправляє пакети від одного вузла Мережі до іншого.

Типи проксі-серверів

Існує кілька типів проксі-серверів, кожен з яких має вузьку спеціалізацію, тобто підтримує роботу тільки з одним або декількома протоколами. Найпоширенішими на даний момент є http-, Socks- і NAT-проксі. Останні входять до стандартні компоненти сучасних операційних систем, таких як Linux і Windows. За своїми характеристиками програмні проксі-сервери NAT практично не відрізняються від апаратних (маршрутизаторів) і істотно поступаються в адмініструванні вузькоспеціалізованим проксі-серверів. Розглянемо найбільш популярні типи проксі-серверів.

HTTP проксі-сервер - один з найпоширеніших типів проксі-серверів в світі. Як видно з назви, він призначений для роботи з HTTP-протоколом і дозволяє працювати браузерам і іншим подібним програмам. Браузер запитує сторінку у проксі-сервера, який, в свою чергу, запитує її з власного кешу. Якщо сторінка не знайдена в кеші або має параметри, які забороняють її кешування, проксі-сервер запитує її біля сусіднього проксі-сервера або безпосередньо звертається до сайту і після успішного завантаження сторінки видає її призначеному для користувача додатком. Оскільки далі в статті буде розглядатися один з HTTP проксі-серверів - Squid, перерахуємо основні можливості цього типу проксі-серверів:

  • дозволяють кешувати часто використовувані дані (веб-сторінки), завдяки чому скорочується зовнішній трафік і прискорюється завантаження сторінок кінцевим користувачем. Однак Інтернет стає все більш динамічним, і часто багато веб-сервери забороняють проксі-серверів кешувати дані або накладають обмеження на певні сторінки, тому приріст в економії трафіку не дуже істотний і може становити до 15%. Якщо питання про трафік стоїть гостро, то багато HTTP проксі-сервери підтримують ігнорування заголовків META в сторінках, тим самим дозволяючи кешувати динамічні дані;
  • обмежують доступ не тільки до певних сайтів, але і до конкретних розділів сайту, за рахунок чого досягається велика гнучкість в адмініструванні користувачів. Крім того, доступ до сайтів певної групи можна дозволяти лише після додаткової аутентифікації;
  • деякі HTTP проксі-сервери дозволяють обмежувати швидкість завантаження інформації, розставляючи пріоритети по типам файлів. Завдяки цьому можна блокувати високу швидкість завантаження, наприклад відеофайлів або музичних композицій;
  • підтримують різання рекламних блоків (банерів) шляхом заміщення вихідної картинки або аплета своїм кодом, що скорочує додатковий трафік;
  • можливо поділ конкретних сайтів на роботу через ті чи інші додаткові проксі-сервери або інтернет-канали, що дозволяє більш економно управляти трафіком і вибирати оптимальні канали зв'язку;
  • одна з важливих особливостей HTTP проксі-сервера - можливість ведення докладної статистики по кожному користувачеві. Це дозволяє аналізувати використання трафіку окремими користувачами, а також виявляти найбільш часто застосовуються веб-сервери;
  • дозволяють працювати не тільки з протоколом HTTP, але і з іншими подібними протоколом - FTP, а в разі необхідності - блокувати його.

HTTPS проксі-сервер - по суті справи, це точно такий же HTTP проксі-сервер, як і описаний вище. Основною відмінністю даного типу проксі-серверів є можливість шифрування переданих між клієнтом, проксі-сервером і кінцевим сервером даних, про що і повідомляє буква «s» в його назві. Проксі-сервер, що працює по протоколу HTTPS, лише організовує канал передачі між клієнтом і сервером і не дозволяє аналізувати проходить по ньому інформацію. Відповідно можливості HTTPS, в порівнянні з HTTP, істотно у же. У той же час цей проксі-сервер може бути використаний в якості проксі-сервера для інших, відмінних від HTTPS протоколів - pop, smtp, imap і ряду інших. У будь-якому випадку проксі-сервер такого типу значно підвищує безпеку конфіденційної інформації, хоча і має деякі недоліки. Зазвичай HTPPS проксі-сервер суміщають з HTTP проксі-сервером, що робить його більш універсальним і гнучким при налаштуванні клієнтів.

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

SOCKS проксі-сервер - працює на основі спеціально розробленого протоколу SOCKS (скорочено від SOCKetS). На даний момент останньою версією протоколу є SOCKS 5. Вона дозволяє виробляти аутентифікацію користувачів на серверній стороні, що підвищує гнучкість настройки подібних систем. Проксі-сервери SOCKS є універсальними і дозволяють користувачеві працювати через будь-який інший протокол з практично будь-яким видом сервісів в Інтернеті. Одна з особливостей проксі-серверів цього типу - можливість роботи від зовнішніх клієнтів з внутрішнємережевий серверами, розташованими за міжмережевими екранами. Такий підхід дозволяє широко використовувати цей вид проксі для забезпечення доступу клієнтів як з локальної мережі, так і в зворотному напрямку. Оскільки цей протокол є одним з найпопулярніших на даний момент, створені спеціальні програми, наприклад FreeCap (www.freecap.ru), що надають можливість пропускати клієнтське програмне забезпечення в Інтернет через цей протокол навіть за відсутності підтримки його цим програмним забезпеченням.

Крім перерахованих вище основних типів проксі-серверів, які охоплюють більшість поширених протоколів передачі даних, існують вузькоспеціалізовані сервери, що забезпечують коректну роботу з тими чи іншими додатками. На додаток до всього вищесказаного відзначимо, що проксі-сервери, до яких може отримати доступ будь-який користувач Інтернету, називаються відкритими. Таких серверів досить багато по всьому світу, і орієнтовані вони в першу чергу на тих користувачів, які хочуть зберегти відвідування сторінок або серверів в таємниці від провайдера або від мережевого адміністратора. Однак найчастіше ці сервери можуть прослуховуватися, оскільки будь-який проксі-сервер (його трафік) без підтримки шифрування переданих даних може бути прослуханий на будь-якому з пристроїв, які знаходяться на шляху від клієнта до сервера.

Проксі-сервер Squid

Проект проксі-сервера Squid (www.squid-cache.org) свого часу відокремився від нині платного проекту Harvest і розробляється декількома ентузіастами на чолі з Duane Wessels з Національної лабораторії з дослідження мереж (National Laboratory for Applied Network Research). Сервер Squid - це високопродуктивний кешуючий проксі, орієнтований передусім на роботу з користувачами, які займаються активним серфінгом в Інтернеті. Squid підтримує роботу користувачів з такими протоколами, як FTP, HTTP, HTTPS і GOPHER. На відміну від інших подібних проектів, проксі-сервер Squid має цікаву особливість - виконання запитів користувачів реалізовано в ньому як один великий Неблокована процес введення-виведення, що забезпечує більш високу продуктивність сервера в цілому. Оскільки сервер Squid є Кешуються проксі, він підтримує широкі можливості з побудови ієрархічної структури зв'язку кеш-серверів на основі протоколів ICP / UDP (Internet Cache Protocol), HTCP / TCP і multicast. Така система дозволяє отримати високу продуктивність і оптимізувати пропускну здатність каналу в Інтернет. Кеш сервера поділяється на віртуальний, який знаходиться в оперативній пам'яті комп'ютера, і звичайний, який зберігається на жорсткому диску. Найбільш часто використовувані об'єкти зберігаються в оперативній пам'яті, що прискорює процес їх відсилання клієнтам. Також у віртуальній пам'яті зберігається б про більша частина запитів DNS. Squid в повній мірі підтримує SSL (HTTPS), що забезпечує конфіденційність інформації, що передається користувачами інформації і приватність їх роботи в Інтернеті. Також не можна залишити без уваги широкі можливості по аутентифікації користувачів на основі різних методик: NCSA, LDAP, MSNT, NTLM, PAM, SMB, SASL і ін. Всі додаткові програми для аутентифікації користувачів йдуть в комплекті з основним ядром програми. Як видно з перерахованих методик, Squid підтримує авторизацію користувачів засобами сервісів не тільки на Linux-, але і на Windows-платформі (MSNT і NTLMv1). У майбутньому очікується підтримка сервісу NTLMv2, який використовується в операційних системах Windows 2003 Server і Vista.

установка сервера

Проксі-сервер Squid поставляється практично у всіх дистрибутивах операційних систем сімейства Linux. Якщо його немає в комплекті операційної системи, то його можна завантажити з сайту розробника - www.squid-cache.org. На момент написання цієї статті вже з'явилася офіційна версія 3.0STABLE1 - це означає, що майже чотирирічна робота над новою версією 3.0 успішно завершена. Однак поки її можна встановити тільки для тестування, так як вона ще сира і не обкатана адміністраторами. Тому ми розглянемо одну зі старих версій Squid - 2.6STABLE12. На даний момент останньою версією серії 2.6 є 2.6STABLE18 від 10 січня 2008 року.

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

Установку проксі-сервера Squid також можна здійснити через програмні пакети типу yum або apt-get, які автоматично встановлять пакет Squid і сконфігурує його без участі користувача. Приклад команди установки:

yum install Squid

або, якщо Squid вже встановлено, але потребує оновлення:

yum update squid

Після установки проксі-сервер Squid можна запускати з командного рядка через команду squid або, що більш правильно, service squid start, при необхідності можна додати цей сервіс в скрипт (/etc/rc.d) автозавантаження при старті системи.

Запустивши сервіс в перший раз з настройками за замовчуванням, користувач повинен побачити наступну картину по команді ps axf | grep squid:

29311? Ss 0:00 squid -D

29313? S 2:03 \ _ (squid) -D

29315? Ss 0:01 \ _ (unlinkd)

Це свідчить про те, що сервіс squid запущений і чекає вхідних з'єднань. Додаткова програма unlinkd, для якої батьківським процесом є squid, відповідає за очищення кеша. Якщо виникли проблеми з запуском сервісу, процес завис або взагалі не запустився, слід подивитися log-файл, який генерується автоматично і розміщений в папці / var / log / squid /, - це дасть уявлення про помилку, через яку сервіс працює некоректно.

Перед тим як запускати сервер, необхідно відредагувати конфігураційний файл squid.conf, який за замовчуванням розташовується в папці / etc / squid /. За замовчуванням жоден з користувачів не зможе скористатися проксі-сервером без редагування конфігураційного файлу.

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

Параметри з'єднань клієнт-сервер і сервер-сервер

параметр http_port

Даний параметр може бути записаний кількома способами, наприклад:

порт

Ім'я хоста: порт

IP адреса: порт

Порт вказує на порядковий номер порту, на якому проксі-сервер буде прослуховувати вхідні з'єднання від клієнтів. За замовчуванням більшістю HTTP проксі-серверів використовується порт 3128. Ім'я хоста або IP-адреса явно вказує, на якому з інтерфейсів буде працювати проксі-сервер. Якщо у вашій системі декілька інтерфейсів, а доступ дати необхідно тільки двох мереж з трьох, то треба перерахувати їх в цьому параметрі у вигляді:

http_port 10.0.0.1:3128

http_port 192.168.0.1:3128

параметр https_port

За своїми функціями цей параметр схожий з http_port, але призначений для завдання строгих опцій роботи по протоколу SSL (HTTPS).

Синтаксис даної опції виглядає так:

https_port ip: port cert = certificate.pem key = key.pem version = sslversion options = option,

де certificate.pem - сертифікат шифрування; key.pem - ключ шифрування; options і version вказують на параметри SSL. Version може приймати значення 1, 2, 3 або 4, де 1 - це автоматичний режим; значення 2 і 3 строго вказують на застосовувану при роботі версію SSL (друга або третя); 4 - на TSLv1. Options працює за принципом від протилежного, тобто виключає невикористовувані версії SSL. За замовчуванням https_port закоментований, і застосовуються стандартні значення. В основному він використовується в тому випадку, коли проксі-сервер працює в режимі акселератора сервера apache.

параметр icp_port

Даний параметр задає порт, який буде прослуховуватися Squid для обміну інформацією з іншими кеш-серверами по протоколу ICP (Internet Cache Protocol). За замовчуванням він має значення 3130. Якщо сервер не передбачається використовувати в зв'язці з додатковими кеш-серверами, то цю опцію слід відключити для оптимізації роботи сервера. Відключення даного параметра здійснюється шляхом додавання (раскомментірованія) рядки icp_port і виставлення значення 0. Також відключення цієї опції можна домогтися, додавши опцію -u в командному рядку при запуску сервісу Squid.

параметр htcp_port

Параметр htcp_port відповідає за порт, який буде використовуватися проксі-сервером Squid для обміну пакетами між сусідніми кеш-серверами по протоколу HTCP. Стандартний порт для цього протоколу - 4827. Однак варто зазначити, що за замовчуванням при установці Squid через yum цей протокол відключений.

Параметр mcast_groups і параметри UPD для Multicast

Опція mcast_gropus задає Параметри з'єднання через Multicast по UDP. За замовчуванню в файлі конфігурації немає Вказівок ні на одну з груп. Перед тим як використовувати цю функцію, необхідно вникнути в систему мультикаст передачі даних. Якщо група задана явно, потрібно ввести додаткові параметри:

  • udp_incoming_address - відповідає за вхідні з'єднання;
  • udp_outgoing_address - відповідає за вихідні з'єднання.

За замовчуванням дані параметри закоментовані і відключені.

Параметри для роботи з сусідніми кеш-серверами

параметр cache_peer

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

cache_peer hostname type proxyport icpport options,

де hostname - DNS-ім'я кеш-сервера, з яким буде працювати squid; proxyport - порт, на якому працює Squid (вказується в параметрі http_port на сусідньому кеш-сервері); icpport - порт, через який відбувається обмін службовою інформацією з сусіднім кеш-сервером (повинен бути вказаний той порт, який приводиться в параметрі icp_port на сусідньому кеш-сервері); type - тип з'єднання (може приймати значення parent, multicast і sibling); options - різні параметри з'єднання, в основному використовується параметр proxy-only.

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

параметр cache_peer_domain

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

cache_peer_domain cachehost domain! domain ...,

де cachehost - ім'я сусіднього кеш-сервера; domain - допустимий домен (наприклад, .ru або .net).

Знак оклику означає зворотну дію: не обслуговувати даний домен за допомогою цього кеш-сервера.

Параметри таймаутів з'єднання з сусідніми серверами

Параметр icp_query_timeout або maximum_icp_query_timeout задає значення часу очікування відповіді від віддаленого сервера в мілісекундах по протоколу ICP.

Параметр mcast_icp_query_timeout - те ж саме, але для multicast.

Параметр dead_peer_timeout задає час в секундах, після чого хост, який не відповідає, вважається відключеним і запити до нього не надсилаються.

параметр hierarchy_stoplist

Дана опція дозволяє вказати рядок. Якщо рядок буде знайдена в URL, цей об'єкт не буде запитуватися у кеш-серверів і не буде там розміщуватися. За замовчуванням цей параметр блокує збереження запитів cgi-bin на віддалених кеш-серверах для забезпечення безпеки.

параметр no_cache

Як видно з назви, даний параметр блокує завантаження в кеш об'єкта. Об'єкт визначається через формулювання acl, про яку буде розказано трохи нижче. За замовчуванням цей параметр блокує будь-яке збереження об'єктів, в URL яких зустрічається рядок cgi-bin. Синтаксис блокування cgi-bin виглядає наступним чином:

acl QUERY urlpath_regex cgi-bin /?

no_cache deny QUERY

Параметри розміру локального кеша

параметр cache_mem

Один з головних параметрів, що визначає обсяг оперативної пам'яті, яка буде застосовуватися Squid для зберігання часто використовуваних об'єктів. Об'єкти, в свою чергу, розбиваються на блоки по 4 Кбайт (розмір блоку визначається параметром maximum_object_size_in_memory), що значно підвищує швидкість обробки і передачі інформації кінцевому користувачу. За замовчуванням цей параметр дорівнює 8 Мбайт, однак, якщо ви володієте надмірною кількістю оперативної пам'яті, значення цього параметра можна збільшити, що підвищить продуктивність сервера.

Параметри cache_swap_low і cache_swap_high

Дані параметри вказують на максимальне (у відсотках) застосування дискового простору, відведеного під зберігання кешу. Як тільки нижній поріг буде досягнутий (cache_swap_low), Squid буде замінювати невикористаний кеш іншим, більш новим контентом. Якщо ж пройдено верхній поріг, сервер буде більш агресивно видаляти невикористовувані файли. Таким чином, досягається ротація і оновлення кешу. За замовчуванням для нижнього порога встановлено значення 90%, а для верхнього - 95% від розміру, відведеного під кеш.

Параметри maximum_object_size і minimum_object_size

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

Параметри cache_replacement_policy і memory_replacement_policy

Дані опції визначають зовнішній вигляд алгоритм, за яким буде виконуватися заміна файлів в кеші (в залежності від назви - в оперативній пам'яті (memory_replacement_policy) або на диску (cache_replacement_policy)). За замовчуванням застосовується алгоритм lru, який зберігає в кеші найбільш часто використовувані об'єкти. Алгоритм GDSF задає параметри кешу таким чином, щоб зберігати часто вживані об'єкти з дуже маленьким розміром. За правилом LFUDA кеш зберігає часто використовувані об'єкти великого розміру, нехтуючи при цьому малими об'єктами.

параметр cache_dir

Ще один з основних параметрів проксі-сервера. Синтаксис виглядає наступним чином:

cache_dir type dir mbytes L1 L2 options,

де type - тип збереження, за замовчуванням Squid зберігає і працює з кешем в режимі ufs, існують також режими aufs і diskd (зовнішня програма, яку поставляють з проксі-сервером); dir - вказівка директорії, де будуть зберігатися файли з кешем; mbytes - максимальний розмір цієї директорії; L1 - кількість піддиректорії в кореневому каталозі кешу; L2 - кількість піддиректорій в директоріях першого рівня (L1).

Стандартні налаштування кешу мають такий вигляд:

cache_dir ufs / var / spool / squid 100 16 256

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

Аутентифікація користувачів сервера

Режим аутентифікації користувача задається параметром auth_param. Він передбачає вибір з кількох способів авторизації кінцевого користувача, які можуть бути скомбіновані між собою в залежності від необхідності і застосовуваних програм (браузерів клієнтів і т.п.). Опис кожного з методів займе не одну сторінку, тому розглянемо найбільш простий приклад, коли користувачі визначаються в залежності від IP-адреси їх комп'ютера. За замовчуванням Squid налаштований саме на таку систему аутентифікації і необхідні рядки параметрів Розкоментувати. Однак для роботи користувачів внутрішньої мережі потрібно внести деякі корективи в інші параметри, які і будуть розглянуті далі.

параметр acl

Даний параметр називається access list і відповідає за доступ до сервера клієнтів відповідно до їх IP-адресами або іншими параметрами, заданими опцією string. Синтаксис цього параметра цілком звичайний для Linux-платформ:

acl aclname acltype string,

де aclname - назва облікового запису, яке буде використано в інших параметрах із застосуванням acess list; acltype - тип, за яким визначається можливість доступу комп'ютера користувача до сервера; string - значення, залежне від зазначеного типу.

Опція acltype може бути задана наступними значеннями:

  • dst - якщо сайт, на який йде запит від клієнта, відповідає опції string, то цей користувач має до нього доступ;
  • src - діапазон або одиничний IP-адреса клієнта;
  • mac - MAC-адресу клієнта;
  • srcdomain - клієнт конкретного домену;
  • dstdomain - доступ до домену;
  • time - час доступу (daydayday ... h1-h2);
  • port - доступ до певного порту або діапазону портів;
  • proto - доступ по певному протоколу;
  • browser - доступ певного браузера.

За замовчуванням в файлі конфігурації створений access list, який включає всіх можливих клієнтів, оскільки визначає діапазон всіх можливих IP-адрес:

acl all src 0.0.0.0/0.0.0.0.

Однак доступ до цього access list закритий для роботи через проксі-сервер за допомогою команди:

http_access deny all

Таким чином, якщо потрібно створити відкритий для всіх користувачів Інтернету проксі-сервер, досить замінити deny на allow - і все повинно запрацювати. Однак в деяких випадках це не спрацьовує. Необхідно дозволити ще одну опцію - http_reply_access allow all, яка за замовчуванням повинна бути дорівнює цьому значенню, проте так відбувається далеко не завжди. Ми розглянемо приклад забезпечення доступу комп'ютерів з певними IP-адресами. Для цього створимо два access list, які будуть визначати користувачів з конкретних мереж:

acl corbina src 10.156.0.0/255.255.0.0

acl local src 192.168.192.0/24

Потім їм необхідно дозволити доступ, додавши рядки:

http_access allow corbina

http_access allow local

І заключний етап:

http_reply_access allowcorbina

http_reply_access allow local

Щоб заборонити доступ до сервера для клієнтів, які виходять за межі описаних мереж, додаємо на всякий випадок рядки:

http_reply_access deny all

http_access deny all

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

Якщо все прописано правильно і ніяких помилок немає, користувачі з цього діапазону адрес отримуватимуть доступ в Інтернет через проксі-сервер. Але тут виникає резонне питання: як аналізувати проходить трафік і отримувати хоч якусь інформацію про те, хто користується Інтернетом і на які сайти заходить? Читання логів в текстовому редакторі не дасть ніякої суттєвої інформації, тому необхідно знайти аналізатор логів, який надасть подібну інформацію.

Аналізатор логів проксі-сервера Squid - LightSquid

Безумовно, існує безліч різних лог-аналізаторів - як універсальних, так і вузькоспеціалізованих. Для проксі-сервера Squid є кілька проектів, один з яких - LightSquid. Це простий в установці і в той же час інформативний демон, який дозволяє отримати б о більшу частину інформації про що проходить через проксі-сервер трафіку і його клієнтів. На сайті розробника (lightsquid.sourceforge.net) можна завантажити останню версію даної програми.

Установка версії LightSquid 1.7.1 передбачає розпакування архіву з дистрибутивом і розміщення файлів на web-сервері. Після перенесення файлів (наприклад, в каталог / var / www / html / lightsquid) необхідно дати права доступу на виконання файлів * .cgi і * .pl від імені web-сервера (в більшості випадків це користувач apache і група apache):

chmod + x * .cgi

chmod + x * .pl

chown -R apache: apache *

Потім в файлі конфігурації apache треба додати можливість запуску скриптів cgi в цій директорії:

<Directory "/ var / www / html / lightsquid»>

AddHandler cgi-script .cgi

AllowOverride All

</ Directory>

Після додавання цих рядків в конфігураційний файл потрібно перезапустити apache:

service httpd restart

Слідом за цими командами необхідно відредагувати основний конфігураційний файл lightsquid.cfg. В даному випадку потрібно змінити змінну $ lang і виставити їй значення ru замість eng, щоб статистика відображалася російською мовою. А також, якщо шлях до lightsquid нестандартний, підправити шляху до скриптів. За замовчуванням в файлі конфігурації дозволена робота з зображеннями, тобто на підставі даних lightsquid будує прості графіки. Бібліотека Perl-GD не завжди встановлюється разом з базовим пакетом Perl, тому необхідно встановити її, виконавши команду:

yum install Perl-GD.

Після цього, якщо все введення установок можна запустити так званий парсер (обробник лог-файлів) - lightparser.pl. Якщо статистика по користувачах вже накопичилася, вона буде відображена на web-сервері при виклику папки lightsquid (див. Малюнок).

Висновок

Звичайно, дешеві маршрутизатори, швидкі й широкі канали доступу в Інтернет, а також доступність зовнішнього IP-адреси істотно зменшили масштаби використання проксі-серверів у всьому світі. Однак необхідно розуміти, що застосування правильно сконфигурированного проксі-сервера у великій компанії в сукупності з NAT-проксі більш надійно, ніж використання тільки NAT-проксі, оскільки останні не дають можливості гнучко встановлювати правила для конкретних сервісів і не дозволяють обмежувати трафік для конкретних користувачів або сервісів (адже для організації він до сих пір залишається дорогим задоволенням).

КомпьютерПресс 2'2008


Але тут виникає резонне питання: як аналізувати проходить трафік і отримувати хоч якусь інформацію про те, хто користується Інтернетом і на які сайти заходить?

Новости