Главная страница 1

Министерство образования Российской Федерации

Государственное образовательное учреждение

высшего профессионального образования

“Хабаровский государственный технический университет”

АДМИНИСТРИРОВАНИЕ В ИНФОРМАЦИОННЫХ СЕТЯХ

Установка и администрирование Proxy-сервера

Методические указания по выполнению лабораторной работы № 3

для студентов специальности 071900

«Информационные системы и технологии»

Хабаровск

Издательство ХГТУ

2004


УДК 681.58:681.32

Администрирование в информационных сетях. Установка и администрирование Proxy-сервера: Методические указания по выполнению лабораторной работы № 3 для студентов специальности 071900 «Информационные системы и технологии» / Сост. Г. К. Конопелько, Д. Г. Конопелько. – Хабаровск: Изд-во Хабар. гос. техн. ун-та, 2004. – 15 с.


Методические указания составлены на кафедре «Автоматика и системотехника». Включают порядок выполнения лабораторной работы, общие сведения, задание на лабораторную работу, требования по оформлению отчета, контрольные вопросы, перечень необходимой для выполнения задания литературы.
Печатается в соответствии с решениями кафедры "Автоматика и системотехника" и методического совета института информационных технологий.

© Хабаровский государственный

технический университет, 2004

Цель работы: настройка и администрирование Proxy-сервера squid под операционной системой Linux.

Лабораторная работа выполняется в локальной сети на рабочей станции с операционной системой Linux 7 или более поздней. В лабораториях кафедры операционная система Linux работает на компьютерах под управлением программного пакета VMware. Этот пакет позволяет создавать так называемые «виртуальные машины» – мнимые компьютеры, не зависящие от выполняющейся в текущее время на данном компьютере операционной системы (ОС). Для запуска ОС Linux необходимо запустить VMware на рабочей станции, выбрать из списка требуемую операционную систему и нажать кнопку «Power ON».



После окончания загрузки для входа в систему необходимо использовать имя пользователя root.

Порядок выполнения лабораторной работы



Подготовка и допуск к работе. К выполнению лабораторной работы допускаются студенты, которые подготовились к работе и имеют не более двух невыполненных предыдущих работ.

Перед работой студент должен:



  • предъявить преподавателю полностью оформленный отчет о предыдущей работе;

  • ответить на вопросы преподавателя.

Студенты, которые не выполнили одно из вышеперечисленных требований, к работе не допускаются.
Отчёт по работе должен содержать:

  • текст задания;

  • перечень всех использованных в лабораторной работе команд и инструкций;

  • вывод по работе.



Установка и администрирование Proxy-сервера
Proxy-сервер, осуществляющий доступ в Internet, предоставляет следующие возможности:

  • централизованный выход в Internet через один сервер в сети;

  • локальное хранение часто просматриваемых документов для увеличения скорости загрузки страниц (один пользователь загрузил документ с удаленного сервера в Internet, а все остальные после этого берут этот документ с Proxy-сервера);

  • регулирование пропускной способности канала в зависимости от его нагрузки;

  • авторизованный доступ в Internet (пользователь может загружать документы из Internet только при наличии логина и пароля).


Установка Proxy-сервера. Прежде чем устанавливать Proxy-сервер squid, надо убедиться в том, что:

  • машина, на которой будет работать Proxy, может соединиться (по WWW, FTP, Telnet – неважно) с другими машинами в сети;

  • машины из внутренней сети могут соединиться с машиной, на которую устанавливается Proxy, опять же неважно каким клиентом;

Если же связь изнутри к Proxy-машине есть и эта Proxy-машина может общаться с внешним миром, можно переходить к настройке squid. Squid надо устанавливать из packages или ports, тогда есть уверенность, что все его компоненты будут размещены по нужным директориям. После установки должно получиться примерно следующее:

  • двоичные файлы должны находиться в каталоге /usr/locl/sbin;

  • в каталоге /usr/local/etc должна появиться директория squid, в которой лежит squid.conf – это его конфигурационный файл, его надо будет редактировать;

  • в каталоге /usr/local/etc/rc.d появился файл squid.sh – это основной стартовый файл (дело в том, что система при старте просматривает этот каталог и все, что найдет там типа *.sh, запустит автоматически). Но можно его запустить и вручную, просто написав ./squid.sh. Если такого файла нет, то при перезагрузке системы squid не будет запускаться;

  • в каталоге /usr/local образовалась директория squid, в которой две поддиректории: cache – там будет его кэш и logs – логи. Там же должен быть файл (возможно, он появится после первого запуска Proxy-сервера) squid.out – это основной лог-файл, в котором и будут сообщения об ошибках, если squid почему-либо не сможет стартовать нормально.

