Руководство по настройке ПО на базе операционной системы Dionis NX C 1.2-10 Hand UTM (2015 год)

150

23.9.3

Команды удаления данных

service dns remove cache [view VIEW] [name NAME [all] ]

Удаляет данные для имени NAME из кэша ДНС. Если указан параметр all - будут удалены все

записи, в которых onwer имеет вид *.NAME, т.е. все поддомены домена NAME.

Если имя NAME не задано - удаляет весь кэш.

Если задан вид - удаляет только из этого вида.

service dns remove dynamic-rrs <VIEW> <FZONE> <RZONE> <NAME> <IP> [force]

Удаляет динамическую запись из прямой зоны FZONE и обратной зоны RZONE вида VIEW.

Запись определяется доменным именем NAME (полным или относительным) и IP-адресом IP.

Если зона статическая - запись удалена не будет, только если не будет указан параметр force.

В этом случае запись, если она будет найдена, будет удалена.

151

24. Служба DHCP

Система имеет службу DHCP, реализующую серверную часть протокола DHCP (Dynamic Host

Configuration Protocol — протокол динамической конфигурации узла).

Протокол DHCP - это сетевой протокол прикладного уровня модели OSI, позволяющий ком-

пьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети

TCP/IP. Данный протокол работает по модели «клиент-сервер». Для автоматической конфигура-

ции клиент на этапе конфигурации сетевого устройства обращается к серверу DHCP и получает

от него нужные параметры.

Основная концепция службы DHCP напоминает концепцию службы DNS - это иерархичность,

вложенность и наследуемость конфигурационных пространств.

Иерархия следующая:

• service dhcp - служба DHCP (уровень А)

• subnet/host - подсеть/хост (уровень Б)

Самый верхний уровень конфигурации службы - это команды уровня service dhcp.

Многие из этих команд есть также на нижележащем уровне Б - в описании подсети или хоста.

Если на верхнем уровне (А) задана некоторая опция, то она определяется и для нижележа-

щего уровня (Б). Далее можно изменить на значение данной опции на уровне Б и оно уже будет

отличаться от все остальных.

Замечание по формату описания параметров: запись {<NAME>,3} - означает список максимум

из трех параметров типа NAME

Чтобы настроить службу DHCP, следует войти в режим ее конфигурации:

service dhcp

Команда осуществляет вход в конфигурацию DHCP-службы.

24.1

Общие настройки службы

listen <ethernet | bond> <N>

Слушать запросы DHCP на Ethernet/Bond интерфейсе N.

Для задания нескольких интерфейсов нужно использовать данную команду для каждого ин-

терфейса.

По умолчанию: слушать на всех широковещательных Ethernet-интерфейсах.

local-port <N>

Порт, на котором слушать DHCP-запросы.

По умолчанию: 67

local-address <IP>

152

IP-адрес, на котором слушать нешироковещательные DHCP-запросы на порт 67 (если иное не

укaзано командой local-port).

Широковещательные запросы приниматься не будут.

Эта команда может быть полезна,если в связке со службой DHCP используется (на другом

узле) служба DHCP-RELAY.

max-lease-time <N>

Максимальный срок аренды адреса (сек.).

Клиент в запросе может прислать желаемое максимальное значение срока аренды адреса.

Опцию можно указывать глобально, в настройках хоста и подсети.

При указании данной опции, клиент не может получить аренду адреса на большее время, чем

указано в данной опции.

По умолчанию: 86400

min-lease-time <N>

Минимальный срок аренды адреса (сек.).

Клиент в запросе может прислать желаемое минимальное значение срока аренды адреса.

Опцию можно указывать глобально, в настройках хоста и подсети.

При указании данной опции, клиент не может получить аренду адреса на меньшее время, чем

указано в данной опции.

По умолчанию: 300

default-lease-time <N>

срок аренды адреса по умолчанию.

Опцию можно указывать глобально, в настройках хоста и подсети.

Этот срок аренды адреса назначается клиенту, если он не прислал в запросе желаемое мак-

симальное значение.

По умолчанию: 43200

respond-delay <N>

Задает число секунд (от 0 до 255) , в течение которых служба будет ждать,прежде чем отве-

тить на запрос клиента.

Эта опция позволяет сделать службу DHCP дублирующей/запасной для основного DHCP-

сервера на другом компьютере. Когда основной DHCP-сервер не отозвался, дублирующая служба

DHCP будет отзываться после определенного количества запросов клиента, указанного парамет-

ром N как продолжительность ожидания перед ответом клиенту. Она может понадобиться для ор-

ганизации дублирующего DHCP-сервера на основе данной службы: если основной сервер DHCP

не ответил в течении указанного числа секунд, то клиенту ответит дублирующая служба DHCP

По умолчанию: 0

send-hostname <on|off>

Это команда нужна, если в сети есть BOOTP-клиенты (бездисковые рабочие станции), которым

необходимо помимо фиксированного адреса присваивать имя хоста.

153

Включить (on) или отключить (off).

Если опция включена, то для каждого объявления хоста, находящегося в зоне действия опции,

имя , использованное в объявлении host (см. ниже подраздел “Настройка статического назначе-

ния”) передается клиенту в качестве его имени.

Опцию можно указывать глобально и в настройках хоста.

По умолчанию: отключено.

ddns-ttl <N>

Устанавливает умалчиваемое значение для TTL-динамических записей. Может понадобиться,

если будут использоваться динамические DNS-обновления.

По умолчанию: определяется клиентом.

24.2

Настройка статического назначения

Обычно фиксированные адреса назначаются важным хостам сети,например серверам.

Рабочим станциям обычно назначают адрес динамически(см. подраздел “Настройка динами-

ческого назначения”).

host <NAME>

Вход в режим статического назначения IP-адреса для клиентов.

NAME - имя, идентифицирующее хост; используется только при включённой опции send-

hostname: в этом случае оно передается клиенту в качестве его имени.

Переопределяется опцией host-name.

Имя хоста несущественно,если не включена(см.выше) опция send-hostname.

Следует также настроить признаки, по которым служба будет определять, принадлежит ли

входящий DHCP-запрос данной host-конфигурации.

mac <MAC>

MAC - МАС-адрес клиента.

Наиболее часто используется привязка хост-декларации к MAC-адресу клиента.

client-id <NAME>

Помимо привязки к МАС-адресу, можно выполнить привязку хост-декларации к идентификато-

ру клиента, который может передаваться в запросе (это т.н. dhcp-client-identifier DHCP-запроса).

NAME - идентификатор клиента.

В результате для поиска host-декларации, соответствующей клиенту,приславшему запрос,

происходит следующее:

• сначала ищется client-id, совпадающий с dhcp-client-identifier, который прислан клиентом;

• если нужный client-id не находится, то ищется совпадение MAC-адреса в команде mac МАС-

адресу клиента.

154

ip <IP>

Задает статический IP-адрес клиента.

24.3

Настройка динамического назначения

Для настройки динамического назначения адресов необходимо описать все се-

ти,обслуживаемые интерфейсами системы, которые будут обслуживать DHCP-запросы.

У этих интерфейсов должны быть назначены IP-адреса с нужным масками сети.

subnet <IP/MASK>

Вход в режим config-service-dhcp-subnet-IP/MASK: динамическое назначение IP-адресов для

клиентов.

range <IP_START> [IP_END]

Задает диапазон в сети SUBNET, адреса в пределах которого могут быть наначены клиентам.

Все IP-адреса в диапазоне должны принадлежать той подсети, к описанию которой относится

секция range.

Если IP_END не указан, то диапазон состоит из одного адреса.

Пример:

(config−service−dhcp−subnet−192.168.1.0/24)# range 192.168.1.10 192.168.1.210

Этой командой мы предписываем службе назначать клиентам IP-адреса из указанного диапа-

зона (всего 201 адрес).

24.4

Сетевые DHCP-опции

Помимо назначения клиентам IP-адресов, служба может передавать им другую конфигураци-

онную сетевую информацию.

Эта информация называется сетевые DHCP-опции. Они могут быть указаны на любом из уров-

ней службы: как глобально, так и в хост- или сетевой декларациях.

broadcast-address <IP>

Адрес для широковещательных запросов.

domain-name <NAME>

Имя домена для разрешения имен через DNS.

search <NAME>

Имя домена для разрешения имен через DNS.

Можно указать несколько доменов.

gateway <IP>

155

Адрес шлюза. Можно задавать несколько шлюзов.

subnet-mask <IP>

Маска подсети.

Если не указана, значение маски берется из описания subnet, в которую попадает запрос.

[N] name-server <IP>

IP-адрес сервера имен с приоритетом N.

[N] ntp-server <IP>

IP-адрес сервера времени с приоритетом N.

[N] wins-server <IP>

IP-адрес WINS (NetBios) сервера с приоритетом N.

[N] smtp-server <IP>

IP-адрес сервера SMTP сервера с приоритетом N.

24.5

Пользовательские DHCP-опции

Существует возможность создать пользовательские DHCP-опции, которые будут передаваться

указанным клиентам так же, как и стандартные DHCP-опции.

Перед использованием пользовательской опции ее необходимо определить.

user-option-def <NAME> <CODE> <TYPE>

Данная команда определяет новую опцию с именем NAME, имеющую код CODE (от 128 до 254)

и тип TYPE.

Код опции CODE принимает значения из инетрвала 128-254, т.к. все коды меньше 128 заре-

зервированы под стандартные DHCP-опции. На самом деле интервал от 128 до 224 так же заре-

зервирован под стандартные DHCP-опции, однако это произошло гораздо позже опубликования

стандарта DHCP-протокола в соответствующем документе RFC и не все клиенты могу поддержи-

вать данный стандарт и вполне могут использовать интервал 128-224 как пользовательский ин-

тервал опций. Поэтому, если это возможно, рекомендуется использовать интервал кодов 224-254.

Интервал 128-224 оставлен для совместимости.

Тип TYPE определяет тип значений опции и может быть следующим:

• bool - задает булевый тип значения опции: on,off

• string - задает строковый тип значения опции: любая текстовая строка

• bytes - задает бинарный тип значения опции: последовательность байт длиной до 128, бай-

ты разделены символом »:».

• uint32 - задает целочисленный тип значения опции: любое 32-битное число

• ip - задает тип значения опции в виде IP-адреса.

user-option <NAME> <VAL>

Задает значение VAL ранее определенной опции NAME. Определение опции делается коман-

дой user-option-def.

156

24.6

Работа со службой

24.6.1

Запуск и остановка службы

Команды выполняются в режиме config-service-dhcp.

enable

Включить DHCP-сервис.

disable

Выключить DHCP-сервис.

24.6.2

Команды просмотра данных

show service dhcp log [all | N ] [archive N] [follow]

Показывает журнал сервиса.

Параметры:

• N - число записей

• all - показать все записи

• follow - просмотр журналов по мере появления

• archive - просмотр старых журналов

По умолчанию: show service dhcp log 25

show service dhcp status

Показывает текущий статус службы DHCP (корректность внутренней конфигурации, коррект-

ность базы данных зон, состояние сервиса).

show service dhcp lease [ all | active | free | IP ]

Показывает данные по выданным адресам: всем, действующим, свободным или по указанно-

му.

Формат выходных данных:

HOST:<HOST> (<STATUS>)

IP:<IP> MAC:<MAC> <DATE_S>−<DATE_E>

Значения полей:

