Объединение myportname и src в Squid с помощью отдельных ACL

Конфигурация на первый взгляд выглядит правдоподобно:

acl team_a myportname 3128 src 198.51.100.0/24

Но определение ACL имеет только один тип. Здесь myportname — это тип; добавление слова src не запускает вторую проверку. Остальные слова относятся к списку значений первого типа. Эта строка не выражает «этот listener и эта клиентская сеть».

Дайте имя каждому условию

Используйте имя для слушающего сокета и отдельный ACL источника. В этом фрагменте используются документационные адреса, которые нужно заменить на подходящие для развёртывания:

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

Разместите правило разрешения после существующих защит для небезопасных портов назначения, ограниченных целей CONNECT и административного доступа. Фрагмент показывает условие клиента/listener; он не заменяет эти защиты.

Условия в одной строке http_access объединяются через AND. Две отдельные строки разрешения пропускали бы любое условие независимо, что заметно изменило бы политику. Несколько значений внутри одного ACL обычно дают альтернативы для этой единственной проверки.

Выбирайте выход отдельно

Подходящий listener можно также использовать через tcp_outgoing_address, чтобы выбрать локальный адрес источника. Это выбор маршрутизации, а не разрешение пользоваться прокси. Правило адреса выхода не может пропустить отклонённый запрос через http_access.

Если конфигурация с несколькими адресами перестаёт работать после обновления, разделите доказательства: ошибка разбора указывает на синтаксис конфигурации; отказ в доступе — на совпадение правил; разрешённый запрос с неверным выходом — на выбор выхода или последующий NAT. Изменение всех трёх сразу делает небольшую ошибку ACL гораздо труднее находимой.