Редирект со Squid на другой прокси-сервер

Родительские прокси сервера

Иногда, например, имея в компании несколько региональных офисов, встает необходимость доступа к определенным ресурсам (сайтам, сервисам и т.п.) из определенной страны. Имея в каждом регионе прокси-сервер Squid это легко реализовать.

Мы будем использовать тэг cache_peer. Формат его записи такой:

cache_peer hostname type http-port icp-port [options]

type:

parent – родительский
sibling – соседский
multicast – мультикаст

proxy-port: номер порта на котором прокси будет слушать запросы клиентов, обычно 8080 или 3128.

icp-port: номер порта на котором прокси будет слушать ICP запросы от других прокси (у Squid по-умолчанию 3130, если указать параметр в конфиге icp_port 3130).

Опции:

proxy-only

определяет, что объекты, которые берутся из этого кэша, не будут сохранятся локально.

weight=n

позволяет установить приоритет использования прокси при прочих равных условиях(например, при использовании sibling(равных) прокси). Не имеет эффекта при отношениях parent-sibling. Опция может принимать любое число начиная с 1. По умолчанию, ставится 1.

ttl=n

позволяет определить TTL(Time-To-Live) в ICP пакетах при использовании multicast. Полезно только в случае рассылки запросов к к группе multicast. Поскольку, мы не принимаем ICP ответы от случайных хостов, вы должны настроить остальные прокси группы (multicast группы) используя опцию multicast-responder.

no-query

используется для запрета отправки ICP запросов к этому соседскому прокси. Только принимать их.

default

использовать этот прокси по умолчанию.

round-robin

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

carp

для определения множества родительских кэшей, которые будут использваться в массиве CARP. CARP представляет собой механизм для распределения нагрузки между родительскими прокси согласно их приоритету(weight).

multicast-responder

определяет принадлежность этого прокси к группе multicast.

closest-only

определяет, что при ответах ICP_OP_MISS, мы будем отправлять ответ CLOSEST_PARENT_MISS и никогда FIRST_PARENT_MISS.

no-digest

определяет, что от этого прокси не запрашивать cache digest.

no-netdb-exchange

отключает запросы к ICMP RTT базе данных (NetDB) от соседского прокси.

no-delay

используется для запрета доступа к этому соседскому прокси при перезагрузке delay pools.

login=user:password

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

Примечание: Строка может содержать URL символы-исключения. (например, %20 для обозначения пробела) Этот также значит, что для использования знака % нужно писать %%.

login=PASS

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

Примечание: Для комбинирования этой опции с локальной аутентификацией, необходимо использовать Basic схему и оба сервера должны иметь одинаковую базу данных пользователей. Такой подход позволяет авторизоваться один раз, вместо двух(один раз на прокси, второй раз на самом сервере). Используйте с осторожностью.

login=*:password

используйте для аутентификации пользователей с разными именами, но одним и тем же паролем. Это может быть необходимо для организации доступа пользователям из другого домена. При этом необходимо идентифицировать пользователей. Значок *(звездочка) может использоваться дополнительно. Например, для добавления некоторой информации, которая будет добавлятся к username.

connect-timeout=nn

используется для определения таймаута соединения(также смотри peer_connect_timeout).

digest-url=url

сообщает Squid взять cache_digest(если digest включен) для этого хоста, с некоторого URL, вместо его обычного расположения.

allow-miss

сообщает Squid, принимать TCP_MISS(отсутсвие в кэше) от sibling(равных, братских) кэшей.

max-conn=n

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

htcp

определяет использование HTCP вместо ICP запросов к соседскому кэшу. Тогда вы должны разрешить Squid использование htcp_access.

htcp-oldsquid

определяет использование HTCP для старых версий Squid. Тогда вы должны разрешить Squid использование htcp_access.

originserver

определяет, что этот родительский прокси используется для выхода в Интернет.

userhash

используется для баланса нагрузки множества родительских прокси. Правила для баланса основываются на клиентском proxy_auth или ident username.

sourcehash

используется для баланса нагрузки множества родительских прокси. Правила для баланса основываются на IP адресе клиента.

name=xxx

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

monitorurl=url

используется для мониторинга состояния соседского прокси. Действует следующим образом: посылает запрос на заданный URL и ждет ответа. Если ответ пришел – прокси “жив”, иначе – нет. По умолчанию, none.

monitorsize=min[-max]

используется для ограничения размера тела ответа полученного от monitorurl. По умолчанию – 0(без ограничения на размер).

monitorinterval=seconds

используется для установки частоты мониторинга. По умолчанию 300 секунд. Если установить значение 0, то мониторинг будет выключен.

monitortimeout=seconds

используется для установки таймаута ‘monitorurl’. По умолчанию, равно значению ‘monitorinterval’.

forceddomain=name

используется для принудительной вставки Host заголовка в запросы направленные к этому прокси. Полезно, если Squid в режиме accelerator.

ssl

определяет то, что подключения к этому прокси должны быть шифрованы по SSL/TLS.

sslcert=/path/to/ssl/certificate

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

sslkey=/path/to/ssl/key

определяет частный SSL ключ для sslcert. Если ‘sslkey’ не установлен, тогда файл, указанный в sslcert должен содержать и ключ и сертификат.

используйте sslversion=1|2|3|4 для определения версии SSL протокола:

1 = automatic (по умолчанию)
2 = SSL v2 only
3 = SSL v3 only
4 = TLS v1 only

sslcipher=…

определяет список корректных SSL шифров, используемых для подключения к этому прокси.