HOST - имя хоста клиента,присланное им в DHCP-запросе(может отсутствовать, т.к. протокол

DHCP не требует передавать его)

STATUS - статус адресной информации (free - свободная, active - занятая)

IP - арендованный IP-адрес

157

MAC - MAC-адрес клиента

DATE_S - время начала срока аренды адреса (формат YYYY/MM/DD/HH:MM:SS)

DATE_E - время конца срока аренды адреса (формат YYYY/MM/DD/HH:MM:SS)

По умолчанию: show service dhcp lease all.

24.6.3

Команды удаления данных

service dhcp remove lease [ IP | DOMAIN ]

Прекратить аренду адреса по указанному IP-адресу узла или его имени DOMAIN.

Если ничего не указано - прекращается аренда всех адресов.

24.7

Примеры

Рассмотрим пример:

• пусть в DHCP описано несколько сетей и хостов, и среди них имеется сеть 1.2.3.0/24 и хост

zeta.

• если необходимо для хоста с МАС-адресом 22:22:22:33:33:33 назначить север имен 2.2.2.2,

для подсети 1.2.3.0/24 назначить сервер имен 3.3.3.3, а для всех остальных - сервер имен

5.5.5.5, следует выполнить следующие команды:

(config−service−dhcp)# name−server 5.5.5.5

(config−service−dhcp)# host zeta

(config−service−dhcp−host−zeta)# mac 22:22:22:33:33:33

(config−service−dhcp−host−zeta)# name−server 2.2.2.2

(config−service−dhcp−host−zeta)# subnet 1.2.3.0/24

(config−service−dhcp−subnet−1.2.3.0/24)# name−server 3.3.3.3

159

25. Служба DCHP-RELAY

Система имеет службу DCHP-RELAY, которая является ретранслятором DHCP- сообщений на

указанные сервера.

Для запуска службы необходимо:

• указать хотя бы один IP-адрес сервера, на который будут перенаправляться DHCP-запросы,

командой server;

• указать интерфейс для взаимодействия с DHCP-серверами командой listen-server.

Для настройки службы следует войти в ее конфигурацию:

service dhcprelay

Осуществляет вход в режим конфигурации службы DHCPRELAY.

25.1

Основные настройки

listen-server <IP>

Задает интерфейс, с которого будут перенаправляться DHCP-запросы на сервера DHCP. Кроме

того,этот интерфейс будет действовать так же, как и интерфейсы указанные командой listen, т.е.

будет принимать DHCP-запросы/ответы как от клиентов, так и от серверов. Поэтому, если реально

присутствует всего один интерфейс, достаточно указать его только командой listen-server.

listen <IFACE>

Задать интерфейс, на котором следует ожидать запросы/ответы DHCP.

По умолчанию: все широковещательные интерфейсы.

enable

Включить службу

disable

Выключить службу

25.2

Дополнительные настройки

send-relay-options

Служба будет добавлять к DHCP-запросу свой идентификатор, который состоит из Circuit ID

(имя аппаратного порта получения запроса) и Remote ID (MAC-адрес интерфейса получения за-

проса); это т.н. DHCP Опция 82 — опция протокола DHCP, использующаяся для того чтобы про-

информировать DHCP-сервер о том, от какого DHCP-ретранслятора и через какой его порт был

получен запрос; применяется при решении задачи привязки IP-адреса к порту коммутатора и для

защиты от атак с использованием протокола DHCP.

160

drop-alien-replies

Отбрасывать ответы DHCP-серверов, если они содержат чужую Опцию 82 (идентификаторы в

ней не соответствует идентификаторам службы)

local-port <PORT>

Порт, на котором слушать DHCP-запросы

По умолчанию: 67.

max-packet-size <SZ>

Максимальный размер DHCP-пакета (вместе с Опцией 82).

По умолчанию: 576 байт.

mode <append|replace|forward|discard>

Указывает, что делать с входящими DHCP-пакетами, которые уже имеют внутри себя Опцию

82, т.е. пришли от других релэй-агентов.

Возможные варианты:

• append : добавить свои идентификаторы к Опции 82

• replace : заменить своими идентификаторами уже имеющиеся в Опции 82 (по умолчанию)

• forward : ничего не менять

• discard : отбросить

25.3

Пример

Приведем настройку для следующей сети:

КЛИЕНТ(ethernet0)<—>DhcpRelay(ethernet1(192.168.0.1)-ethernet2(10.0.0.1))<—

>DhcpServer(ethernet3(10.0.0.2))

Интерфейсы ethernet0,ethernet1 - обслуживают клиентскую сеть 192.168.0.0/24.

Интерфейсы ethernet2,ethernet3 - обслуживают сеть сервера 10.0.0.0/24.

Минимальная конфигурация Dhcp Relay:

(config−service−dhcprelay)# listen ethernet 1

(config−service−dhcprelay)# listen−server ethernet 2

(config−service−dhcprelay)# server 10.0.0.2

(config−service−dhcprelay)# enable

Минимальная конфигурация Dhcp Server:

(config−service−dhcp)# local−address 10.0.0.2

(config−service−dhcp−subnet−192.168.0.0/24)# range 192.168.0.10 192.168.0.100

(config−service−dhcp)# enable

161

26. Служба PROXY

Система имеет

службу PROXY, которая является прокси-сервером для протоколов FTP и HTTP.

Прокси-сервер - это служба, позволяющая клиентам выполнять косвенные запросы к другим

сетевым службам.

Далее под службой будем понимать описываемую прокси-службу

, под УС будем

понимать удаленный сервер, ресурс которого желает получить клиент через прокси-службу.

Рассмотрим алгоритм обработки HTTP-запроса клиента через PROXY-службу при задействова-

нии всех ее возможностей:

1. клиент пытается получить ресурс, расположенный, например, на удалённом HTTP-сервере

(web-страница, картинки, аудио-, видео-файлы и др.);

2. клиент подключается к службе или запрос клиента перенаправляется маршрутизатором на

службу;

3. служба аутентифицирует пользователя, анализирует запрос клиента и проверяет,разрешен

ли данный запрос для данного клиента;

4. если запрос разрешён, могут быть сделаны модификации заголовков HTTP-запроса клиен-

та;

5. далее служба ищет запрашиваемый ресурс в своем кэше;

6. если ресурс найден в кэше, делается проверка на свежесть ресурса;

7. если ресурс свеж, он возвращается клиенту;

8. если ресурс стар или не найден в кэше, то служба пытается получить его с удаленного

HTTP-сервера, возможно на ограниченной скорости;

9. если ресурс получен с удаленного сервера, то служба проверяет, разрешен ли данный

ресурс для возврата клиенту;

10. если ресурс разрешен, то служба проверяет, нужно ли его кэшировать;

11. перед возвратом ресурса его HTTP-заголовок также может быть изменен;

12. наконец ресурс возвращается клиенту.

В дальнейшем в разделах данной главы будет указано, к какому пункту данного алгоритма

относится раздел.

Таким образом, основные цели службы:

• кэширование данных: может держать копию часто запрашиваемых Интернет-ресурсов в

своем кэше и выдавать по запросу, снижая тем самым нагрузку на Интернет-канал и ускоряя

получение клиентом запрошенной информации;

• защита локальной сети от внешнего доступа: локальные узлы взаимодействуют с внешними

ресурсами только через службу, а внешние узлы не могут обращаться к локальным;

• ограничение доступа из локальной сети к внешней:

- на удаленные ресурсы определённого типа;

- для определённых клиентов;

- на объем трафика извне в сторону определённых клиентов и/или сетей.

162

26.1

Общие понятия

26.1.1

Режимы работы службы

Существуют два режима работы службы:

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

проксирование/кэширование HTTP,FTP протоколов

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

правил; поддерживает проксирование/кэширование только HTTP протокола; успешность

выполнения запроса полностью зависит от наличия заголовка Host в HTTP-запросе клиента.

Более подробно настройка службы в обоих режимах описана далее в подразделе “Общие

настройки службы”.

26.1.2

Правила и списки доступа

Основные понятия службы - списки контроля доступа(ACL) и правила доступа. ACL - это име-

нованный набор элементов определённого типа.

Формат ACL следующий: acl <NAME> <TYPE> <PARAMS>

Рассмотрим поля команды:

• NAME - это имя ACL;

• TYPE - это тип ACL; определяет тип элементов данного списка ACL; может принимать мно-

жество значений, рассмотренных ниже;

• PARAMS - это элементы, входящие в данный список.

Рассмотрм возможные типы ACL:

• src - IP-адреса источника (медленный тип);

• dst - IP-адреса назначения (медленный тип);

• myip - IP-адреса локальных интерфейсов системы;

• srcdomain - доменное имя источника;

• dstdomain - доменное имя назначения;

• srcdom-regex - регулярное выражение для доменного имени источника;

• dstdom-regex - регулярное выражение для доменного имени назначения;

• random - случайная частота события (задается дробным числом типа 1/N);

• time - дата и или время события;

• port - порт назначения;

• myport - локальный порт системы;

• proto - протокол HTTP или FTP;

163

• method - метод HTTP;

• user-agent - приложение клиента (UserAgent);

• proxy-auth - имя пользователя;

• proxy-auth-all - все пользователи;

• proxy-auth-regex - регулярное выражение для имени пользователя;

• maxconn - максисмальное число прямых TCP-соединений (X-Forwarded-For не учитывают-

ся);

• max-user-ip - максимальное число попыток аутентификации с разных IP-адресов для одного

и того же пользователя;

• req-mime - MIME-тип запроса клиента;

• rep-mime - MIME-тип ответа пользователя;

• mac - MAC-адрес для клиентов из той же подсети;

• uri - регулярное выржание для URI;

• urn - регулярное выржание для URN.

Под источником и назначением обычно в службе прокси понимается клиент и сервер.

На примерах рассмотрим, как создавать ACL:

(config−service−proxy)# acl a1 src 10.0.0.0/24 10.0.1.0/24

(config−service−proxy)# acl a1 src 10.0.2.0/24

(config−service−proxy)# acl a2 src 10.0.3.0/24

(config−service−proxy)# acl u1 uri xxx

В результате: ACL a1 будет состоять из 3х сетей 10.0.0.0/24 10.0.1.0/24 10.0.2.0/24; ACL а2

будет состоять из сети 10.0.3.0/24; ACL u1 будет состоять из всех запросов, в URI которых есть

слово xxx.

При поиске службой того ACL, в пределы которого попадает запрос клиента или ответ сервера,

используется OR-логика: если запросу соответствует хотя бы один из элементов, перечисленных

в данном ACL, то считается, что запрос попал в данный ACL, и поиск прекращается. Поэтому,

для оптимизации работы службы, при определении параметров ACL лучше задавать первым тот

параметр ACL, вероятность попадания в который максимальная.

Рассмотрим пример создания правил доступа на основе ранее созданных ACL:

(config−service−proxy)# http−access deny a1 u1

(config−service−proxy)# http−access permit a2

(config−service−proxy)# http−access deny all

При поиске службой правила, в который попадает запрос клиента или ответ сервера, исполь-

зуется AND-логика: запрос/ответ должен удовлетворять всем ACL, перечисленным в правиле. По-

этому, для оптимизации работы службы, при определении правил на основе ACL лучше задавать

первым тот параметр правила, вероятность попадания в который минимальная.

В данном примере доступ запрещается для запросов, приходящих из сетей a1, только если

они пытаются получить ресурс, в URI которого есть слово xxx. Для сетей из a2 разрешается