Для начала squid.conf можно редактировать незначительно. Там стоят значения «по умолчанию» и они вполне приемлемы. Единственное, что необходимо сделать – определиться, сколько мегабайт диска следует выделить под кэш. По умолчанию – 100 Мб. Для изменения этого значения найдите в squid.conf строчку

cache_swap 100

и поставьте подходящее значение. Максимальный объем можно оценить исходя из пропускной способности канала Internet за одни сутки.

Скорее всего, понадобится еще одно исправление. Дело в том, что нельзя запускать Proxy-сервер от имени root. Поскольку при старте машины squid.sh будет исполняться от имени root, то надо сделать следующее. Надо найти в конфигурационном файле строчку

cache_effective_user nobody nogroup

и «раскомментировать» ее. Это будет означать, что в процессе работы squid будет иметь права «псевдоюзера» nobody.

На самом деле это не совсем правильно. Правильнее завести нового «псевдоюзера» squid (или еще как-нибудь - www, cache ...) и в конфиг-файле вписать именно его, а не nobody.

После этого надо будет поправить владельца для директории /usr/local/squid. Для этого выполните команду



chown -R nobody /usr/local/squid

Здесь -R означает, что меняется владелец не только директории, но и рекурсивно меняется владелец всего содержимого поддиректорий. Если Вы завели специального «псевдоюзера», то, естественно, в команде вместо nobody укажите его имя. Теперь осталось сформировать «внутреннюю структуру кэша». Кстати, если этого не сделать, то squid при запуске сам подскажет вам: «запустите программу squid –z». Естественно, это надо сделать. Только учтите, что /usr/local/sbin обычно не прописан в PATH даже у root, поэтому лучше набрать полный путь



/usr/local/sbin/squid -z

Теперь можно попытаться запустить squid. Зайдите в /usr/local/etc/rc.d и запустите ./squid.sh. На консоли должно появиться сообщение от squid: "Ready to serve requests" («готов обслуживать запросы»).


Настройка Proxy-сервера. Общая настройка Proxy-сервера чаще всего не вызывает сложностей. Сложности обычно вызывают три обстоятельства: настройка ACL (access control list – список прав доступа) и правил для них, настройка дополнительных программ вроде «баннерорезалок» и настройка ограничений использования канала.

Настройка ACL. Обратимся к соответствующему месту файла squid.conf и прокомментируем его.

ACL прописываются в виде строки acl имя_acl тип_acl параметры ACL или acl имя_acl тип_acl «файл» – при этом в файле сохраняется по одному значению на строку.

Итак, сначала типы списков.

acl aclname src ip-address/netmask – в этом acl описывается ip-адрес или сеть, принадлежащая клиентам squid. Например:

acl vasya src 192.168.1.1/255.255.255.255 – описывает единственную машину с адресом 192.168.1.1 и назначает ей ACL с именем vasya.

acl office src 192.168.1.1/255.255.255.0 – описывает диапазон машин с адресами 192.168.1.1-.254 и назначает этому ACL имя office. Если диапазон необходимо сузить, то необходимо либо изменить маску подсети, либо воспользоваться явным указанием: acl vip_user src 192.168.1.1-192.168.1.5/255.255.255.0. Здесь squid выбирает тот диапазон адресов, который окажется меньше либо по маске, либо по явному указанию.

acl aclname dst ip-address/netmask – этот тип ACL описывает уже сервер, страницы с которого будут запрашивать клиенты. Следует отметить, что в этом типе ACL задается не символьный адрес сервера, а ip.

acl aclname srcdomain.domain.ru – описывает клиентов, но уже не по ip-адресам, а по реверсным DNS. Это значит, что нет разницы, какие ip-адреса принадлежат клиентам, главное, чтобы они определялись dns. Соответственно под это правило попадут все клиенты, стоящие в домене domain.ru.

acl aclname dstdomain .domain.ru – описывает сервер. Сравнивается с запросом из URL. Под этот ACL попадут все серверы третьего уровня домена domain.ru.

acl aclname srcdom_regex [-i] xxx acl aclname dstdom_regex [-i] xxx – описания аналогичны предыдущим, но теперь для выяснения, подходит ли правило под запрос, используются regex-правила. Если символьный адрес не смог определиться из ip-адреса, к запросу будет применена строка none.

acl aclname time [day-abbrevs] [h1:m1-h2:m2] – ACL, описывающий время. Коды дней недели определяются так: S – Sunday – Воскресенье, M – Monday – Понедельник, T – Tuesday – Вторник, W – Wednesday – Среда, H – Thursday – Четверг, F – Friday – Пятница, A – Saturday – Суббота.

