Send Squid-anmodninger gennem en overordnet proxy

At angive en parent i Squid betyder ikke i sig selv, at hver videresendt anmodning skal bruge den. Hvis en direkte rute strider mod din politik, skal du konfigurere kravet eksplicit og teste, hvad der sker, når parenten er utilgængelig.

Dette eksempel til Squid 6.13 navngiver én parent og forbyder direkte videresendelse til oprindelsesserveren for én klientkilde:

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

Begge adresser er pladsholdere. Vælg til en kontrolleret upstreamtest, hvor offentlige HTTP-parents er tilladt, en adresse fra HTTP-proxylisten. Behold den separate http_access-politik, der kun tillader de ønskede klienter. Routningsreglen giver ikke en klient ret til at bruge proxyen.

Kontrollér eksisterende routningsregler

no-query slår ICP-forespørgsler til denne peer fra. Nullet er peerens forespørgselsport, ikke dens HTTP-lytter. Den klientvendte lytter og adgangsreglerne er stadig adskilt.

Gennemgå eksisterende always_direct-indstillinger og andre peervalg, før du tilføjer blokken. At nægte et match i always_direct kræver ikke i sig selv en parent. Den eksplicitte never-direct-regel udtrykker kravet for den valgte klient.

Dette styrer transaktioner, der skal videresendes. En brugbar lokal cachepost kan leveres uden kontakt til parenten, så fraværet af en ny parentforbindelse er ikke automatisk et brud på routningen.

Kontrollér ruten og fejladfærden

Brug en kontrolleret destination, og sammenhold adgangsloggens hierarkioplysninger med destinationens observationer. En endelig HTTP-status alene viser ikke, om Squid brugte parenten eller en direkte rute.

Gør parenten utilgængelig i en vedligeholdelsestest, og gentag samme ikke-cachede anmodning. Forbyder politikken direkte videresendelse, skal transaktionen fejle frem for at nå oprindelsen ad en anden rute. Gør det kun på tjenester, du kontrollerer, og gendan den ønskede konfiguration bagefter.