свободный доступ. Для всех остальных сетей доступ запрещён (используется встроенный ACL с

именем all).

Помимо правил доступа, существуют и другие команды, использующие ACL. Например: Рас-

смотрим пример создания правил доступа на основе ACL:

164

(config−service−proxy)# max−reply−size a1

Наконец, добавим еще одно правило по оптимизации работы службы: правила на основе ACL

типа srcdomain, dst, proxy-auth лучше определять как можно раньше в списке.

Важное замечание: для правила доступа любого типа рекомендуется всегда добавлять в

конец списка правил данного типа запрещающее или разрешающее (зависит от контекста) пра-

вило,направленное на всех (например, http-access deny all).

26.1.3

Регулярные выражения

В некоторых командах службы параметры задаются упрощёнными регулярными выражениями

(РВ). Тип параметра в этом случае называется REGEX.

РВ - это формальный язык поиска подстрок в тексте, основанный на использовании метасим-

волов.

По сути РВ - это строка-образец, состоящая из символов (С) и метасимволов (МС) и задающая

правило поиска.

МС - это С, который используется для замены других С или их последовательностей, приводя

таким образом к символьным шаблонам.

В дальнейшем в этом разделе все символы,указанные в кавычках, должны вводиться в систе-

ме без кавычек.

Кратко опишем используемые МС:

• «?» - С перед данным МС может быть, а может и отсутствовать; например: «ax?» - это «ax»

или «a»;

• «*» - количество С перед данным МС больше либо равно 0; например: «ax*» - это «a»,

«ax», «axx», «axxx» и т.д.;

• «+» - количество С перед данным МС больше либо равно 1; например: «ax+» - это «ax»,

«axx», «axxx» и т.д.;

• «» - задает наборы символов; например: [a-z123=] - это все строчные англ.буквы, цифры

1,2,3 и знак равно;

• «.» - любой символ; например: .* - это любое множество,в том числе пустое, любых симво-

лов;

• «{}» - задает число повторений предыдущего символа; например: [a-z]{1,3} - любые одно-

, двух- и трехбуквенные слова;

• «ˆ» - задает начало строки; например: ˆ123[ab]? - это все строки, начинающиеся на 123,

123a или 123b;

• «$» - задает конец строки; например: [0-9]{2}$ - это все строки, оканчивающиеся на двух-

значные числа.

• «()» - задает группу символов; например: a([0-9]b){2} - это a1b4b, a5b2b и т.д., т.е. МС

{2} применяется к группе ([0-9]b).

Существует возможность использовать МС как С, т.е. МС будет иметь только функцию символа,

т.е. отображать сам себя. Это называется экранирование МС.

165

Символ экранирования (CЭ) - «\\».

При установке параметра типа REGEX,если в значении параметра используется СЭ, необходи-

мо взять все значение параметра в двойные кавычки,например:

(config−service−proxy)# acl a1 urn ”\\.cgi$”

При удалении параметра типа REGEX,если в значении параметра используется СЭ, необходи-

мо взять все значение параметра в двойные кавычки и продублировать СЭ,например:

(config−service−proxy)# no acl a1 urn ”\\\\.cgi$”

26.2

Общая настройка службы

Часть информации о настройке в данном разделе,а именно настройка режимов работы службы,

относится п.2 Алгоритма.

Чтобы войти в режим настройки службы, следует выполнить команду:

(config)# service proxy

Необходимо также задать почтовый адрес администратора службы, которая будет указана в

веб-страницах, описывающих проблему с выполнением запроса клиента, чтобы он мог ,в случае

необходимости, узнать причину данной проблемы:

(config−service−proxy)# admin−email ivanov@company.ru

По умолчанию используется адрес admin@company.

Важно: система должна быть способна разрешать имена узлов через DNS. Для этого либо

настройте и включите службу DNS и/или укажите в ip resolver адрес(а) серверов имен.

26.2.1

Настройка службы в обычном режиме.

Следует настроить порт и адрес(необязательно), на которых служба будет ожидать входящие

запросы:

(config−service−proxy)# listen 3128 192.168.0.1

Данная команда настраивает службу в обычном режиме, т.е. клиентам необходимо будет ука-

зать в настройках своих Интернет-браузеров адрес и порт службы.

26.2.2

Настройка службы в прозрачном режиме.

Обычный режим может быть не очень удобным, т.к. необходимо настраивать браузеры клиен-

тов.

166

Поэтому можно настроить службу в режиме intercept (режим перехвата или прозрачный

режим). Рассмотрим пример настройки службы в прозрачном режиме, обслуживающую запро-

сы, приходящие из сети 192.168.1.0/24 на 80-й порт(HTTP) на интерфейс ethernet2 с адресом

192.168.1.254:

(config)# ip nat−list proxy

(config−nat−proxy)# exclude in tcp dport 80 dst 192.168.1.254

(config−nat−proxy)# nat tcp dport 80 src 192.168.1.0/24 redirect port 3127

(config)#

(config)# ip access−list dropmyself

(config−acl−dropmyself)# deny tcp dport 3127 dst 192.168.1.254

(config)#

(config)# interface ethernet 2

(config−if−ethernet2)# ip nat−group proxy

(config−if−ethernet2)# ip access−group dropmyself in

(config)#

(config−service−proxy)# listen 3127 192.168.1.254 intercept

В данном режиме службы клиентам не нужно ничего настраивать, они автоматически, после

запуска службы, будут работать через нее. В данном примере предполагалось, что клиенты об-

служиваются маршрутизатором

, на котором и настраивается прокси-служба.

Рассмотрим вышеприведенные команды:

• правило proxy перенаправляет трафик на 80-й порт с адресов сети 192.168.1.0/24 на порт

3127, исключая при этом запросы на 80й порт локальной WEB-службы;

• правило dropmyself отбрасывает весь трафик,приходящий на адрес и порт прокси сервера,

объявленные ниже как intercept: это нужно для предотвращения обработки запросов непо-

средственно на прерывающий сокет службы, т.е. на 192.168.1.254:3127, т.к. это может

вызвать петлю перенаправления запросов, когда служба будет бесконечно слать запрос

самой себе, думая что она и есть удалённый сервер;

• ip nat-group proxy и ip access-group dropmyself in применяют вышописанные правила на

интерфейсе; вместо ip nat-group нужно использовать ip nat-group-xfrm, если трафик че-

рез интерфейс предполагается заворачивать в какой-либо туннель,например DISEC: в этом

случае NAT выполняется до «заворачивания» в туннель для отсылаемого через интерфейс

трафика и после «разворачивания» из туннеля для принимаемого интерфейсом трафика;

• команда listen непосредственно определяет сокет (адрес и порт) для принятия HTTP-

запросов и объявляет его прерывающим сокетом; пары 0.0.0.0:3128 и 127.0.0.1:3128 за-

прещаны.

Важно: в команде listen для режима intercept можно указать опцию no-pmtu-discovery, если

у некоторых клиентов иногда возникают проблемы с долгим ожиданием обработки HTTP-запроса.

Это может быть связано проблемой доставки ICMP Must fragment сообщения:

(config−service−proxy)# listen 3127 192.168.1.254 intercept no−pmtu−discovery

Вы можете указать неограниченное количество сокетов обоих типов, на которых будут при-

ниматься запросы. Единственное ограничение: один и тот же сокет может быть только одного

типа.

167

26.3

Настройка параметров кэширования.

Далее настроим параметры службы, описывающие кэш.

Настройка типа кэша на диске:

(config−service−proxy)# cache type aufs

Другой тип кэша, который может быть использован в данной команде, это ufs. Отличие ufs

от aufs в том, что первый обеспечивает синхронные файловые операции над кэшем, а второй -

асинхронные, что более эффективно. Рекомендуется всегда использовать aufs.

Настройка механизма замены объектов в кэше на диске и в памяти:

(config−service−proxy)# cache replacement−policy disk hlru

(config−service−proxy)# cache replacement−policy memory hlru

Рекомендуется использовать один и тот же механизм для кэша в памяти и кэша на диске.

Опишем возможные механизмы замены объектов:

• lru : Least Recently Used (сначала заменяются самые старые объекты, к которым давно не

было доступа);

• hlru : Heap-based Last Recently Used (аналогично предыдущему,но в новой, более эффек-

тивной реализации);

• gdsf : Greedly Dual Size Frequency (в кэше остаются прежде всего популярные маленькие

объекты);

• lfuda : Least Frequently Used with Dinamic Aging (в кэше остаются прежде всего популярные

объекты,вне зависимости от размера).

Настройка размера кэша на диске(первая команда) и в памяти(вторая команда):

(config−service−proxy)# cache disk−size 10000

(config−service−proxy)# cache memory−size 64

Размер задается в Мб.

Настройка размеров кэшируемых объектов на диске(первые две команды) и в памяти(третья

команда):

(config−service−proxy)# cache limit disk max 500

(config−service−proxy)# cache limit disk min 5

(config−service−proxy)# cache limit memory max 8

Размер задается в Кб. Объекты,размер которых выходит за указанные рамки, не будут кэши-

роваться. Минимальное ограничение для объектов в памяти равно 0 и не может быть изменено.

26.4

Настройка доступа к службе

Данный раздел относится к пп.3 и 9 Алгоритма.

168

С помощью этих настроек осуществляется контроль над тем, какие узлы могут иметь доступ

к сети Интернет и какие данные они могут запрашивать через прокси-службу.

Для начала напомним, как формируется URI (Унифицированный идентификатор ресурса):

URI=URL|URN, где | - конкатенация.

Напрмер, URI = ftp://ftp.dlink.ru/pub/ADSL/ , где: URL = ftp://ftp.dlink.ru , URN =

/pub/ADSL/

Далее рассмотрим примеры.

Запрет доступа к нежелательным сайтам и фильтрация ответов сервра:

(config−service−proxy)# acl workers src 10.0.0.0/24

(config−service−proxy)# acl bosses src 10.0.1.0/24

(config−service−proxy)# acl mime1 rep−mime ^audio

(config−service−proxy)# acl blacklist uri ^http://jihad

(config−service−proxy)# acl blacklist uri kommunist

(config−service−proxy)# acl blacklist urn ^/cgi−bin

(config−service−proxy)# acl blacklist uri

^http://bad\\.site\\.number[0−9]+\\.sym−.\\.tail−*\\.ru$

(config−service−proxy)# acl docsite uri ^http://documentation

(config−service−proxy)# http−access deny blacklist workers

(config−service−proxy)# http−access deny docsite bosses

(config−service−proxy)# http−access permit all

(config−service−proxy)# http−reply−access deny mime1

Данные правила запрещают работникам (сеть workers) посещать следующие сайты:

• сайты, начинающиеся на http://jihad;

• сайты, в URI которых есть слово kommunist;

• сайты, в URN которых есть /cgi-bin, т.е. запрет доступа к CGI-приложениям серверов;

• сайты, имеющие вид http://bad.site.number$A.sym-$B.tail-$C.ru, где:

- $A -это набор цифр от 0 до 9;

- $B - любой символ;

- $C - любой набор символов, том числе и пустой.

Кроме того, данные правила запрещают директорам (сеть bosses) посещать сайты, начинаю-

щийся на http://documentation.

Другим лицам (которые не входят в категории bosses и workers) доступ на любые сайты раз-

решен.

Если доступ разрешен, то используется последнее правило (http-reply-access): после получе-

