Wyślij każdego słuchacza Squid 7 do jego własnego nadrzędnego serwera proxy

W przypadku Squid 7 nazwij każdego przychodzącego słuchacza i określ, który rodzic może obsługiwać jego żądania:

http_port 3128 name=route_a
http_port 3129 name=route_b
acl via_a myportname route_a
acl via_b myportname route_b
cache_peer parent-a.example.net parent 8080 0 no-query name=parent_a
cache_peer parent-b.example.net parent 8080 0 no-query name=parent_b
cache_peer_access parent_a allow via_a
cache_peer_access parent_a deny all
cache_peer_access parent_b allow via_b
cache_peer_access parent_b deny all

Zachowaj uwierzytelniony dostęp klienta i wymagane konta nadrzędne skonfigurowane osobno. Ten fragment routingu wybiera kwalifikujących się partnerów; nie autoryzuje klientów ani nie udostępnia poświadczeń nadrzędnych. W przypadku testu dozwolonego miejsca docelowego publicznego bez skonfigurowanych poświadczeń nadrzędnego serwera proxy, lista serwerów proxy HTTP udostępnia kandydujące publiczne elementy równorzędne.

Zawężanie odpowiednich węzłów równorzędnych samo w sobie nie zabrania bezpośredniego przesyłania dalej. Jeśli te wyjścia są zabronione dla wybranych żądań, dodaj:

never_direct allow via_a
never_direct allow via_b

Przejrzyj wcześniej reguły always_direct i pełną konfigurację wyboru rodzica. Określ, czy niedostępny przypisany element nadrzędny musi spowodować niepowodzenie przekazywania lub czy istnieje inna jawnie zatwierdzona trasa. Kontrolowane żądanie przekazania i porównanie braku elementu nadrzędnego może sprawdzić wybrany wynik; sama udana strona może ukryć błędną odpowiedź zastępczą.

końcowy publiczny adres IP należy do ostatniego połączenia zewnętrznego. Dwóch różnych rodziców może dzielić wyjście NAT, więc sprawdź ten adres niezależnie od wyboru słuchacza i równorzędnego.

Użyj odnośnika równorzędnego, aby uzyskać szczegółowe informacje na temat uwierzytelniania/transportu. Te interfejsy dotyczą Squid 7 i wcześniejszych wersji wspierających; nie są one dostępne w niezmienionej formie w Squid 8.