Ну а вместо h1:m1 и h2:m2 вставляется время. Запомните – h1:m1 всегда должно быть меньше h2:m2.

Итак, acl worktime time MTWHF 08:00-17:00 описывает рабочее время с понедельника по пятницу, с 8 утра до 5 вечера, acl weekday time SA описывает целиком субботу с воскресеньем, а acl evening time 17:00-23:59 описывает время до полуночи. Если необходимо описать всю ночь, то приходится заводить два ACL: первый – с вечера до полуночи, а второй – с полуночи до утра.

acl aclname url_regex [-i] ^http://regex-правила, применяемые ко всему URL.

acl aclname urlpath_regex [-i] \.gif$ – аналогичные правила, применяемые к URL.

acl aclname port 80 70 21 – ACL, описывающий порты. Вместо простого перечисления можно указать диапазон, например, 1-1024.

acl aclname proto HTTP FTP – ACL, описывающий протокол, по которому клиент желает сделать запрос на сервер.

acl aclname method GET POST – метод, которым передаются данные клиента серверу.

acl aclname browser [-i] regexpregexp-запрос на клиентский браузер. Вычисления основаны на заголовке User-Agent, который пересылает браузер.

acl aclname ident username – ACL описывает имя пользователя, от которого запущена программа на клиентской машине. Имя узнается с помощью ident-сервера.

acl aclname ident_regex [-i] pattern – то же самое, но основанное на regex-правилах.

acl aclname proxy_auth username acl aclname proxy_auth_regex [-i] pattern – ACL, описывающий имя пользователя. Это имя возвращает внешняя авторизующая программа.

acl aclname maxconn number – это правило сработает, если клиент сделает больше number запросов к кешу.

acl req_mime_type mime-type1 – правило, срабатывающее при upload файлов клиентом. Заметьте – uplode, а не скачивание.

Здесь представлены не все описания ACL, но большинство, необходимых в повседневной практике. Для более полного знакомства с описанием следует обратиться к исходному тексту файла squid.conf – там все описано, правда, по-английски.

Итак, создадим правила обычной сети:

acl all src 0.0.0.0/0.0.0.0 acl office src 192.168.1.0/255.255.255.0

all – правило, описывающее все машины, и office – описывающее все машины в подсети 192.168.1.0.

http_access allow office http_access deny all

Эти два правила описывают полный доступ машинам, описываемым acl office, и запрещает доступ машинам, описываемым all. В приведенном примере есть конфликт в описания прав доступа: машины, попадающие под правило all (а по этому правилу все запрещено) не могут использовать Proxy-сервер. Тут в дело вступает порядок просмотра ACL – они просматриваются в порядке объявления, и если сработало одно правило, то другие уже не просматриваются.

К примеру, если мы введем в дополнение ACL acl vasya src 192.168.1.100/255.255.255.255

и расположим правила так:



http_access allow office http_access deny vasya http_access deny all ,

то машина с ip-адресом 192.168.1.100 по-прежнему будет иметь возможность соединяться через Proxy сервер;

а если так:

http_access deny vasya http_access allow office http_access deny all ,

то все будет в порядке. Остальные офисные машины не попадают под действие первого правила.

Если в списке нет ни одного правила, то запрос будет отвергнут. Если ни одно правило не сработало, то за основу берется последнее. Если, к примеру, мы заменим предпоследнее правило на http_access allow all, то нашим Proxy-сервером смогут пользоваться абсолютно все (кроме vasya), кто сможет соединиться с портом squid. Так что будьте внимательнее. Но авторы squid постарались: даже если последнее правило будет разрешающим для всех, то запрос будет отвергнут. Это поможет избежать дыр в Proxy-сервере.

На основе этих же списков-правил так же управляется и доступ к другим возможностям Proxy-сервера (см. файл squid.conf, где все расписано).

Правила – правилами, но, предположим, что в сети появились пользователи, которые честно подключаются к серверу и начинают выкачивать гигабайтами запрещенную информацию. При этом занесение этих сайтов в deny-список вызывает их возмущение.

На этот счет придумали много вещей, но самым эффективным остается сокращение канала для таких пользователей: доступ есть, но качается плохо, возразить им нечего – такая ситуация в Internet не редкость.

Итак, давайте разберемся с «траффик-шейпингом» – именно так это называется. В squid же это называется delay-pool. Заметим, что squid при сборке должен быть собран с опцией --enable-delay-pools.

