Съчетаване на 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 грешка много по-трудна за откриване.