ния ответа от сервера анализируется тип содержимого ответа (поле Content-Type HTTP-заголовка

ответа) и если типа содержимого начинается с audio, то содержимое клиенту не возвращается и

не кэшируется.

26.5

Настройка фильтрации HTTP-заголовков

Данный раздел относится к п.4 и 11 Алгоритма.

169

Служба имеет возможность удалять HTTP-загловки и изменять их значения в запросах клиен-

тов и/или ответах сервера.

По умолчанию никакие заголовки не удаляются.

Для исключения заголовка из HTTP-пакета запроса и ответа используются следующие коман-

ды: request-header-access deny и reply-header-access deny соответственно.

Для включения заголовка в HTTP-пакета запроса и ответа используются следующие команды:

request-header-access permit и reply-header-access permit соответственно.

Для замены содержимого в ранее исключенных HTTP-заголовках запроса и ответа использу-

ются следующие команды: request-header-replace и reply-header-replace соответственно.

Следует обратить внимание, что замена содержимого работает только для заголовков, кото-

рые попадают в request/reply-header-access deny правила.

Рассмотрим пример. Скрытие от удаленных серверов названия приложения, с помощью кото-

рого клиенты локальной сети работают в сети Интернет:

(config−service−proxy)# acl lan src 10.0.0.0/24

(config−service−proxy)# request−header−access deny User−Agent lan

(config−service−proxy)# request−header−access permit All lan

(config−service−proxy)# request−header−replace User−Agent ”Fake Browser 1.0”

Данные команды заменяют информацию в заголовке User-Agent во всех исходящих из сети

10.0.0.0/24 HTTP-пакетах на Fake Browser 1.0.

Аналогично можно менять заголовки в ответах HTTP-серверов командами reply-header-

access/reply-header-replace.

26.6

Настройка выборочного кэширования

Данный раздел относится к п.10 Алгоритма.

Служба имеет возможность предписывать, какие объекты и для каких пользователей следует

кэшировать, а какие нет.

Рассмотрим примеры. Запретим кэширование объектов, расположенных в локальной сети:

(config−service−proxy)# acl lan dst 10.0.0.0−10.0.3.0/24

(config−service−proxy)# caching deny lan

(config−service−proxy)# caching permit all

Обычнно не следует кэшировать объекты, находящиеся на HTTP-серверах локальной сети,

т.к. доступ к ним и так достаточно быстрый. Это сохранит место в кэше для других объектов.

В данном примере все HTTP-запросы на адреса из четырех сетей (10.0.0.0/24 - 10.0.3.0/24) не

будут кэшироваться.

Другой пример. Запретим в LAN кэширование всего, кроме аудиоинформации:

(config−service−proxy)# acl lan dst 10.0.0.0−10.0.3.0/24

(config−service−proxy)# acl aud req−mime ^audio

(config−service−proxy)# caching deny lan !aud

(config−service−proxy)# caching permit all

170

26.7

Настройка аутентификации

Данный раздел относится к п.3 Алгоритма.

Служба имеет возможность проводить аутентифиуацию пользователей, желающих работать

через нее. Это возможно только в обычном режиме работы службы.

В этом случае клиенты, настроив свой браузер на использование прокси, при попытке вы-

хода в Интернет получат приглашение (с названием DionisNX-PROXY) ввести имя пользователя

и пароль. Служба, одобрив аутентификацию, может с помощью правил доступа задать разное

обслуживание для разных пользователей,прошедших аутентификацию.

В службе существует 1 вид аутентифицации:

• локальная

26.7.1

Локальная аутентификация.

Для аутентификации данного типа необходимо добавить в конфигурацию системы имена поль-

зователей и их пароли. Рассмотрим пример.

Сначала включим локальную аутентификацию:

(config−service−proxy)# auth local 3

Указываем число параллельных процессов аутентификации.

Далее добавим пользователей:

(config−service−proxy)# user ivan pas1

(config−service−proxy)# user liza pas2

(config−service−proxy)# user oleg pas3

(config−service−proxy)# user mary pas4

Например, у пользователя ivan пароль pas1.

Далее создадим список доступа для пользователей:

(config−service−proxy)# acl allusers proxy−auth−all

(config−service−proxy)# acl vipusers proxy−auth ”oleg mary”

(config−service−proxy)# acl url1 url−regex ^http://vk

(config−service−proxy)# http−access permit url1 vipusers

(config−service−proxy)# http−access deny url1 allusers

(config−service−proxy)# http−access permit allusers

(config−service−proxy)# http−access deny all

Данные правила разрешают доступ в Интернет только тем пользователям, которые прошли

аутентификацию. Среди аутентифицированных пользователей запрещен доступ к сайтам, начи-

нающимся на http://vk , всем, кроме пользователей oleg и mary (vipusers).

Также vipusers можно задать в следующем виде:

171

(config−service−proxy)# acl vipusers2 proxy−auth oleg

(config−service−proxy)# acl vipusers2 proxy−auth mary

В данном случае ACL vipusers и vipusers2 полностью идентичны.

26.8

Настройка контроля пропускной способности сети

Данный раздел относится к п.8 Алгоритма.

Служба может контролировать скорость потока данных от удалённых серверов к пользова-

телям: ограничения накладываются только на кэш-промахи, кэш-попадания не ограничиваются

по скорости.

Контроль пропускной способности сети действует при помощи пулов задержки.

Для лучшего понимания настройки рассмотрим механизм пулов задержки на основе аналогии

с ведрами и кранами.

Существует 4 типа ведер:

• общее ведро: может ограничивать весь трафик (тип agr);

• общее ведро, разделенное на 256 индивидуальных ведер: может ограничивать весь трафик

и трафик по каждому из 256 узлов (тип agr-host24);

• общее ведро, разделенное на 256 сетевых ведер, разделенных на 256 индивидуальных

ведер: может ограничивать весь трафика, трафик по каждой из 256 С-сетей и трафик по

каждому из 65536 узлов (т.е. 256 узлов из 256 сетей) (тип agr-net24-host16);

• аналогично предыдущему типу, только добавляется контроль трафика по каждому аутенти-

фицированному пользователю (тип agr-net24-host16-user).

Рассмотрим алгоритм работы контроля скорости трафика на основе общего ведра.

Весь входящий внешний трафик заполняет общее ведро. В этом общем ведре есть один боль-

шой кран, из которого пользователи службы получают данные удаленных серверов, которые

наполняют ведро своим трафиком.

У ведер есть параметры: размер и скорость наполнения. Размеры и скорость указываются в

байтах и байтах в секунду соответственно. Возможно использование префиксов kb,mb,gb - для

кило,мега и гигабайт (размер умножается на 10ˆ3,10ˆ6 и 10ˆ9 соответственно).

Как только клиенты службы через один большой кран сольют себе весь трафик из ведра (в

случае если их общая скорость слива превысит скорость наполнения ведра) и ведро перестанет

успевать наполняться, включается общее ограничение (если оно задано) на скорость подачи

трафика из крана,которое становится равным скорости наполнения ведра. Если скорость слива

ниже скорости наполнения, ведро будет заполняться (до установленного объёма).

Чтобы настроить общее ограничение, следует выполнить команду:

(config−service−proxy)# delay−pool pool1 agr 1mbs/100mb

Данное ведро имеет размер 100Мб и скорость наполнения 1mbs. Пока оно не пусто - клиенты

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

1mbs.

172

Механизм для остальных ведер аналогичен. Отличие только в размере и скорости наполнения

ведер: например, по каждой сети типа С, по каждому узлу, по каждому пользователю.

Рассмотрим пример:

(config−service−proxy)# delay−pool pool2 agr−host24 10mbs/100mb 1mbs/10mb

(config−service−proxy)# delay−pool pool3 agr−net24−host16 10mbs/100mb 1mbs/10mb

100kbs/1mb

(config−service−proxy)# delay−pool pool4 agr−net24−host16−user 10mbs/100mb 1mbs/10mb

100kbs/1mb 50kbs/1mb

(config−service−proxy)# delay−pool pool5 agr−host24 10mbs/100mb −1/−1

Рассмотрим подбробно, какие ведра определены данными командами:

• pool2: общее ведро размером 100Мб и скоростью наполнения 10Мбс, внутри которого есть

256 ведер 1Мбс/10Мб для каждой С-сети;

• pool3: общее ведро размером 100Мб и скоростью наполнения 10Мбс, внутри которого есть

256 ведер 1Мбс/10Мб для каждой С-сети, и в каждом из таких ведер есть 256 ведер, зада-

ющих ограничение 100kbs/1mb на каждый хост;

• pool4: аналогично pool3, только кроме этого задается ведро 50kbs/1mb на каждого пользо-

вателя;

• pool5: аналогичен pool2, только ограничение на С-сеть не накладывается (-1 обозначает

отсутствие ограничения).

Разрешающие правила (delay-access permit) ограничивают трафик ведром, указанным в пра-

виле, для пользователей, попадающих под действие указанного в правиле ACL. Если такое пра-

вило найдено - просмотр правил прекращается и правило применяется.

Запрещающие правила (delay-access deny) не ограничивают трафик ведром, указанным в пра-

виле, для пользователей, попадающих под действие указанного в правиле ACL. Если такое пра-

вило найдено - просмотр правил для ведра данного типа прекращается, однако продолжается

для ведер других типов.

26.9

Правила проверки объектов в кэше на свежесть

Данный раздел относится к пп.6-8 Алгоритма.

Служба имеет возможность настраивать правила, по которым те или иные объекты кэша будут

считаться службой свежими или несвежими.

Свежесть объекта, в свою очередь, определяет, необходимо ли обновлять в кэше объект с

удаленных серверов или нет.

Говоря кратко, чем чаще объекты определяются как свежие, тем больше будет процент попа-

дания в кэш и ,как следствие, большая скорость обслуживания клиентов.

Далее под ресурсом будем понимать именованную последовательность данных, расположен-

ную на HTTP-сервере и доступную по ее URI.

Под объектом будем понимать размещенный в кэше службы ресурс,полученный с HTTP-

сервера.

173

Перед рассмотрением правил напомним и введем несколько понятий.

Заголовки HTTP, необходимые для понимания правил:

• Date : дата генерации HTTP-ответа сервером;

• Last-Modified : дата последней модификации ресурса;

• Expires : дата предполагаемого истечения срока актуальности ресурса;

• If-Modified-Since : выполнять указанный HTTP-метод если ресурс изменился с указанного

момента.

Директивы HTTP-заголовка Cache-Contol, который управляет кэшированием:

• no-cache : сервер не должен использовать кэшированный ответ;

• no-store : ответ на этот запрос не должен кэшироваться;

• max-age : максимальное время хранения объекта в кэше;

• must-revalidate : если кэшированный ответ устарел, то должен быть обновлен, вне зависи-

мости от правил кэш-службы.

Другие термины:

• возраст объекта (ВО) - это разница между Date и Last-Modified объекта; Date обновляется,

а Last-Modified может обновиться во время последнего запроса объекта с HTTP-сервера;

• возраст реакции (ВР) - это степень несвежести объекта, т.е. время прошедшее с момен-

та последнего запроса объекта клиентом; иначе говоря, это время с момента последней

валидации службой объекта на свежесть: возврата свежего объекта из кэша, получения

отсутствующего или обновление несвежего объекта с сервера;

• LM-фактор - это отношение ВР к ВО.

Рассмотрим, как создаются правила проверки на свежесть:

