Posílání požadavků Squid přes nadřazenou proxy

Přimějte Squid 6.13 používat rodiče pro předávané požadavky známého klienta a zabraňte nechtěnému přímému náhradnímu spojení.

Deklarace rodiče v Squid sama neznamená, že jej musí použít každý předávaný požadavek. Pokud by přímá cesta porušovala vaši politiku, nastavte požadavek výslovně a otestujte nedostupnost rodiče.

Tento příklad pro Squid 6.13 pojmenuje jednoho rodiče a zakáže přímé předávání k původu pro jeden klientský zdroj:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

Obě adresy jsou zástupné. Pro řízený upstream test, kde jsou veřejní HTTP rodiče povoleni, vyberte adresu ze seznamu HTTP proxy. Zachovejte samostatnou politiku http_access, která povoluje jen zamýšlené klienty. Směrovací pravidlo nedává klientovi oprávnění používat proxy.

Zkontrolujte existující směrovací pravidla

no-query vypne ICP dotazy na tento protějšek. Nula je jeho dotazovací port, ne HTTP posluchač. Posluchač pro klienty a jeho přístupová pravidla zůstávají samostatné.

Před přidáním bloku prověřte stávající nastavení always_direct a další výběry protějšků. Odmítnutí shody v always_direct samo o sobě rodiče nevyžaduje. Výslovné pravidlo never-direct tento požadavek stanoví pro vybraného klienta.

To řídí transakce vyžadující předání. Použitelnou položku místní cache lze obsloužit bez kontaktu s rodičem, takže chybějící nové spojení s rodičem není automaticky porušením směrování.

Zkontrolujte cestu a chování při selhání

Použijte řízený cíl a porovnejte hierarchické informace přístupového logu s pozorováním cíle. Samotný konečný stav HTTP neříká, zda Squid použil rodiče, nebo přímou cestu.

V údržbovém testu znepřístupněte rodiče a opakujte stejný necachovaný požadavek. Pokud politika zakazuje přímé předávání, transakce má selhat, ne dosáhnout původu jinou cestou. Dělejte to jen na službách pod vaší kontrolou a poté obnovte zamýšlenou konfiguraci.

Související články