Маршрутизація одного домену призначення на іншого батьківського Squid 7

Припустімо, що один домен партнера має використовувати призначений 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, тому під час обслуговування цього налаштування використовуйте документацію відповідної розгорнутої версії.