(config−service−proxy)# refresh \\.jpg$ 1000 70% 5000

Все параметры команды refresh обязательны. Разберем их по порядку появления в строке

команды:

• \\.jpg$ - это РВ, задающее URI объектов, для которых будет применяться данное правило;

в данном случае это картинки с расширением jpg;

• 5000 - это максимальный ВР в минутах (ВРМАКС); объект несвеж, если его ВР больше ВР-

МАКС, в данном случае 5000 мин;

• 70% - это максимальный LM-фактор (ЛММАКС); объект несвеж, если его LM-фактор больше

ЛММАКС, в данном случае 70%;

• 1000 - это минимальный ВР в минутах (ВРМИН); объект свеж, если его ВР меньше ВРМИН,

в данном случае 1000 мин.

Правила проверки на свежесть будут работать только для объектов, у которых не указан

Expires, если обратное не указано специальной опцией правила (см.ниже).

174

Чем больше прошло времени с момента последней проверки на свежесть, тем менее свеж

объект и тем больше LM-фактор. Когда LM превысит значение, заданное в команде, объект пере-

станет быть свежим.

Порядок правил важен - как только запрашиваемый объект попадет в одно из правил, поиск

правил будет остановлен для данного объекта.

Рассмотрим алгоритм проверки на свежесть в случае,если не заданы дополнительные опции

правила:

1. проверка по Expires,если он есть в пакете: если дата прошла,то объект не является свежим;

если дата еще не наступила,то объект является свежим; выход;

2. если ВР больше чем ВР_МАКС, то объект не является свежим и требуется его обновление с

удаленного сервера;

3. если ВР меньше чем ВР_МАКС, то осуществляется проверка по LM-фактору: если объект

является свежим - выход;

4. если ВР меньше ВР_МИН, то несвежесть по LM-фактору не убедительна: объект был совсем

недавно получен и мог быть создан также совсем недавно,в результате LM-фактор стал

высоким; т.о если ВР меньше ВР_МИН,то объект является свежим - выход;

5. иначе, несвежесть по LM-фактору убедительна, объект признается устаревшим и необходи-

мо его обновление с удаленного сервера.

Рассмотрим дополнительные опции правила, которые могут изменить вышеописанный алго-

ритм:

• override-expire : игнорировать заголовок Expires;

• override-lastmod : игнорировать заголовок Last-Modified;

• reload-into-ims

: использовать заголовок If-Modified-Since

(только при наличии Last-

Modified) вместо директивы no-cache;

• ignore-no-cache : игнорировать директиву no-cache;

• ignore-no-store : игнорировать директиву no-store;

• ignore-reload : игнорировать директивы no-cache и reload;

• ignore-must-revalidate : игнорировать директиву must-revalidate;

• refresh-ims : всегда обновлять объект, вне зависимости от наличия If-Modified-Since в за-

просе клиента.

Пример использования дополнительных опций:

(config−service−proxy)# refresh \\.jpg$ 10000 70% 20000 reload−into−ims ignore−reload

26.10

Настройка журналов службы

Служба имеет систему журналов. Всего их существует 5 типов:

• cache: общий журнал службы; имеет пять уровней подробности журналирования, причем

каждый следующий уровень включает сообщения предыдущего:

175

- low: : сообщения о критических и фатальных ошибках;

- middle: : сообщения о важных проблемах службы, предупреждения;

- high : сообщения о небольших проблемах службы и высоко-уровневые операции служ-

бы;

• access : информация о доступе к службе и клиентских запросах;

• store : информация об объектах, сохраняемых в кэше и удаляемых из него;

• useragent : информация о клиентских браузерах (на основе заголовка User-Agent HTTP-

запроса);

• referer : информация о доменах, посещаемых клиентами (на основе заголовка Referer HTTP-

запроса).

При нормальной работе системы не следует устанавливать уровень cache журнала выше

middle, чтобы не замедлять работу системы.

Обычно, если нет проблем в работе службе, достаточно бывает следующих журналов:

(config−service−proxy)# log access

(config−service−proxy)# log cache middle

Также можно отключить журнал доступа, оставив только общий журнал службы(cache).

Для просмотра журналов службы следует выполнить команду:

(config−service−proxy)# do show service proxy log

По умолчанию будет показан общий журнал службы.

Чтобы посмотреть, например, журнал доступа, следует выполнить команду:

(config−service−proxy)# do show service proxy log access

Иногда бывает необходимо вести журналы клиентских запросов, но делать это не для всех

клиентов. Для этого существует правило log-access.

Рассмотрим пример:

(config−service−proxy)# acl vip1 src 10.0.0.1 10.0.0.2

(config−service−proxy)# acl vip2 srcdom−regex ^vip

(config−service−proxy)# log−access deny vip1

(config−service−proxy)# log−access deny vip2

(config−service−proxy)# log−access permit all

Данные правила запрещают вести журнал доступа для узлов с адресами 10.0.0.1,10.0.0.2 и

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

он включен.

Рассмотрим формат строки журнала доступа на следующем примере:

16/Apr/2012:16:50:32 +0400 555 192.168.33.116 TCP_MISS/200 250 GET

http://notify5.dropbox.com/subscribe? − DIRECT/199.47.216.147 text/plain

Рассмотрим поля строки журнала по порядку слева направо:

• 16/Apr/2012:16:50:32 +0400 - время (UTC) завершения обработки запроса службой;

176

• 555 - продолжительность (в милисекундах) обработки запроса;

• 192.168.33.116 - адерс клиента;

• TCP_MISS/200 - код результата обработки запроса службой (коды перечислены ниже) и

код HTTP-ответа;

• 250 - полный размер в байтах HTTP-пакета (размер HTTP-заголовков и размер,указанный

в Content-Length);

• GET -метод HTTP;

• http://notify5.dropbox.com/subscribe? - URI запроса;

• DIRECT - код узла, обозначающий,что запрос перенаправляется службой напрямую на уда-

ленный сервер; NONE - запрос не перенаправляется никуда;

• 199.47.216.147 - адрес удалённого сервера, в случае если код узла - DIRECT;

• text/plain - тип содержимого HTTP-ответа, берется из Content-Type заголовка HTTP-ответа.

Коды результата обработки запроса службой приведены ниже:

•

TCP_HIT : в кэше найдена свежая копия ресура; копия возвращена клиенту;

•

TCP_MISS : в кэше не найдена копия ресурса;

•

TCP_REFRESH_HIT : в кэше найдена возможно несвежая копия ресурса; послан запрос ва-

лидации ресурса на УС; УС вернул ответ «Not Modified»,т.е. изначально копия была свежа;

•

TCP_REF_FAIL_HIT : в кэше найдена возможно несвежая копия ресурса; послан запрос ва-

лидации ресурса на УС; УС не вернул ответ или вернул непонятный службе ответ; служба

возвратила клиенту возможно несвежую копию ресурса;

•

TCP_REFRESH_MISS : в кэше найдена возможно несвежая копия ресурса; послан запрос

валидации ресурса на УС; УС вернул возвратил обновленные данные ресурса, т.е. копия в

кэше была действительно несвежая;

•

TCP_CLIENT_REFRESH_MISS : в кэше найдена копия ресурса; клиентский запрос содержал

«Cache-Control: no-cache»; запрос перенаправлен УС, т.е. копия в кэше была принудитель-

но обновлена;

•

TCP_IMS_HIT : клиент прислал запрос валидации ресурса, т.к. он его уже имеет, при помо-

щи IfModifiedSince; в кэше найдена более свежая копия; копия возвращена клиенту;

•

TCP_SWAPFAIL_MISS : в кэше найдена свежая копия ресура; служба не смогла загрузить

копию из своего кэша; послан запрос на УС,как будто это был кэш-промах;

•

TCP_NEGATIVE_HIT : отрицательный HTTP-ответ (например «Connection refused» или «404

Not Found») был ранее закэширован; клиенту возвращён закэшированный отрицательный

ответ;

•

TCP_MEM_HIT : в памяти найдена свежая копия ресурса и возвращена клиенту;

•

TCP_DENIED : запрос клиента запрещен из-за правил доступа (http-access или http-reply-

access);

•

TCP_OFFLINE_HIT : если включен режим offline, любой ресурсы,найденный в кэше возвра-

щается клиенту,без проверки на свежесть;

•

NONE - другой результат; используется при разного рода ошибках в запросе, например

непонятный URI ресурса.

177

26.11

Работа со службой

Для запуска службы следует выполнить команду:

(config−service−proxy)# enable

Для остановки службы следует выполнить команду:

(config−service−proxy)# disable

Для просмотра статуса и правильности настройки службы следует выполнить команду:

(config−service−proxy)# do show service proxy status

Строка «Info: config is ok» говорит о том, что все в порядке. Любые строки, начинающиеся с

«Error: » говорят об ошибках.

Чтобы удалить объект из кэша службы по его URI, следует выполнить команду:

(config−service−proxy)# do service proxy remove−object http://example.com/pic.jpg

Команда будет выполнена, только если служба включена.

Очистка всего кэша:

(config−service−proxy)# do service proxy remove−object all

Команда будет выполнена, только если служба отключена.

Обновление объекта в кэше:

(config−service−proxy)# do service proxy reload−object http://example.com/pic.jpg

Команда будет выполнена, только если служба включена.

Чтобы посмотреть различную информацию о работе службы:

(config−service−proxy)# do show service proxy info

Существует много типов информации, которую можно посмотреть, используя данную команду.

Эта команда описана более подробно в следующем подразделе «Мониторинг службы».

26.12

Мониторинг службы

Служба прокси имеет мощную систему мониторинга своего состояния. Мониторинг службы

осуществляется различными подкомандами команды show service proxy info.

Рассмотрим данные подкоманды.

178

26.12.1

Общая информация

Общая информация о работе службы:

# show service proxy info

Будучи вызвана без параметров, эквивалентна команде:

# show service proxy info general

Формат вывода данной команды:

•

Squid Object Cache - версия службы;

•

Start Time - время запуска службы;

•

Current Time - текущее время;

•

Connection information for squid - информация о соединениях и клиентах:

- Number of clients accessing cache - число обслуженных клиентов; клиенты различаются

по из IP-адресам;

- Number of HTTP requests received - число полученных HTTP-запросов;

- Request failure ratio - соотношение неуспешных запросов (ошибка в TCP соедине-

нии,ошибка DNS или аппаратная сетевая ошибка) к успешным;

- Average HTTP requests per minute since start - среднее число HTTP запросов в минуту;

- Select loop called - среднее число вызовов select()/poll() и среднее время между ними;

•

Cache information for squid - информация о кэше:

- Hits as % of all requests - процент кэш-попаданий во всех запросов за последние 5 и

60 минут;

- Hits as % of bytes sent - процент трафика кэш-попаданий во всем трафике за последние

5 и 60 минут;

- Memory hits as % of hit requests - процент кэш-попаданий в памяти (TCP_MEM_HIT) во

всех кэш-попаданиях;

- Disk hits as % of hit requests - процент кэш-попаданий на диске (TCP_HIT) во всех

кэш-попаданиях;

- Storage Swap size - размер (Кб) данных в кэше на диске;

- Storage Swap capacity - процент заполнения данными кэша на диске;

- Storage Mem size - размер (Кб) данных в кэше в памяти;

- Storage Mem capacity - процент заполнения данными кэша в памяти;

•

Median Service Times (seconds) - среднее время выполнения операций (в секундах):

