Прочитайте эту политику вслух: разрешите офисной сети использовать прокси для одобренного назначения. Если эти условия относятся друг к другу, держите их вместе в правиле.

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. Рассмотрите четыре случая: одобренный клиент к одобренному назначению, одобренный клиент в другое место, другой клиент к одобренному назначению и другой клиент в другое место. Если правила разрешают больше случаев, чем задумано политикой, исправьте логику, прежде чем расширять слушатель. Синтаксически правильная конфигурация всё равно может выражать неверные разрешения.

Похожие статьи