Фильтры не действуют для локальных серверов.
16.6 Группа 'HTTP'
Стандартные настройки HTTP. Для разрешения обслуживания UserGate этого протокола, необходимо установить галочку 'Разрешить HTTP'.
Если на машине свободен 80 порт, можно поставить его, нет - что-нибудь другое. Соответственно настраиваются клиенты. При смене значения происходит внутренний рестарт прокси и на мониторе можно посмотреть, что всё удалось (или нет).
Если нужно подключиться каскадом к верхнему прокси, необходимо установить соответсвующую галочку и задать его IP и порт.
Если на parent-proxy требуется авторизация, достаточно установить галочку 'Авторизация на прокси каскада' и задать login и password. В этом случае ко всем http-заголовкам будет добавляться информация по авторизации, что позволит подключиться к парент-прокси, как обычный авторизованный пользователь.
Ну и если можно разрешить доступ к FTP- серверам по протоколу HTTP, поставьте соответствующую галочку.
Реализация HTTP прокси.
В целом всё сделано достаточно классически.
Применяется базовый механизм авторизации на основе кодировки base64.
Получив соединение с клиентом, прокси разбирает заголовок, определяет, что это действительно http запрос, делает выводы о необходимости авторизации и возможности кэширования. Далее проверяется, не соответствует ли запрашиваемый документ списку внутренних команд прокси, не превышены ли ограничения для пользователя и нет ли запрашиваемого ресурса в кэш. Ну и наконец определяется адрес хоста (по системным настройкам DNS), его порт и устанавливается соединение с ним от своего имени. Далее устанавливается туннельное соединение, пассивно обеспечивая все методы http. Несколько иной алгоритм для метода CONNECT, необходимого всеми любимой ICQ, но тут тоже всё продумано и работает.
Реализация FTP по HTTP прокси.
Если HTTP запрос содержит ссылку на FTP ресурс прокси пытается установить FTP соединение. Если URL имеет вид 'ftp://name_user:password@host/resource',
прокси будет устанавливать соединение от имени name_user. В случает 'ftp://host/resource' устанавливается соединение от анонимного пользователя.
После установки соединения и авторизации на FTP-сервере UserGate анализирует тип ресурса (каталог/файл) открывает порт данных и запрашивает ресурс на этот порт. В случае если запрашиваемый ресурс- каталог, UserGate сам генерирует HTML страничку и отправляет клиенту, в противном случае ресурс считается как бинарный файл и передаётся клиенту без изменений.
После скачивания ресурса, оба соединения (команд и данных) закрываются.
Так как запрос осуществляется в протоколе HTTP, механизм авторизации тот же.
16.7 Группа 'FTP'
Если указать осмысленный номер порта этого сервиса (лучше 21- если он свободен) и установить галочку 'Разрешить FTP',
будет разрешён доступ по FTP протоколу, Если 0, то нет.
Для протокола FTP заложен свой механизм авторизации на firewall, и необходимо указать в клиенте соответствующий IP, порт, включить авторизацию на firewall и задать User ID и Password в соответствии с Логин и паролем пользователя на UserGate.
Типы указаний FTP-сервера UserGate понимает как: SITE site или OPEN site.
Реализация классического FTP прокси.
После соединения клиента с UserGate, последний отсылает приветствие и ожидает
авторизации. После приёма от клиента USER и PASS (авторизация на firewall), UserGate проверяет наличие такого пользователя, отправляет подтверждение авторизации и ожидает запрос к собстенно FTP-серверу в формате: SITE site или OPEN site. К сожалению не все клиенты FTP поддерживают такой механизм, но что-ж делать:
Далее прокси обеспечивать туннельный режим для любых команд с клиента на FTP-сервер и перехватывает только команду PORT. На эту команду прокси открывает свой сокет для приёма/передачи данных и подставляет его параметры в команду. Т.о. FTP-сервер видит открытый для него порт данных на доступном интерфейсе (с настоящим IP) и устанавливает соединение с ним. Обмен данных на этом порту шлюз осуществляет в туннельном режиме.
16.8 Группы 'SMTP и POP3'
Для этих протоколов UserGate может работать в качестве туннеля с соответствующими серверами, которые могут находиться как внутри локальной сети, так и в интернете.
Если указать в поле порт клиентов нулевые значение, протоколы поддерживаться не будут.
В противном случае можно настроить клиента SMTP/POP3 на работу через UserGate, указав в качестве почтовой машины IP и соответствующие порты прокси.
При установке чека 'Только как туннель' все пакеты будут проходить через UserGate, без какой-либо обработки и даже без анализа. Однако это может дать возможность получить интранет клиентам доступ к интернетовскому почтовому серверу.
Если установить чек 'Ограничить трафик', то доступ к почтовым серверам будет определяться общими ограничениями пользователя. В противном случае трафик хоть и будет учитываться на общих основаниях, ограничения для почтовых протоколов не будет.
Авторизация по SMTP
Для SMTP нет особых стандартных способов авторизации. Единственно, что можно придумать - смотреть почтовый адрес отправителя. Это и делает UserGate, читая поле 'MAIL FROM' из заголовка письма и делая поиск среди своих пользователей по почтовому адресу. Т.к. за одно соединение возможна передача нескольких писем на разные серверы, UserGate просматривает каждое письмо и определяет является ли почтовый сервер локальный. В зависимости от этого решается возможность отправки письма (ограничения по трафику) и расчёт трафика.
Авторизация по POP3
С протоколом POP3 проще, при соединении с сервером в протоколе заложена передача логина и пароля. Если Вы думаете, что эти значения должны совпадать с соответствующими атрибутами пользователя UserGate - будете абсолютно правы. Именно по этим полям находится пользователь UserGate и далее, для каждого принимаемого письма, определяется тип сервера POP3 (локальный/интернет) и рассчитывается трафик.
16.9 Группа 'Кэш'
UserGate имеет возможность кэширования проходящих через него ресурсов. Вообще групповое кэширование вещь чрезвычайно ответственная. Не стоит верить сообщениям, что где-то есть эффективный и достоверный кэш. Это взаимоисключающие требования. Вся проблема, что, несмотря на достаточную продуманность в HTTP1.1 вопросов кэширования, многие сервера (пока, пожалуй, большинство) не слишком заботятся о том, каким методом кэшировать свои ресурсы. В результате есть то, что есть на сегодняшний день: если алгоритмы группового кэширования выдержать в соответствии рекомендаций RFC, работа кэш будет абсолютно неэффективной. И именно поэтому в группе 'Кэш' так много чеков, позволяющих администратору самому подобрать наиболее эффективную пару эффективности/достоверности.
Время хранения
Косвенно управлять размером кэш можно, меняя этот параметр, определяющий, сколько нужно хранить ресурс в кэш с момента последнего обращения.
Размер кэш на диске
При превышении этого размера будут автоматически удаляться самые старые (к которым давно не было обращений) записи ресурсов из кэш.
Следует отметить, что в UserGate фоном постоянно исполняется утилита, следящая за целостностью данных в кэш и необходимость их хранения по этим параметрам. Для минимальной загрузки машины скорость обработки выбрана небольшой, примерно 10 файлов в секунду. Поэтому, например, для уменьшения размера кэш нужно уменьшить значение этих параметра и немного подождать. Через некоторое время размер кэша уменьшится.
Макс. длина ресурса
Если размер ресурса превышает максимально допустимый, он не помещается в кэш или будет удален в первую очередь.
Разрешить от локальных серверов
Локальные серверы обычно находятся в интранет сети и кэшировать их нет смысла, гарантируя этим достоверность данных от них.
Разрешить, содержащие cookie
Cookie информация в запросе обычно идентифицирует пользователя на web-сервере и групповое кэширование ресурсов по этому запросу не рекомендуется. Однако большинство серверов настолько полюбили использование cookie, что отказ от кэширования этих ресурсов существенно снижает эффективность кэширования.
Разрешить для GET с '?'
условные запросы также не рекомендуется кэшировать, но для увеличения эффективности можно немного рискнуть, включив эту опцию.
Кэш содержания каталогов FTP
файловые ресурсы FTP принципиально не кэшируются, ну а если предполагается частое использование одних и тех же FTP- серверов всеми пользователями, можно облегчить трафик и увеличить скорость отображения каталогов FTP, включив эту опцию.
Дочитывать в кэш после закрытия
Если пользователь, не дождавшись полной загрузки ресурса, отменяет загрузку (например, переходит по ссылке) недокаченный ресурс не помещается в кэш и при следующем обращении пользователя к этому же ресурсу, загрузка начинается с нуля. Включив эту опцию, UserGate будет докачивать ресурсы, и вернувшись, пользователь будет приятно удивлён мгновенным выводом всех картинок, которых он раньше и не видел. Правда статистически это скорее увеличит трафик.
16.10 Группа 'Расчёт трафика'
Для расчёта можно учитывать как входящий трафик, так и исходящий, установив соответствующие чеки - учитывать запросы, учитывать ответы. Обычно провайдеры предъявляют счёт только на входящий трафик, непонятно только как быть с SMTP почтовыми отправлениями, где имеется практически один исходящий трафик. В зависимости от этих установок считается суммарный трафик для пользователя- SumTraffic. По этому значению производится контроль по ограничениям для пользователя и расчёт оплаты.
Так как UserGate рассчитан в первую очередь на on-line пользователей, расчёт времени работы пользователя в интернет является не тривиальной задачей. В UserGate время рассчитывается как сумма времён отдельных сессий. Начало сессии считается время первого коннекта с нелокальным сервером, если сессия ещё не открыта. А для определения момента окончания сессии используется тайм-аут после дисконнекта последнего соединения пользователя. Время формирования тайм-аута указывается в поле Время простоя. По аналогичному алгоритму расчитывается время при старте программы на основании логов. По времени работы пользователя в интернет контролируются ограничения пользователя, и может производиться расчёт оплаты. Следует учесть, что для on-line клиентов время работы - относительное понятие, является оценочной характеристикой и в большой степени зависит от величины тайм-аута.
Оплата абонентов (пользователей) расчитывается по простой формулке:
dollars=(((double) SumTraffic/(1024*1024))* TarifMb) + (((double)Time/(60*60)) * TarifHours);
где:
SumTraffic- суммарный трафик пользователя
Time- времени работы пользователя в интернет, расчитанное по вышеприведённуму алгоритму.
TarifMb- помегабайтный тариф в поле Тариф за один Mb (у.е.)
TarifHours- почасовой тариф в поле Тариф за один час (у.е.)
Ну и наконец расчитывается оплата в национальной валюте по курсу, указанному в поле Курс этих у.е.
16.11 Группа 'Администратор'
В этой группе определяется информация о администраторе.
Полное имя, E-Mail - используются исключительно для подписи e-mail рассылок и определении переменных %ADMIN_NAME и %ADMIN_EMAIL при формировании письма.
Пароль - если в это поле введена строка, доступ на закладку 'Настройка' будет возможен только после введения пароля.
III. приложение.
А. Просмотр трафика по HTTP
Программа UserGate предоставляет пользователю самому просмотреть свои ограничения/запрещения, выполняя запрос по HTTP на специальные выделенные URL, которые обрабатываются самим UserGate. На эти URL UserGate сам формирует страницы, которые пользователь может увидеть стандартным Web-браузером.
Вот список этих URL:
http://usergate/Commands
список ссылок-команд, поддерживаемых UserGate.
Можно разместить этот линк на главной странице вашего локального Web-сервера, для упрощения доступа пользователя к командам UserGate.
http://usergate/Close
закрыть текущую сессию пользователя. Как выше отмечалось сессия закрывается автоматически по тайм-ауту, однако, использовав эту команду, пользователь может это сделать немедленно.
http://usergate/Properties
свойства пользователя. Пользователь может посмотреть свой профиль по всем ограничениям и запрещениям.
http://usergate/Statistics
краткая статистика. Будет показан трафик и расчёт оплаты с начала месяца и с начала дня.
http://usergate/StatDays
статистика по дням. Генерируется таблица с детализацией трафика пользователя по дням с начала месяца.