- HTTP Requests (All) - среднее время выполнения запроса;

- Cache Misses - среднее время выполнения запроса при кэш-промахе;

- Cache Hits - среднее время выполнения запроса при кэш-попадании (запросы с ре-

зультатом TCP_HIT, TCP_MEM_HIT);

- Near Hits - среднее время выполнения запроса при кэш-обновлении (запросы с резуль-

татом TCP_REFRESH_HIT);

- Not-Modified Replies - среднее время выполнения запроса If-modified-since (запросы с

результатом TCP_IMS_HIT);

179

- DNS Lookups - среднее время выполнения DNS-разрешения (прямого и обратного);

•

Resource usage for squid - статистика использования ЦПУ и памяти службой (значения вре-

мени - в секундах):

- UP Time - время работы службы в секундах;

- CPU Time - процессорное время,использованное службой;

- CPU Usage - процент использования процессора службой; отношение CPU Time к UP

Time;

- CPU Usage, 5 minute avg - аналогично предыдущему, но за последние 5 минут;

- CPU Usage, 60 minute avg - аналогично предыдущему, но за последние 60 минут;

- Process Data Segment Size via sbrk() - размер сегмента данных службы (Кб);

- Maximum Resident Size - максимальный размер памяти, доступный службе;

- Page faults with physical i/o - число ошибок «Отсутствие страницы в памяти»;

•

Memory usage for squid via mallinfo() - статистика использования памяти службой:

- Total space in arena - общий объем памяти,выделенный службе;

- Ordinary blocks,Small blocks и др. - прочая информация о памяти возвращаемая функ-

цией mallinfo();

•

Memory accounted for - информация по учету выделенной памяти (размер указан в Кб):

- Total accounted - общий объем отслеживаемой памяти;

- memPool accounted - общий объем отслеживаемой памяти пулов (стуктур фиксирован-

ного размера);

- memPool unaccounted - общий объем неотслеживаемой памяти для пулов;

- memPoolAlloc calls - число вызовов функции memPoolAlloc, выделяющей пулы;

- memPoolFree calls - число вызовов функции memPoolAlloc, освобождающей пулы;

•

File descriptor usage for squid - статистика использования файловых дескрипторов (ФД):

- Maximum number of file descriptors - максимально возможное число ФД для службы;

- Largest file desc currently in use - максимальное число ФД, задействованных на данный

момент;

- Number of file desc currently in use - число ФД, используемых в настоящее время;

- Files queued for open - число файлов в очереди на открытие (ненулевое значение

возможно только для типа кэша aufs);

- Available number of file descriptors - доступное число ФД;

- Reserved number of file descriptors - зарезервированное число ФД;

- Store Disk files open - число открытых файлов в настоящий момент;

•

Internal Data Structures - статистика мест хранения объектов:

- StoreEntries - число закэшированных службой объектов; каждый объект потребляет

около 100 байт памяти службы (пул StoreEntry; см. далее info mem);

- StoreEntries with MemObjects - число объектов, закэшированных в памяти, и объектов,

к которым обращаются в настоящий момент;

- Hot Object Cache Items - число объектов, закэшированных в памяти;

- on-disk objects - число объектов закэшированных на диске.

180

26.12.2

Активные соединения

Следующая команда показывает список активных соединений на данный момент времени:

# show service proxy info active−requests

Формат вывода команды:

• Сonnection - адрес памяти структуры соединения;

• FD - дексриптор сокета для TCP соединения, после которого следует объем принятых и

переданных через него данных;

• FD desc - краткое описание сокета, обычно это URI;

• in - адрес памяти буфера приема, смещение следующих принятых данных и размер буфера

приема;

• peer - удаленный сокет для TCP-соединения (для режима перерывания - это сокет клиента);

• me - локальный сокет для TCP-соединения удаленного сервера (для режима перерывания

- это сокет клиента);

• nrequests - число запросов,полученных по данному соединению;

• defer - осуществляется ли отложенное чтение на сокете соединения;

• uri - запрашиваемый URI из запроса клиента;

• log_type - статус кэша по данному запросу - то, что появится в журнале доступа после

завершения обработки запроса;

• out.offset - смещение по которому запрашиваются данные (имеет смысл во время скачива-

ния больших файлов);

• out.size - размер данных в ответе;

• req_sz - размер HTTP-запроса клиента;

• entry - адрес памяти структуры хранения (StoreEntry) и ее хэш;

• start - сколько секунд назад инициировано соединение.

26.12.3

AUFS

Следующая команда выводит данные по асинхронной обработке запросов при типе кэша aufs:

# show service proxy info aufs

Формат вывода команды:

• open,close,read,write и т.д. - счетчики асинхронно выполненных файлов операций (откры-

тие,закрытие,чтение,запись и т.д.);

• Threads status: число асинхронных файловых операций;

• queue: размер очереди запросов; при превышении 80 (5*16, где 16 - число асинхронных

потоков) - будет выдано предупреждение о загруженности системы.

181

26.12.4

Аутентификация

Следующая команда показывает статистику по аутентификации пользователей:

# show service proxy info auth

Имеет смысл только при включённой аутентификации пользователей.

26.12.5

Клиенты

Следующая команда показывает статистику по по клиентам службы:

# show service proxy info clients

Формат вывода команды:

• Address: IP-адрес клиента;

• Name: FQDN-имя клиента;

• Currently established connections: число открытых соединений клиента и службы;

• HTTP Requests: число HTTP запросов клиента;

• TCP_HIT,TCP_MISS,…: статистика результатов запросов.

26.12.6

Трафик и ресурсы

Следующая команда показывает статистику по трафику и ресурсам:

# show service proxy info counters

Формат вывода команды:

• sample_time - время последнего расчета счетчиков; расчет производится не реже, чем один

раз в минуту;

• client_http.requests - число HTTP-запросов, полученных от клиентов;

• client_http.hits - число кэш-попаданий в ответ на HTTP-запросы клиентов; соответствует

числу строк с типом результата TCP_HIT в журнале доступа;

• client_http.errors - число клиентских транзакций, приведших к ошибке;

• client_http.kbytes_in - объем HTTP-трафика в Кб, полученного от клиентов (HTTP-запросы);

• client_http.kbytes_out - объем HTTP-трафика в Кб, переданного клиентам (HTTP-ответы);

• client_http.hit_kbytes_out - объем HTTP-трафика в Кб, переданного клиентам (HTTP-ответы)

в результате кэш-попаданий, включая ответы с кодом 304 (Not Modified);

• server.all.requests - число запросов, переданных на УС;

• server.all.errors - число запросов на УС, приведших к ошибке;

• server.all.kbytes_in - объем трафика в Кб, полученого с УС;

• server.all.kbytes_out - объем трафика в Кб, переданного на УС;

• server.http… - аналогично server.all, но только для HTTP-запросов;

182

• server.ftp… - аналогично server.all, но только для FTP-запросов;

• server.other… - аналогично server.all, но только для прочих запросов (Gopher, WAIS, SSL);

• page_faults - число ошибок «Обращение к отсутствующей странице»;

• select_loops - число раз вывзова seclect()/poll() в главном цикле ввода-вывода службы;

• cpu_time - накопленное время CPU в секундах;

• wall_time - время, прошедшее с последнего расчета счетчиков;

• swap.outs - количество объектов(файлов), записанных в дисковый кэш службы;

• swap.ins - количество объектов(файлов), считанных с дискового кэша;

• swap.files_cleaned - количество объектов(файлов), удаленных периодической процедурой

очистки;

• aborted_requests - число отмененных запросов на УС, произошедших из-за отмены их кли-

ентами.

26.12.7

Пулы задержки

Следующая команда показывает статистику по пулам задержки (в байтах):

# show service proxy info delay

Формат вывода команды:

• Aggregate/Network/Individual - тип пула (общий/сетевой/индивидуальный);

• Max - размер пула;

• Restore(Rate) - объем данных,добавляемых к пулу каждую секунду;

• Current - текущий объем пула; узлы опредлеляются последним значимым октетом.

Пример для agr: Current: 12345

Пример для agr-host24: Current: 1:1234 2:5678, где 1,2 - последний октет IP-адреса хоста.

Пример для agr-net24-host16: Current [Network 5]: 1:1234 2:5678, где 1,2 - последний октет

IP-адреса хоста, 5 - предпоследний октет IP-адреса сети, например 10.0.5.0/24.

26.12.8

Открытые файлы

Следующая команда показывает статистику по файлам,открытым службой:

# show service proxy info filedescriptors

Формат вывода команды:

• File - дескриптор файла;

• Type - тип файла: File - для дискового кэша, лог-файла; Pipe - канал для IPC, межпроцсесс-

ного взаимодействия; Socket - соект для свзяи с клиентами,УС и IPC;

• Tout - таймаут для файлов типа Socket; такой файл закроется,если по нему не будет актив-

ности по истечении указанного таймаута;

183

• Nread - количество байт, прочитанных из файла;

• Nwrite - количество байт, записанных в файл;

• Remote Address - для файлов типа Socket это удаленный TCP-адрес соединения (удаленный

сокет);

• Description - описание файла для типов Socket/Pipe или путь к файлу для типа File.

26.12.9

X-Forwarded-For-заголовки

Следующая команда показывает полученные X-Forwarded-For заголовки:

# show service proxy info forward−headers

X-Forwarded-For-заголовок содержит IP-адреса клиентов,для которых данный HTTP-запрос

был ретранслирован прокси-сервером. Например,если служба получает HTTP-запрос от узла, в

котором содержится X-Forwarded-For-заголовок с адресом 1.1.1.1, это значит, что служба полу-

чила данный запрос от другого прокси-сервера, который, в свою очередь, получил этот запрос

от узла 1.1.1.1.

26.12.10

Via-заголовки

Следующая команда показывает полученные Via-заголовки:

# show service proxy info via−headers

Via-заголовок содержит имена и,возможно, порты и другую идентифицирующую информацию

прокси-сереверов, через которые прошел полученный службой HTTP-запрос.

26.12.11

HTTP-заголовки

Следующая команда показывает статистику по HTTP-заголовкам:

# show service proxy info http−headers

Формат вывода команды:

• Header Stats: request - статистика по HTTP-запросам;

- Field type distribution - распределение HTTP-заголовков:

* id - внутренний идентификатор;

* name - имя заголовка;

* count - количество заголовков;

* #/header - частота появления заголовков; например, частота 1.0 означает,что

заголовок присутствует в каждом запросе;

- Cache-control directives distribution - распределение директив кэширования заголовка

Cache-Control:

184

* id - внутренний идентификатор;

* name - имя директивы;

* count - количество директив;

* #/cc_field - частота появления директив кэширования;

- Number of fields per header distribution - распределение количества HTTP-заголовков:

* id - внутренний идентификатор;

* #flds - количество заголовков;

* count - число запросов с указанным в поле #flds количеством заголовков;

* %total - доля запросов с указанным в поле #flds количеством заголовков в общем

числе запросов;

•

Header Stats: reply - статистика по HTTP-ответам. Поля аналогичны полям для Header Stats:

request;

•

Http Fields Stats (replies and requests) - статистика по HTTP-запросам и HTTP-ответам:

- id - внутренний идентификатор;

- name - имя заголовка;

- #alive - количество заголовков типа name, хранаящихся в данный момент в памяти

