Samo navođenje nadređenog proxyja u Squidu ne znači da ga svaki proslijeđeni zahtjev mora koristiti. Ako bi direktna putanja prekršila 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 direktno prosljeđivanje izvornom serveru 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 kontrolisani upstream test u kojem su javni HTTP nadređeni proxyji dopušteni odaberite adresu s liste 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šalac. Slušalac 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 uslov za odabranog klijenta.

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

Provjerite putanju i ponašanje pri kvaru

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

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

Povezani članci