Итак, сначала разберемся, какие есть пулы. Пулы делятся на три класса. Первый, и самый простой, это когда всему acl ограничивается трафик до определенной величины. Второй – когда отдельно ограничивается трафик для одной машины из подсети и для всей подсети. И третий класс – когда ограничивается трафик для отдельных машин, для подсети класса С или меньше и для подсети класса B.

Итак, давайте обыграем ситуацию, когда в сети завелся «дискокачальщик».

delay_pools 1 – у нас всего один пул.

delay_class 1 1 – первый пул первого класса.

delay_access 1 allow vasya

delay_access 1 deny all

В первый пул попадают только машины, описываемые ACL vasya. Остальные работают, как им положено, ведь им доступ к первому пулу запрещен.



delay_parameters 1 800/64000

Вот и все. Теперь файлы и страницы объемом до 64 Кб будут скачиваться на максимальной скорости, а то, что больше этого – на скорости 800 б/c.

Или совсем уж радикальная мера:

delay_parameters 1 800/800 – и «злобный качальщик» все будет качать на скорости 800 б/c.

Но даже в не очень большой сети будут возникать ситуации, когда все хотят что-то качать, в итоге никому ничего не хватает.

Исправляем строчку с delay_pools на delay_pools 2. Теперь у нас будет два пула.

delay_class 2 2 – второй пул будет второго класса (совпадение номеров чисто случайно) – первый – это vasya.

delay_access 2 allow office

delay_access 2 deny all

Во второй пул попадают только машины с ACL office.



delay_parameters 2 64000/64000 4000/4000

В итоге вся подсеть, описываемая office, будет использовать канал не больше 512 Кбит/с (64 Кб/с), но каждый отдельный хост будет качать не более 4 Кб/c. Этим правилом очень легко разграничить по скорости разные подсети, использующие один канал.

К примеру, у нас есть две подсети, описываемые office и office1. При этом office не должна иметь никаких ограничений на канал (примем канал за 256 Кбит) в целом, но каждый из office не должен качать быстрее 6 Кб/с. А office1 – это пользователи, которым всем и 5 Кб/с хватит.

Создаем два пула второго класса и прописываем для них ACL. Затем определяем этим пулам параметры.



delay_parameters 3 -1/-1 6000/6000 – это определение для office (ему отдан номер пула 3).

delay_parameters 4 5000/5000 -1/1 – а это для office1.

В итоге после применения этих правил получаем все, что заказано – первый офис грузит канал как хочет (-1/-1), но никто из сотрудников больше 6 Кб/c не получает. А второй офис грузит канал не больше 5 Кб/с, но в распределении этих 5 Кб/с между сотрудниками нет никаких правил.

Понятно, что в описание пулов можно заложить и другие параметры, например, время, место доступа и т. д. Остается еще одна маленькая вещь, которую нельзя оставить без внимания. И эта вещь – навязанная реклама через баннеры и другие объекты. Для того, чтобы такую рекламу не пропустить на броузер, каждый URL, который передается squid, первоначально передается редиректору. И тот либо возвращает прежний URL в случае, если все в порядке, либо возвращает тот, который, по его мнению, более правильный. А кто мешает нам перехватывать обращения к баннерам и счетчикам и вместо них подсовывать свою картинку? В итоге страницы можно заполнить прозрачными окошками.

Итак, в squid.conf прописываем строку



redirect_program /squid/bin/redirector

где /squid/bin/redirector – путь до выполняемой программы, которая как раз и обеспечивает разбор URL. Ее можно написать на чем угодно, но наиболее предпочтительным является Perl – этот язык как раз предназначен для подобного рода работ. Полная версия редиректора лежит на http://linuxnews.ru/redirector.



Описание директив squid. Описание директив содержится непосредственно в файле конфигурации squid.conf и в документации, прилагаемой к данной лабораторной работе.

Задание на лабораторную работу
Лабораторная работа выполняется по вариантам.

Вариант

Задание

Подгруппа 1, 5

Сконфигурировать Proxy-сервер на порт 3128; разрешить доступ с ip 10.10.146.150 c 10-00 до 15-00 ч; запретить доступ с ip 10.10.146.176 с 10-00 до 15-00 ч; запретить доступ к доменам *.khb.ru

Подгруппа 2, 6

Сконфигурировать Proxy-сервер на порт 8080; разрешить доступ с ip 10.10.146.176 c 10-00 до 15-00 ч; запретить доступ к файлам *.gif; запретить доступ к домену *.khb.ru c ip 10.10.146.150

Подгруппа 3, 7

