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

http_access allow office_clients approved_destination

Каб гэты радок дазволіў запыт, павінны супасці абодва ACL. Калі яго падзяліць, палітыка зменіцца:

http_access allow office_clients
http_access allow approved_destination

Цяпер офісным кліентам можна дазволіць без абмежавання па прызначэнні, а запытам да гэтага прызначэння — без офіснага абмежавання, калі папярэдняе правіла іх не адхіліла. Два радкі — не больш чытэльнае напісанне аднаго радка.

Парадак — частка палітыкі

Squid ацэньвае правілы доступу паслядоўна. Першае супадаючае рашэнне кіруе запытам. Папярэдні allow all зводзіць на нішто пазнейшае асцярожнае абмежаванне; папярэдняя супадаючая адмова перашкаджае дайсці да пазнейшага дазволу.

Дакументацыя http_access тлумачыць гэтую паслядоўнасць. Трымайце наўмысную канчатковую адмову, а не спадзявайцеся, што чытач запомніць неявныя паводзіны па змаўчанні.

Многія вызначэнні ACL маюць іншую сувязь OR: адзін названы ACL крыніцы можа пералічваць некалькі дазволеных дыяпазонаў. Гэта не робіць крыніцу і прызначэнне адным тыпам ACL. Вызначце іх асобна, затым аб'яднайце імёны ў рашэнні аб доступе.

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

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