Saada Squidi päringud ülemproksi kaudu

Pane Squid 6.13 kasutama tuntud kliendi edastatavatel päringutel ülemproksit ja väldi tahtmatut otsest varumarsruuti.

Ülemproksi deklareerimine Squidis ei tähenda iseenesest, et iga edastatav päring peab seda kasutama. Kui otsene tee rikuks sinu poliitikat, määra nõue selgesõnaliselt ja katseta ülemproksi kättesaamatust.

See Squid 6.13 näide nimetab ühe ülemproksi ja keelab otseedastuse lähtepunkti ühe kliendilähte jaoks:

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

Mõlemad aadressid on kohatäited. Hallatud upstream-katseks, kus avalikud HTTP-ülemproksid on lubatud, vali aadress HTTP-proksiloendist. Säilita eraldi http_access-poliitika, mis lubab ainult soovitud kliente. Marsruutimisreegel ei anna kliendile õigust proksit kasutada.

Kontrolli olemasolevaid marsruutimisreegleid

no-query keelab ICP-päringud sellele partnerile. Null on partneri päringuport, mitte HTTP-kuulaja. Kliendipoolne kuulaja ja selle ligipääsureeglid jäävad eraldi.

Vaata olemasolevad always_direct seaded ja teised partnerivalikud üle enne ploki lisamist. Vaste keelamine always_direct all ei nõua iseenesest ülemproksit. Selgesõnaline never-direct-reegel väljendab seda nõuet valitud kliendile.

See juhib edastamist vajavaid tehinguid. Kasutatava kohaliku vahemälukirje saab anda ülemproksit puudutamata, seega uue ülemproksiühenduse puudumine pole automaatselt marsruutimisrikkumine.

Kontrolli teed ja käitumist rikke korral

Kasuta hallatud sihtkohta ja võrdle ligipääsulogi hierarhiateavet sihtkoha vaatlustega. Ainult lõplik HTTP-staatus ei näita, kas Squid kasutas ülemproksit või otseteed.

Muuda ülemproksi hoolduskatses kättesaamatuks ja korda sama vahemällu salvestamata päringut. Kui poliitika keelab otseedastuse, peab tehing nurjuma, mitte jõudma lähtepunkti teist teed. Tee seda vaid enda hallatavatel teenustel ja taasta pärast soovitud seadistus.

Seotud artiklid