ssloptions=…

определяет используемый SSL движок:

NO_SSLv2 Запрещает использовать SSLv2
NO_SSLv3 Запрещает использовать SSLv3
NO_TLSv1 Запрещает использовать TLSv1

Смотри src/ssl_support.c или документацию по OpenSSL для более подробной информации.

sslcafile=…

используется для определения файла содержащего CA сертификаты.

sslcapath=…

определяет каталог, который содержит CA сертификаты.

sslcrlfile=…

определяет список аннулированных сертификатов.

sslflags=…

определяет различные флаги SSL:

DONT_VERIFY_PEER Принимать сертификаты, даже если они не проверены.

NO_DEFAULT_CA Не использовать список CA по умолчанию, встроенный в OpenSSL.

ssldomain=

используется для указания имени прокси в сертификате. Необходимо для проверки на корректность полученного сертификата. Если не указано, то используется hostname прокси.

front-end-https

используется для включения заголовка “Front-End-Https: On” необходимый при использовании Squid как SSL представителя(фронтенда) в Microsoft OWA. Смотри MS KB документ Q307347 для подробностей об этом заголовке.

connection-auth=off

сообщает Squid, что этот прокси не поддерживает Microsoft ориентированные подключения для аутентификации. По умолчанию, auto, для автоматического определения статуса прокси.


Потом мы будем использовать тэги cache_peer_access и never_direct

cache_peer_access cache-host allow|deny [!]aclname ...

Синтаксис использования подобен http_access.

never_direct allow|deny [!]aclname ...

Этот тэг позволяет определить какие(чьи) запросы, НИКОГДА НЕ БУДУТ идти напрямую в Интернет. В качестве параметров тэга используются списки ACL.

never_direct является противоположностью always_direct.

Примеры

Дано:

Наш текущий прокси-сервер: firstproxy.company.ru
Удаленный прокси-сервер: secondproxy.company.ru

Пример 1

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

# Определяем прокси, через который нам необходимо выйти
cache_peer secondproxy.company.ru parent 3128 0 no-query no-digest default
# Создаем acl с названием domains в котором указываем домены сайтов, которые должны открываться через secondproxy.company.ru
acl domains dstdomain site1.com site2.com site3.com
# Разрешаем доступ acl через наш указанный прокси
cache_peer_access secondproxy.company.ru allow domains
# Запрещаем acl'у ходить через наш текущий прокси
never_direct allow domains

Пример 2

Когда нужно открыть сайт используя другой прокси-сервер (не Squid) с авторизацией.

# Определяем прокси, через который нам необходимо выйти
cache_peer secondproxy.company.ru parent 3128 0 no-query no-digest default login=user:password
# Создаем acl с названием domains в котором указываем домены сайтов, которые должны открываться через secondproxy.company.ru
acl domains dstdomain site1.com site2.com site3.com
# Разрешаем доступ acl через наш указанный прокси
cache_peer_access secondproxy.company.ru allow domains
# Запрещаем acl'у ходить через наш текущий прокси
never_direct allow domains

Пример 3

Если удаленный прокси Squid, тогда можно использовать кэш, укажем порт ICP

# Определяем прокси, через который нам необходимо выйти
cache_peer secondproxy.company.ru parent 3128 3130
# Создаем acl с названием domains в котором указываем домены сайтов, которые должны открываться через secondproxy.company.ru
acl domains dstdomain site1.com site2.com site3.com
# Разрешаем доступ acl через наш указанный прокси
cache_peer_access secondproxy.company.ru allow domains
# Запрещаем acl'у ходить через наш текущий прокси
never_direct allow domains

Пример 4

И еще один пример, когда на удаленном прокси-сервере работает NTLM авторизация. Проблема состоит в том, что мне не удалось заставить работать опцию login с указанием домена и логина пользователя. Я сделал проще. Создал acl на удаленном прокси, в котором указал IP адрес нашего прокси, с которого будут направляться запросы и разрешил ему все. Это правило выставил выше всех остальных (где правила, использующие авториазцию или требующие авторизацию).

acl trustedproxy src 192.168.1.1
http_access allow trustedproxy

А на нашем прокси уже не указывал опцию login. Конфиг, как в Примере 1.

Пример 5

И еще один пример конфигурации, для структуры на иллюстрации к этой статье. В данном случае главный прокси-сервер принимает подключения на трех портах: 3127, 3128, 3129. Далее отправляет обратившихся на другой прокси, в зависимости от того, к какому порту обратились. Сам главный прокси никого не пускает в Интернет.

# Прописываем ACL для портов
acl port1 localport 3127
acl port2 localport 3128
acl port3 localport 3129
# Слушаем порты
http_port 3128
http_port 3129
http_port 3130
# Описываем удаленные прокси-сервера
cache_peer p1.example.com parent 3128 0 name=proxy1
cache_peer p2.example.com parent 3128 0 name=proxy2
cache_peer p3.example.com parent 3128 0 name=proxy3
# Разрешаем
cache_peer_access proxy1 allow port1
cache_peer_access proxy2 allow port2
cache_peer_access proxy3 allow port3
# Запрещаем главной проксе выпускать в Интернет
never_direct allow all

Можно, конечно, принимать на главной проксе на один порт и разруливать трафик, в зависимости от потребностей… но это уже отдельная история 🙂


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Unlix © Все права защищены 2023

Копирование материалов с сайта Unlix.ru без указания полной ссылки на источник ЗАПРЕЩЕНО!