(заголовки активных содеинений и для объектов,хранящихся в кэш-памяти службы;

- %err - процент ошибочных заголовков типа name;

- %repeat - доля запросов/ответов, с повторяющимися однотипными заголовками типа

name;

•

Headers Parsed - число обработанных HTTP-запросов/ответов;

•

Hdr Fields Parsed - число обработанных HTTP-заголовков.

26.12.12

DNS-клиент

Следующая команда показывает статистику по внутреннему DNS-клиенту службы:

# show service proxy info idns

Формат вывода команды:

• The Queue - очередь неразрешенных DNS-запросов:

- ID - внутренний идентификатор;

- SIZE - размер запроса;

- SENDS - число попыток запроса;

- FIRST SEND / LAST SEND - промежуток времени между последним и первым запросом;

• Nameservers - статистика запросов/ответов на сервера имен:

- IP ADDRESS - адрес сервера имен;

- # QUERIES - число посланных на сервер имен запросов;

- # REPLIES - число полученных от сервера имен ответов;

• Rcode Matrix - статистика DNS-ответов:

185

- RCODE - код ответа:

* 0 - успешный ответ;

* 1 - сервер имен не смог понять запрос (Format Error);

* 2 - проблема с сервером имен (Server Failure);

* 3 - доменное имя не существует (Name Error);

* 4 - сервер имен не поддерживает указанный тип запроса (Not Implemented);

* 5 - отказ в обработке запроса из-за политики безопасности сервера (Refused);

- ATTEMPT1 - число одинарных повторных попыток запроса в результате получения

RCODE=2;

- ATTEMPT2 - число двойных повторных попыток запроса в результате получения

RCODE=2;

- ATTEMPT3 - число тройных повторных попыток запроса в результате получения

RCODE=2;

• Search list - список доменов,используемых при разрешении имен.

26.12.13

DNS-кэш

Следующая команда показывает статистику по внутреннему DNS-кэшу службы:

# show service proxy info ipcache

Формат вывода команды:

• IP Cache Statistics - статистика по DNS-кэшу:

- IPcache Entries In Use - количество записей кэша, используемых в настоящее время;

- IPcache Entries Cached - количество записей кэша;

- IPcache Requests - число DNS-запросов;

- IPcache Hits - число DNS-запросов, разрешенных из кэша DNS-службы;

- IPcache Negative Hits - число DNS-запросов, негативно разрешенных из кэша DNS-

службы;

- IPcache Numeric Hits - число запросов разрешения адреса в имя, разрешенных из кэша

DNS-службы;

- IPcache Misses - число DNS-запросов, разрешенных через DNS-сервер,а не из кэша

DNS-службы;

- IPcache Retrieved A - число полученных А-записей;

- IPcache Retrieved AAAA - число полученных АААА-записей;

- IPcache Retrieved CNAME - число полученных CNAME-записей;

- IPcache CNAME-Only Response - число полученных только CNAME-записей;

- IPcache Invalid Request - число неверных DNS-запросов;

• IP Cache Contents - кэш DNS-службы для наиболее популярных имен:

- Hostname - доменное имя;

- Flg - флаги: N - кэширование негативно разрешенного имени; H - разрешение пришло

из статического назначения системы (см. ip resolver hosts);

186

- lstref - показывает, сколько секунд назад запись использовалась последний раз;

- TTL - время жизни записи в кэше (секунд);

- N(b) - N: число IP-адресов имени (адреса с суффиксом OK); b: число IP-адресов имени,

которые недоступны в настоящее время (адреса с суффиксом BAD);

- последняя колонка - показывает IP-адреса с суффиксом OK или BAD (см. N(b) колон-

ку).

26.12.14

Память

Следующая команда показывает статистику использования памяти службой:

# show service proxy info mem

Формат вывода команды:

• Largest pools stats - статистика по двум максимальным пулам фиксированных структур:

- Pool name - имя пула: StoreEntry - пул структур,создаваемая на каждый кэшированный

объект; MD5-digest - пул хэшей ответа; All-pools - все пулы;

- Size - размер экзампляра стуктуры (байт);

- Number - число структур в пуле;

- TotSize - общий размер пула;

- HiSize - максимально наблюдаемый размер пула;

• Cumulative allocated volume - общий объем памяти, выделенной службе; часть ее может

быть освобождена; учитывается только выделяемая память;

• Total Pools created - общее число созданных пулов;

• Pools ever used - число использованных по настоящий момент пулов;

• Currently in use - число используемых в настоящий момент пулов.

26.12.15

Свежесть

Следующая команда показывает статистику алгоритма проверки на свежесть:

# show service proxy info refresh

Формат вывода команды:

• HTTP histogram - показывает распределение проверок на свежесть, приведших к решению

о свежести объекта (Fresh/Stale - свежий/несвежий), при запросе его клиентом:

- Count - общее число проверок данного типа;

- %Total - доля проверок данного типа;

- Category - тип проверки на свежесть: —причины свежести—

* Fresh: request max-stale wildcard - в запросе была директива max-stale, т.е. клиент

хочет принять объект любой свежести;

187

* Fresh: request max-stale value -в запросе была директива max-stale со значени-

ем больше времени,прошедшего с момента истечения времени жизни объекта

(Expires);

* Fresh: expires time not reached - момент истечения времени жизни объекта еще не

наступил;

* Fresh: refresh_pattern last-mod factor percentage - объект подпадает под refresh-

правило; LM-фактор объекта меньше указанного в правиле LM-фактора;

* Fresh: refresh_pattern min value - возраст объекта меньше указанного в значении

min правила refresh, в которое попадает объект;

* Fresh: refresh_pattern override expires - объект подпадает под refresh-правило с

параметром override-expire;

* Fresh: refresh_pattern override lastmod - объект подпадает под refresh-правило с

параметром override-lastmod; —причины несвежести—

* Stale: response has must-revalidate - запрос содержит директиву кэширования

Cache-Control: must-revalidate;

* Stale: changed reload into IMS - объект подпадает под refresh правило с парамет-

ром reload-into-ims;

* Stale: request has no-cache directive - запрос содержит директиву кэширования

Cache-Control: no-cache;

* Stale: age exceeds request max-age value - в запросе была директива max-age со

значением меньше возраста объекта;

* Stale: expires time reached - момент истечения времени жизни объекта наступил;

* Stale: refresh_pattern max age rule - возраст объекта больше указанного в значе-

нии max правила refresh, в которое попадает объект;

* Stale: refresh_pattern last-mod factor percentage - объект подпадает под refresh-

правило; LM-фактор объекта не меньше указанного в правиле LM-фактора;

* Stale: by default - объект не подпадает ни под один критерий алгоритма проверки,

в связи с чем признается несвежим по умолчанию;

* TOTAL - общее число проверок;

•

On Store histogram - аналогично HTTP histogram, но для проверок на свежесть ответов УС

для кэш-промахов.

26.12.16

Ретрансляция запросов

Следующая команда показывает статистику ретрансляции запросов УС:

# show service proxy info requests

Формат вывода команды:

• Status - код HTTP-ответа:

- 1xx: Informational (информационные);

- 2xx: Success (успешно);

- 3xx: Redirection (перенаправление);

- 4xx: Client Error (ошибка клиента);

188

- 5xx: Server Error (ошибка сервера);

• try#1-10 - число попыток, предпринятых для получения ответа типа Status (try#1 - одна

попытка,…,try#10 - десять попыток).

26.12.17

Кэш

Следующая команда показывает статистику по кэшу:

# show service proxy info storage

Формат вывода команды:

• Store Entries - число кэшированных объектов;

• Store Directory #0 - указывает тип кэша (aufs);

• FS Block Size - размер блока файловой системы (байт);

• First level subdirectories - число директорий первого уровня;

• Second level subdirectories - число директорий второго уровня;

• Maximum Size - максимальный размер кэша;

• Current Size - текущий размер кэша;

• Percent Used - текущая заполненность кэша;

• Filemap bits in use - сколько битов файловой карты использовано;

• Filesystem Space in use - объем места на диске, использованного службой;

• Filesystem Inodes in use - сколько использовано инодов;

• Flags: SELECTED - всегда значение SELECTED; значит что кэш в режиме чтения-запись;

формат read-only для кэша не поддерживается;

• Removal policy - типа политики замены объектов в дисковом кэше: lru - для LRU, heap - для

LFUDA, GDSF или HLRU;

• LRU reference age - показывает дату самого старого объекта кэша; только для политики

замены объектов LRU.

26.12.18

Рекомендации по настройке

26.12.18.1

Размер дискового кэша

Размер дискового кэша определяется опытным путем в зависимости от нужд клиентов службы,

их числа, а также размера доступной оперативной памяти.

Например при использовании 4Гб дискового кэша объем потребляемой памяти при полном

заполнении кэша будет варьироваться в пределах 150-200Мб.

189

27. Служба SNMP

имеет службу SNMP.

Данная служба позволяет другим узлам получить SNMP-информацию о системе, а также отсы-

лает другим узлам SNMP-нотификации о старте и остановке службы.

27.1

Общая настройка службы SNMP

Чтобы войти в режим настройки службы, следует выполнить команду:

(config)# service snmp

Настройка интерфейса и/или порта, который служба будет использовать для приема запросов

и посылки ответов, нотификаций, например:

(config−service−snmp)# listen 192.168.0.1 udp

По умолчанию,используется UDP-порт 161 и любой локальный интерфейс, которому назначен

IP-адрес.

27.2

Настройка базовой SNMP информации

Настройка общей информации о системе. Например:

(config−service−snmp)# sysinfo location russia

(config−service−snmp)# sysinfo name router1

(config−service−snmp)# sysinfo name admin@domain

Этими командами можно задать, соответственно, физическое местонахождение системы, имя

системы и адрес электронной почты администратора системы.

27.3

Настройка правил доступа

Настройка правил, по которым другим узлам разрешено получать информацию о системе по

SNMP-протоколу. Например:

(config−service−snmp)# acl pas1

(config−service−snmp)# acl pas2 1.2.3.4

(config−service−snmp)# acl pas3 2.2.2.0/24

Рассмотрим приведенные в примере команды:

• первая команда: первый параметр команды (pas1) - это обязательный параметр, задающий

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

о системе по протоколу SNMP. Адрес узла может быть любой, т.к. он не указан.

190

• вторая команда: только узел с адресом 1.2.3.4 и паролем доступа pas2 может получить

информацию о системе по протоколу SNMP.

• третья команда: только узлы сети 2.2.2.0/24 и паролем доступа pas3 могут получить ин-

формацию о системе по протоколу SNMP.

27.4

Настройка правил нотификаций

Настройка правил, по которым другим узлам разрешено получать нотификации от службы

SNMP. Например:

(config−service−snmp)# notify pas1 1.2.3.4

(config−service−snmp)# notify pas2 1.2.3.5:5555 v2

(config−service−snmp)# notify pas3 1.2.3.6:5556 v2c tcp

Рассмотрим третью команду в примере.

Первый обязательный параметр команды (pas3) - это пароль доступа, который должен быть

установлен в конфигурации SNMP-клиента, который хочет получать нотификации.

Второй обязательный параметр команды (1.2.3.6) - это IP-адрес клиента, которому разрешено

посылать нотификации.

Остальные параметры - это порт, версия нотификаций и транспортный протокол. По умолча-

нию,используется UDP-порт 162 и версия нотификаций v2c.

Нотификации, посылаемые по умолчанию (не требуется настройка):

• NET-SNMP-AGENT-MIB::nsNotifyShutdown - посылается при выключении службы;

• SNMPv2-MIB::coldStart - посылается при включении службы;

• NET-SNMP-AGENT-MIB::nsNotifyRestart - посылается при перезапуске службы (например,

во время настройки уже запущенной службы).

Дополнительно можно включить следующие типы нотификаций (команда указана после опи-

сания нотификации):

• SNMPv2-MIB::authenticationFailure - посылается при неуспешной аутентификации SNMP-

клиента (например, когда он послал серверу неверный пароль).

Включение дополнительных нотификаций осуществляется командой:

(config−service−snmp)# trap auth

27.5

Работа со службой

Для запуска службы выполните команду:

(config−service−snmp)# enable

193

28. SSH

В рамках системы протокол SSH не считается защищенным и, соответственно, его

использования недостаточно для установления доверенного канала передачи данных. Для созда-

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

28.1

Сервер SSH

В системе реализована возможность удалённого доступа к командному интерфейсу по

протоколу SSH.

Чтобы разрешить удалённый доступ к данному узлу, необходима активировать службу SSH

следующими командами (из режима конфигурации):

(config)# service ssh

(config−service−ssh)# enable

По умолчанию служба будет принимать SSH-соединения на всех интерфейсах. Есть возмож-

ность настроить службу для приёма SSH-соединений на одном локальном IP-адресе и/или изме-

нить TCP порт по умолчанию (22). Для этого необходимо указать опцию «listen». Например:

(config−service−ssh)# listen 192.168.1.1

или

(config−service−ssh)# listen 0.0.0.0 2222

Данная опция может быть очищена с помощью команды «no listen».

Также можно отдельно задать порт для приема соединений:

(config−service−ssh)# port 2222

В этом случае указанный порт будет использоваться для всех слушающих IP-адресов, если в

соответствующей команде «listen» порт не задан явно. Допустимо указание нескольких слушаю-

щих портов. Очистить опцию можно с помощью команды «no port»:

(config−service−ssh)# no port 2222

По умолчанию возможен доступ извне только к учётной записи «cli», которая обеспечивает

доступ к командам непривилегированного режима, и для входа в привилегированный режим бу-

дет необходимо ввести команду «enable». Чтобы ускорить доступ к привилегированному режиму

через учётную запись «adm», необходимо включить опцию:

(config−service−ssh)# permit−adm−login

Данная опция может быть очищена командой «no permit-adm-login».

Следует помнить, что если настройки службы редактируются при работающей (активирован-

ной) службе, необходимо перезапустить службу, чтобы настройки вступили в силу:

(config−service−ssh)# disable

(config−service−ssh)# enable

194

Чтобы остановить службу и удалить все настройки, нужно выполнить команду режима конфи-

гурации:

(config)# no service ssh

28.1.1

Контроль доступа

Для контроля доступа к сервису ssh предусмотрены команды «allow» и «deny». Контроль осу-

ществляется на основании имени пользователя и удаленного адреса, с которого происходит по-

пытка соединения (user[@host]). В имени пользователя или удаленном адресе могут быть исполь-

зованы шаблоны («*» - ноль или более символов, »?» - ровно один символ).

Команды «allow» и «deny» соответственно разрешают или запрещают доступ для указанных

пользователей. Команда «deny» имеет более высокий приоритет, чем команда «allow». Команд

«allow» и «deny» может быть несколько. Если используется команда «allow», то доступ будет

предоставлен только указанным пользователям (и адресам). Всем остальным пользователям в до-

ступе будет отказано. И наоборот, если используется команда «deny», то доступ будет запрещен

указанным пользователям (и адресам). Всем остальным пользователям доступ будет разрешен.

Если команды «allow» и «deny» не используются - доступ по-умолчанию разрешен. Обратите

внимание на то, что администратор adm имеет полный контроль над системой. Возможность уда-

ленного доступа администратора является важным параметром безопасности и контролируется

дополнительной командой режима конфигурирования сервиса ssh - «permit-adm-login» (команда

описана выше). Для учетной записи администратора команды «allow» и «deny» лишь добавля-

ют возможности по контролю доступа на основании удаленного адреса, с которого происходит

попытка соединения.

Удаленный адрес может быть не указан. В этом случае будет учитываться только имя пользо-

вателя.

Следующая команда разрешит доступ оператору cli и запретит всем остальным (в данном

случае adm):

(config−service−ssh)# allow cli

Следующая команда разрешит доступ оператору cli и администратору adm с удаленного адре-

са 192.168.2.3. Доступ с других адресов запрещен:

(config−service−ssh)# allow *@192.168.2.3

Следующая команда запретит доступ администратору adm из подсети 192.168.2.0/24. Доступ

с других адресов разрешен. Доступ оператору cli разрешен с любых адресов:

(config−service−ssh)# deny adm@192.168.2.*

28.2

Клиент SSH

также реализован клиент SSH для удалённого доступа к другим узлам

Команда доступна как из привилегированного, так и из непривилегированного режима. Формат

команды:

195

> ssh <user> <host> [<port>]

Для узлов в качестве <user> можно указывать учётные записи «cli» или «adm».

При обращении на удаленные узлы, информация об этих узлах заносится в список известных

хостов (know-hosts). При повторном обращении на тот же удаленный узел, сравнивается сохра-

ненный (при первом обращении) ключ удаленного хоста и текущий ключ удаленного хоста. Если

ключи не совпадают, соединение считается небезопасным и связь не устанавливается. Это сде-

лано для предотвращения подмены удаленного хоста. Для просмотра списка известных хостов

используется следующая команда:

Router# show ssh known−hosts

Если администратор знает, что удаленный хост был легально заменен или изменился ключ

удаленного хоста, он может удалить из списка известных хостов информацию о таком узле. Это

позволит установить связь и сохранить новый ключ хоста в списке известных хостов:

Router# clear ssh known−hosts 192.168.1.33

также можно полностью очистить список известных хостов:

Router# clear ssh known−hosts all

28.3

Соединение без использования паролей

Если соединение с удаленным узлом по протоколу SSH является частой операцией, неудобно

каждый раз вводить пароль. Для установления соединения без использования паролей могут

использоваться открытые ключи.

Если администратор, находясь на хосте А, хочет устанавливать соединение с хостом Б, то на

хосте А он должен создать закрытый и открытый ключи:

A# ssh key generate

Затем открытый ключ должен быть отправлен на хост Б. В случае, если хост Б работает под

управление системы

, администратор может выполнить команду:

A# ssh key export host adm 192.168.1.2

Предполагается, что хост Б имеет IP-адрес 192.168.1.2 и администратор желает устанавливать

соединение используя учетную запись adm на удаленном хосте. Последним аргументом может

быть указан удаленный порт. В данном случае порт не указан и, соответственно будет исполь-

зован стандартный номер для SSH протокола - 22. После получения ключа, хост Б добавит этот

ключ в список авторизованных ключей (authorized-keys). Все последующие соединения с хоста

A на хост Б будут происходить без использования пароля.

В случае, если хост Б работает под управлением операционной системы отличной от

администратор может записать созданный открытый ключ в файл на хосте А:

A# ssh key export file open.key

196

Где open.key - произвольное имя файла, в который будет сохранен открытый ключ. После

этого файл может быть скопирован на хост Б любым удобным способом и добавлен в список

авторизованных ключей. Например в Linux-системах файл с авторизованными ключами находится

в домашней директории пользователя и называется ~/.ssh/authorized_keys.

Если же на хосте А установлена система, отличная от Dionis NX C 1.2-10 Hand UTM,

администратор может скопировать файл с открытым ключом с хоста А на хост Б любым

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

хосте Б:

B# ssh key import file open.key

Где open.key - имя файла с открытым ключом.

Администратор может просмотреть список авторизованных ключей используя команду:

B# show ssh authorized−keys

Для более детального вывода, можно указать опцию «verbose».

B# show ssh authorized−keys verbose

Если какой-либо ключ больше не требуется, он может быть удален из списка авторизованных

ключей:

B# clear ssh authorized−keys adm@A

Где «adm@А» идентифицирует ключ в списке авторизованных ключей и является последним

полем при выводе на экран детального списка авторизованных ключей. Можно удалить сразу все

ключи из списка авторизованных ключей:

B# clear ssh authorized−keys all

28.4

Передача файлов

Протокол SSH может использоваться для передачи файлов. Если администратор хочет полу-

чить файл с удаленного хоста, он может выполнить следующую команду:

Router# ssh get petrov 192.168.1.2 /tmp/test.txt

Где «petrov» - учетная запись на уделенном хосте, «192.168.1.2» - IP-адрес удаленного хоста,

»/tmp/test.txt» - путь к файлу. Для отправки файла на удаленный хост, администратор может

выполнить команду:

Router# ssh put test.txt petrov 192.168.1.2

Описанные команды соответствуют команде scp в Linux-системе. Файлы с Linux-системы (и

других систем, поддерживающих протокол SSH) могут быть отправлены на хост с системой

197

29. Telnet

Система имеет службу Telnet, реализующую сетевой протокол уровня приложений для

создания текстового интерфейса по сети.

29.1

Настройка

Для входа в режим конфигурации службы следует выполнить команду:

(config)# service telnet

Для настройки сокета, на котором служба будет ожидать Telnet-соединение, выполните:

(config−service−telnet)# listen 192.168.0.1 1023

(config−service−telnet)# listen 192.168.1.1

Если порт не указан, по умолчанию используется порт 23. В данном случае мы предписы-

ваем службе принимать запросы на адресе 192.168.0.1 и использовать порт 1023, и на адресе

192.168.1.1 и использовать порт 23.

Возможно указание множества сокетов для принятия соединений.

По умолчанию,если не указано ни одной опции listen, служба ожидает соединения на всех

интерфейсах и на порту 23.

Чтобы включить службу выполните

(config−service−telnet)# enable

Чтобы выключить службу выполните

(config−service−telnet)# disable

Если служба включена, для изменения ее опций выполните:

• измените нужную опцию

• выполните команду disable

• выполните команду enable

199

30. Сервис DIWEB

В системе реализована возможность удалённого доступа к визуальному Web-интерфейсу по

протоколу HTTP. Сервис позволяет конфигурировать часть функций системы.

В текущей версии Dionis- NX работа через Web-интерфейс возможна только с помощью учет-

ной записи “adm”. При этом учетная запись “adm” должна иметь статус “supervisor”, т.е. иметь

полный доступ к возможностям системы.

Чтобы разрешить удалённый доступ к данному узлу, необходима активировать службу diweb

командами (из режима конфигурации):

(config)# service diweb

(config−service−web)# enable

По умолчанию служба будет принимать соединения на всех интерфейсах. Есть возможность

настроить службу для приёма HTTP-соединений на одном локальном IP-адресе и/или изменить

порт по умолчанию (80). Для этого необходимо указать опцию «listen». Например:

(config−service−web)# listen 192.168.1.1

или

(config−service−web)# listen 0.0.0.0 8080

Данная опция может быть очищена с помощью команды «no listen».

Следует помнить, что если настройки службы редактируются при работающей (активирован-

ной) службе, необходимо перезапустить службу, чтобы настройки вступили в силу:

(config−service−web)# disable

(config−service−web)# enable

Чтобы остановить службу и удалить все настройки, нужно выполнить команду режима конфи-

гурации:

(config)# no service diweb

Руководство по настройке ПО на базе операционной системы Dionis NX C 1.2-10 Hand UTM (2015 год) - часть 4