Абвясціць бацькоўскі проксі ў Squid само па сабе не азначае, што кожны перасыланы запыт мусіць яго выкарыстоўваць. Калі прамы шлях парушае палітыку, задайце патрабаванне яўна і праверце недаступнасць бацькоўскага проксі.

Гэты прыклад для Squid 6.13 задае адзін бацькоўскі проксі і забараняе прамую перасылку да крыніцы для адной кліенцкай крыніцы:

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

Абодва адрасы — запаўняльнікі. Для кантраляванага upstream-тэсту, дзе дазволены публічныя бацькоўскія HTTP-проксі, выберыце адрас са спіса HTTP-проксі. Захавайце асобную палітыку http_access, што дапускае толькі патрэбных кліентаў. Правіла маршруту не дае кліенту права карыстацца проксі.

Праверце наяўныя правілы маршрутызацыі

no-query выключае ICP-запыты да гэтага вузла. Нуль — порт запытаў вузла, а не яго HTTP-слухач. Слухач для кліентаў і яго правілы доступу застаюцца асобнымі.

Перад даданнем блока праверце наяўныя налады always_direct і іншыя варыянты выбару вузлоў. Забараніць супадзенне ў always_direct само па сабе не патрабуе бацькоўскага проксі. Яўнае правіла never-direct выказвае гэтае патрабаванне для выбранага кліента.

Гэта кіруе транзакцыямі, якім патрэбная перасылка. Прыдатны запіс лакальнага кэша можна аддаць без сувязі з бацькоўскім проксі, таму адсутнасць новага злучэння з ім не абавязкова парушае маршрут.

Праверце маршрут і паводзіны пры збоі

Выкарыстоўвайце кантраляванае прызначэнне і супастаўляйце звесткі іерархіі з журнала доступу з назіраннямі прызначэння. Адзін выніковы статус HTTP не скажа, ці Squid выкарыстаў бацькоўскі проксі, ці прамы шлях.

У тэсце абслугоўвання зрабіце бацькоўскі проксі недаступным і паўтарыце той самы некэшаваны запыт. Калі палітыка забараняе прамую перасылку, транзакцыя мусіць завяршыцца няўдачай, а не трапіць да крыніцы іншым шляхам. Рабіце гэта толькі са службамі пад сваім кантролем і пасля тэсту аднавіце патрэбную канфігурацыю.

Падобныя артыкулы