Прокси-сервер является непрозрачным, или объявленным, когда пользователи знают о том, что они общаются через прокси-сервер, потому что они обращаются (на языке прокси-сервера: HTTP) к прокси-серверу.
Прозрачные прокси-сервера сами по себе не являются на самом деле типом прокси-сервера, скорее любой прокси-сервер является либо прозрачным, либо объявленным по проекту.
Кэширующие прокси-серверы
Кэширующие прокси-серверы, как указано в их названии, являются прокси-серверами, которые сконфигурированы на повторное использование кэшированных образов контента, когда это доступно и возможно. Когда кэшированная ранее часть контента недоступна, то производится ее выборка и использование в контенте, но также с попыткой ее кэширования.
Наиболее важным аспектом для кэширующих прокси-серверов является необходимость обеспечения того, что кэширующие прокси-серверы кэшируют только то, что на самом деле можно кэшировать. Динамический, регулярно изменяющийся контент не лучший выбор для кэширования, так как это может оказать воздействие на стабильность приложения, основанного на этом контенте. В случае HTTP-контента заголовки HTTP отображают возможность кэширования контента посредством указателей "cache".
В большинстве случаев пересылающие прокси-серверы конфигурируются также для работы в качестве кэширующих прокси-серверов. Это явление используется настолько часто, что компания IBM включила это в название компонента своего Edge Server: IBM Caching Proxy.
Прокси-сервер обеспечения безопасности
В качестве необходимой для простых прокси-серверов функциональности прокси-серверы могут быть сконфигурированы для приведения в исполнение политик безопасности. Такие прокси-серверы обеспечения безопасности могут обрабатывать (либо выступать в качестве посредников при обработке) запросы аутентификации и авторизации. В этих случаях аутентификация пользователя клиента и авторизация клиента для доступа к определенному контенту контролируется самим прокси-сервером. Далее мандат безопасности посылается от прокси-сервера к конечным серверам с запросом, а конечный сервер должен быть сконфигурирован на оказание доверия предоставляемому прокси-серверу мандату.
Существует много различных продуктов и предложений, а также множество топологий на выбор, но с точки зрения выполнения прокси-функций безопасность является дополнительной функцией, которую может выполнять прокси-сервер.
В большинстве случаев функциональные возможности по обеспечению безопасности могут быть добавлены стандартному прокси-серверу в виде дополнительного программного модуля (плагина, от англ.- plug-in) (к примеру, IBM Tivoli WebSeal Plug-In для IBM WebSphere Edge Server). Существуют также и отдельные продукты, такие, как IBM Tivoli Access Manager for e-Business, которые служат только в качестве прокси-сервера обеспечения безопасности.
Обратные прокси-серверы имеют много общего кода с пересылающими прокси-серверами: фактически одни и те же продукты могут быть сконфигурированы одним или другим образом либо двумя сразу. Однако с функциональной и практической точки зрения в нашем случае мы рассматриваем обратные прокси-серверы как полностью другой инструмент.
Обратные прокси-серверы прозрачны, отчасти по определению. За обратным прокси-сервером пользователь вообще не знает о своем общении с прокси-сервером. Пользователь полагает, что общается с реальным предметом – сервером, на котором находится контент.
Обратные прокси-серверы обычно избраны и реализованы в целях обеспечения изоляции контента и зон. Однако, вы можете также добавить в обратные прокси-серверы функциональные возможности по кэшированию для обеспечения производительности заодно с преимуществами обеспечения безопасности.
Нужно обратить внимание, что при этом виде сценария выигрыш в производительности за счет кэширования относится к производительности сети, так как обычно обратный прокси-сервер расположен близко к конечному серверу. Важным мотивом кэширования с помощью обратного прокси-сервера является разгрузка от подачи статического, кэшируемого контента от конечных серверов приложений. Это позволит зачастую более дорогим конечным серверам приложений немного освободиться и сфокусировать свое внимание на пропускных способностях своих процессоров при выполнении более сложных динамических задач и задач, связанных с транзакциями.
Однако когда на обратном прокси-сервере разрешено кэширование, важным становится обеспечение его должной защиты. Весь контент, даже если он полностью статичен, продолжает нуждаться в защите.
1.6 Прокси-сервер Squid
Squid — программный пакет, реализующий функцию кэширующего прокси-сервера для протоколов HTTP, FTP, Gopher и (в случае соответствующих настроек) HTTPS. Разработан сообществом как программа с открытым исходным кодом (распространяется в соответствии с GNU GPL). Все запросы выполняет как один неблокируемый процесс ввода/вывода. Используется в UNIX-like системах и в ОС семейства Windows NT. Имеет возможность взаимодействия с Active Directory Windows Server путём аутентификации через LDAP, что позволяет использовать разграничения доступа к интернет ресурсам пользователей, которые имеют учётные записи на Windows Server, также позволяет организовать «нарезку» интернет трафика для различных пользователей.
В сочетании с некоторыми межсетевыми экранами и маршрутизаторами Squid может работать в режиме прозрачного прокси-сервера. В этом режиме маршрутизатор вместо того, чтобы сразу пересылать http-запросы пользователя http-серверу в интернете, перенаправляет их прокси-серверу, который может работать как на отдельном хосте, так и на самом маршрутизаторе. Прокси-сервер обрабатывает запрос (с возможной отдачей содержимого из кэша), это содержимое направляется к запросившему пользователю, для которого оно выглядит как «ответ» сервера, к которому адресовался запрос. Таким образом, пользователь может даже не знать, что все запросы и ответы прошли через прокси-сервер.
Сервер Squid развивается в течение уже многих лет. Обеспечивает совместимость с большинством важнейших протоколов Интернета, а также с операционными системами:
GNU/Linux
FreeBSD
OpenBSD
NetBSD
BSDI
Mac OS X
OSF и Digital Unix
IRIX
SunOS/Solaris
NeXTStep
SCO Unix
AIX
HP-UX
Microsoft Windows
Описаниеархитектуры
Для контроля доступа к ресурсам и определения ряда действий используются списки контроля доступа (англ. access control list, acl). Каждый ACL может состоять из нескольких критериев (но только одного типа):
адрес (сеть) источника запроса, цели запроса
имя (доменное имя) источника запроса, имя цели запроса
части URL запроса
протокол
порт (получателя, отправителя, самого Squid’а)
метод (PUT или GET) при передаче данных по HTTP
браузер (User-agent)
ident (запрос к рабочей станции)
номер автономной системы отправителя/получателя (не для всех случаев)
авторизация на прокси-сервере
номер соединения (чаще всего используется для ограничения количества соединений)
SNMP
сертификаты пользователя
параметры запроса
внешние обработчики
Squid поддерживает несколько видов идентификации пользователей:
по IP-адресу (или доменному имени узла)
по переданным реквизитам (логин/пароль)
по идентификатору пользовательского агента (браузера)
Для идентификации по логину/паролю возможно использовать:
обычные логин/пароль
NTLM-авторизацию
внешние программы авторизации (определяющие формат авторизации)
Squid имеет возможность переписывать запрашиваемые URL. Squid может быть сконфигурирован так, чтобы пропускать входящие URL через процесс редиректора выполняемого как внешний процесс (подобно dnsserver), который возвращает новый URL или пустую строку, обозначающую отсутствие изменений.
Редиректор – не является стандартной частью пакета Squid. Редиректор предоставляет администратору контроль за передвижениями пользователей. Использование редиректора в сочетании с прозрачным проксированием дает простой, но эффективный контроль, над доступом к порно. Программа-редиректор должна читать URL (один на строку) со стандартного входа и записывать измененные URL или пустые строки на стандартный выход. Нужно заметить, что программа-редиректор не может использовать буферизированный I/O. Squid дописывает дополнительную информацию после URL, которую редиректор может использовать для принятия решения.
SAMS (SQUID Account Management System) - программное средство для администрирования доступа пользователей к прокси-серверу Squid.
На данный момент SAMS настраивает работу редиректоров:
Редиректор SAMS - редиректор, работающий напрямую с базами SAMS
SquidGuard - очень мощный редиректор.
Стандартный SQUID - простейший редиректор, описанный в документации к SQUID.
Написан специально для SAMS, напрямую использует информацию, содержащуюся в базе данных. Позволяет включить различное перенапраление запросов для пользователей (регулируется шаблонами пользователей).
Редиректор SAMS обеспечивает:
ограничение доступа пользователей к SQUID
контроль времени доступа пользователей к SQUID
ограниечение доступа пользователей к запрещенным ресурсам (или доступ пользователей только к разрешенным ресурсам)
перенаправление запросов пользователей к баннерам, счетчикам и т.п.