Wysyłanie żądań Squid przez nadrzędne proxy

Zadeklarowanie rodzica w Squid samo w sobie nie oznacza, że każde przekazywane żądanie musi go użyć. Jeśli bezpośrednia trasa narusza politykę, ustaw ten wymóg jawnie i przetestuj niedostępność rodzica.

Ten przykład dla Squid 6.13 wskazuje jednego rodzica i zabrania bezpośredniego przekazywania do źródła dla jednego źródła klienta:

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

Oba adresy są zastępcze. Do kontrolowanego testu upstream, w którym wolno używać publicznych rodziców HTTP, wybierz adres z listy proxy HTTP. Zachowaj oddzielną politykę http_access, dopuszczającą tylko zamierzonych klientów. Reguła trasowania nie upoważnia klienta do korzystania z proxy.

Sprawdź istniejące reguły trasowania

no-query wyłącza zapytania ICP do tego peera. Zero to jego port zapytań, a nie nasłuch HTTP. Nasłuch dla klientów i jego reguły dostępu pozostają osobne.

Przed dodaniem bloku przejrzyj obecne ustawienia always_direct i inne wybory peerów. Odrzucenie dopasowania w always_direct samo nie wymaga rodzica. Jawna reguła never-direct wyraża ten wymóg dla wybranego klienta.

Dotyczy to transakcji wymagających przekazania. Użyteczny wpis lokalnej pamięci podręcznej można obsłużyć bez kontaktu z rodzicem, więc brak nowego połączenia z nim nie jest automatycznie naruszeniem trasy.

Sprawdź trasę i zachowanie przy awarii

Użyj kontrolowanego celu i zestaw informacje hierarchii z dziennika dostępu z obserwacjami celu. Sam końcowy status HTTP nie mówi, czy Squid użył rodzica, czy trasy bezpośredniej.

W teście serwisowym uczyń rodzica niedostępnym i ponów to samo żądanie nieobecne w cache. Jeśli polityka zabrania bezpośredniego przekazywania, transakcja powinna się nie udać zamiast dotrzeć do źródła inną trasą. Rób to wyłącznie na kontrolowanych usługach i przywróć potem zamierzoną konfigurację.