Сконфигурировать Proxy-сервер на порт 12345; разрешить доступ с ip 10.10.146.176; запретить доступ к файлам *.cgi; запретить доступ к домену *.khb.ru c ip 10.10.146.150 c 10-00 до 15-00 ч

Подгруппа 4, 8

Сконфигурировать Proxy-сервер на порт 1345; запретить доступ с ip 10.10.146.176; запретить метод POST; запретить доступ к домену *.khstu.ru и к файлам *.gif c ip 10.10.146.150 c 10-00 до 15-00 ч

При защите необходимо знать назначение используемых директив, уметь объяснить информацию, содержащуюся в log-файлах

Для редактирования файлов конфигурации и навигации по файловой системе удобно использовать программу mc. Для ее загрузки необходимо набрать в командной строке

[root@lis] $ mc

Интерфейс программы mc интуитивно понятен и не представляет трудностей при использовании.



Содержание отчета


  1. Содержимое конфигурационных файлов (без комментариев в тексте).

  2. Отрывок из log-файлов, демонстрирующий обращения через прокси-сервер.



Контрольные вопросы


  1. Назначение сервера прокси.

  2. В каком файле содержится информация о конфигурации Proxy-сервера?

  3. Какие протоколы кэшируются прокси?

  4. Какие условия должны быть выполнены перед установкой Proxy-сервера?

  5. Что такое список прав доступа?

  6. Общий синтаксиc ACL.


Библиографический список


  1. Мартин Майкл Дж. Введение в сетевые технологии = Understanding the Network: Практическое руководство по организации сетей / Мартин Майкл Дж. – М.: ЛОРИ, 2002. – 660 с.

  2. Бэндл Дэвид. Защита и безопасность в сетях Linux = Linux security toolkit: Пер. с англ. / Бэндл Дэвид. – СПб.: Питер, 2002. – 480 с. (Для профессионалов. Б-ка Linux).

  3. Мельников Д. А. Информационные процессы в компьютерных сетях: Протоколы, стандарты, интерфейсы, модели... / Мельников Д. А. – М.: КУДИЦ-ОБРАЗ, 1999. – 256 с. (Б-ка профессионала).


АДМИНИСTРИРОВАНИЕ В ИНФОРМАЦИОННЫХ СЕТЯХ

Установка и администрирование Proxy-сервера
Методические указания по выполнению лабораторной работы № 3

для студентов специальности 071900

«Информационные системы и технологии»
Конопелько Геннадий Константинович

Конопелько Денис Геннадьевич

Главный редактор Л. А. Суевалова

Редактор Е. Н. Ярулина

Компьютерная верстка Д. Г. Конопелько


Подписано в печать 28.05.04. Формат 60х84 1/16.

Бумага писчая. Гарнитура «Таймс». Печать офсетная. Усл. печ. л. 0,93.

Тираж 100 экз. Заказ .
Издательство Хабаровского государственного технического университета.

680035, Хабаровск, ул. Тихоокеанская, 136.


Отдел оперативной полиграфии издательства

Хабаровского государственного технического университета.



680035, Хабаровск, ул. Тихоокеанская, 136.



Смотрите также:
Методические указания по выполнению лабораторной работы №3 для студентов специальности 071900 «Информационные системы и технологии»
164.45kb.
1 стр.
Методические указания к выполнению лабораторной работы для студентов дневной формы обучения специальности 230201 «Информационные системы и технологии»
287.23kb.
1 стр.
Методические указания к выполнению лабораторной работы №10 для студентов очной формы обучения всех специальностей
188.73kb.
1 стр.
Методические указания по выполнению и оформлению дипломных проектов (работ) для студентов специальности «Информационные системы»
510.17kb.
3 стр.
Методические указания к выполнению лабораторной работы №12 для студентов очной и заочной форм обучения всех специальностей
221.29kb.
1 стр.
Рабочая программа по курсу «Имитационное моделирование экономических процессов» для специальности 230201(071900) «Информационные системы и технологии»
143.39kb.
1 стр.
Методические указания к выполнению курсового и дипломного проектирований для студентов специальностей
1039.8kb.
6 стр.
Методические указания по выполнению дипломной работы для студентов специальности «Математика и информатика»
292.85kb.
1 стр.
Методические указания по выполнению дипломной работы для студентов специальности 080507 «Менеджмент организации»
1570.68kb.
8 стр.
Методические указания к выполнению курсовой работы для студентов специальности 050509
312.33kb.
1 стр.
Методические указания к выполнению курсовых работ для студентов специальности
129.95kb.
1 стр.
Методические указания по выполнению контрольной работы для студентов специальности 080102. 65 (060600) «Мировая экономика»
169.1kb.
1 стр.