Samo navođenje nadređenog proxyja u Squidu ne znači da ga svaki proslijeđeni zahtjev mora koristiti. Ako bi izravni put prekršio politiku, izričito postavite taj zahtjev i testirajte nedostupnost nadređenog proxyja.

Ovaj primjer za Squid 6.13 imenuje jednog nadređenog proxyja i zabranjuje izravno prosljeđivanje izvornom poslužitelju za jedan klijentski izvor:

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

Obje adrese su zamjenske. Za kontrolirani upstream test u kojem su javni HTTP nadređeni proxyji dopušteni odaberite adresu s popisa HTTP proxyja. Zadržite zasebnu politiku http_access koja dopušta samo predviđene klijente. Pravilo usmjeravanja ne daje klijentu pravo korištenja proxyja.

Provjerite postojeća pravila usmjeravanja

no-query isključuje ICP upite ovom peeru. Nula je njegov port za upite, a ne HTTP slušatelj. Slušatelj prema klijentima i njegova pravila pristupa ostaju zasebni.

Prije dodavanja bloka pregledajte postojeće postavke always_direct i druge odabire peerova. Odbijanje podudaranja u always_direct samo po sebi ne zahtijeva nadređeni proxy. Izričito pravilo never-direct postavlja taj uvjet za odabranog klijenta.

Ovo upravlja transakcijama koje treba proslijediti. Upotrebljiv zapis lokalne predmemorije može se poslužiti bez kontakta s nadređenim proxyjem, pa odsutnost nove veze s njim nije automatski kršenje usmjeravanja.

Provjerite put i ponašanje pri kvaru

Koristite kontrolirano odredište i usporedite hijerarhijske podatke dnevnika pristupa s opažanjima odredišta. Sam konačni HTTP status ne govori je li Squid koristio nadređeni proxy ili izravni put.

U testu održavanja učinite nadređeni proxy nedostupnim i ponovite isti nepredmemorirani zahtjev. Ako politika zabranjuje izravno prosljeđivanje, transakcija treba propasti, a ne stići do izvora drugim putem. Radite to samo na uslugama pod svojom kontrolom i zatim vratite predviđenu konfiguraciju.

Povezani članci