Kierowanie jednej domeny docelowej do innego rodzica Squid 7

Załóżmy, że jedna domena partnerska musi używać wyznaczonego proxy upstream, a inne dozwolone żądania korzystają ze zwykłego rodzica. W Squid 7 nazwane peery i cache_peer_access wyrażają tę politykę:

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

To fragment routingu dla istniejącego proxy forward z kontrolą dostępu. Jeśli niezależny test publicznego celu może używać publicznych rodziców bez uwierzytelniania, wybierz kandydatów z listy proxy HTTP dla tych adresów, dla których nie skonfigurowano danych logowania rodzica. Wymagana trasa produkcyjna partnera pozostaje odrębnym ustaleniem dostępu. Nazwy nadają każdemu rodzicowi jednoznaczną tożsamość dla jego reguł dostępu.

Dla pasującego celu kwalifikuje się tylko partner_parent. Dla innych celów kwalifikuje się tylko general_parent. Pierwsza pasująca reguła dla każdego pojedynczego peera decyduje, czy ten peer się kwalifikuje.

cache_peer_access filtruje kandydatów; nie układa wszystkich peerów w łańcuch zapasowy. Jeśli pozostawisz kilka kwalifikujących się, algorytmy wyboru peera Squida wybierają spośród nich.

Wiersz never_direct czyni użycie rodzica obowiązkowym w tym przykładzie. Jeśli wymagany rodzic nie może być użyty, połączenie bezpośrednie nie jest oferowane jako zamiennik. Zachowaj istniejące uprawnienia klienta i celu w http_access; te reguły decydują, które żądania są dopuszczane przed wyborem upstream.

Ta konfiguracja używa udokumentowanego interfejsu Squid 7. Dokumentacja oznacza cache_peer_access jako niedostępne w Squid 8, więc przy utrzymaniu tego ustawienia korzystaj z dokumentacji odpowiedniej wdrożonej wersji.