Sendu Squid-petojn tra gepatra prokurilo

Deklari gepatron en Squid ne per si mem signifas, ke ĉiu plusendata peto devas uzi ĝin. Se rekta vojo malobservus vian politikon, agordu tiun postulon eksplicite kaj testu, kio okazas kiam la gepatro ne disponeblas.

Por Squid 6.13, ĉi tiu ekzemplo nomas unu gepatron kaj malpermesas rektan plusendadon al la origino por unu klienta fonto:

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

Ambaŭ adresoj estas lokokupiloj. Por kontrolata suprenflua testo, kie publikaj HTTP-gepatroj estas permesitaj, elektu adreson el la listo de HTTP-prokuriloj. Konservu la apartan http_access-politikon, kiu permesas nur la celitajn klientojn. La enkursiga regulo ne rajtigas klienton uzi la prokurilon.

Kontrolu la ekzistantajn enkursigajn regulojn

no-query malŝaltas ICP-demandojn al ĉi tiu kunulo. La nulo estas la demanda pordo de la kunulo, ne ĝia HTTP-aŭskultanto. La klientflanka aŭskultanto kaj ĝiaj alirreguloj restas apartaj.

Reviziu ekzistantajn always_direct-agordojn kaj aliajn kunulelektojn antaŭ ol aldoni ĉi tiun blokon. Rifuzi kongruon en always_direct ne per si mem postulas gepatron. La eksplicita never-direct-regulo esprimas tiun postulon por la elektita kliento.

Tio regas transakciojn, kiuj bezonas plusendadon. Uzebla loka kaŝmemorero povas esti servata sen kontakti la gepatron; do foresto de nova gepatra konekto ne aŭtomate estas enkursiga malobservo.

Kontrolu la vojon kaj ĝian malsukceskonduton

Uzu kontrolatan celon kaj ekzamenu la hierarkiajn informojn de la alirprotokolo kune kun la observoj ĉe la celo. Sola fina HTTP-stato ne diras, ĉu Squid uzis la gepatron aŭ rektan vojon.

En prizorga testo maldisponebligu la gepatron kaj ripetu la saman nekaŝmemoritan peton. Se la politiko malpermesas rektan plusendadon, la transakcio devas malsukcesi anstataŭ atingi la originon per alia vojo. Faru tion nur ĉe servoj, kiujn vi regas, kaj restarigu la celitan agordon poste.