Предположим, один домен партнёра должен использовать назначенный upstream-прокси, а остальные разрешённые запросы — обычного родителя. В Squid 7 именованные peer и cache_peer_access выражают эту политику:

cache_peer partner-proxy.example parent 3128 0 no-query name=partner_parent
cache_peer general-proxy.example parent 3128 0 no-query name=general_parent

acl partner_domain dstdomain .partner.example

cache_peer_access partner_parent allow partner_domain
cache_peer_access partner_parent deny all

cache_peer_access general_parent deny partner_domain
cache_peer_access general_parent allow all

never_direct allow all

Это фрагмент маршрутизации для существующего прямого прокси с контролем доступа. Если независимая проверка публичного назначения может использовать публичных родителей без аутентификации, выберите кандидатов из списка HTTP-прокси для тех адресов, где не настроены учётные данные родителя. Требуемый производственный маршрут партнёра остаётся отдельной договорённостью о доступе. Имена дают каждому родителю однозначную идентичность для его правил доступа.

Для совпадающего назначения подходящим остаётся только partner_parent. Для других назначений подходящим остаётся только general_parent. Первое совпадающее правило для каждого отдельного peer решает, подходит ли этот peer.

cache_peer_access фильтрует кандидатов; он не выстраивает все peer в резервную цепочку. Если оставить несколько подходящих, алгоритмы выбора peer в Squid выбирают среди них.

Строка never_direct делает использование родителя обязательным в этом примере. Если требуемого родителя нельзя использовать, прямое соединение не предлагается в качестве замены. Сохраните существующие разрешения клиента и назначения в http_access; эти правила решают, какие запросы допускаются до выбора upstream.

Эта конфигурация использует документированный интерфейс Squid 7. Справочник отмечает cache_peer_access как недоступный в Squid 8, поэтому при обслуживании этой настройки используйте документацию соответствующей развёрнутой версии.

Похожие статьи