Combinare myportname e src di Squid con ACL separate

La configurazione sembra plausibile a prima vista:

acl team_a myportname 3128 src 198.51.100.0/24

Ma una definizione ACL ha un solo tipo. Qui myportname è il tipo; aggiungere la parola src non avvia un secondo controllo. Le parole restanti appartengono all’elenco dei valori del primo tipo. Quella riga non esprime «questo listener e questa rete client».

Dare un nome a ogni condizione

Usa un nome per il socket in ascolto e un ACL di origine separato. Questo estratto usa indirizzi di documentazione, che vanno sostituiti con indirizzi adatti al deployment:

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

Metti la regola di autorizzazione dopo le protezioni esistenti per porte di destinazione non sicure, destinazioni CONNECT limitate e accesso amministrativo. L’estratto illustra la condizione client/listener; non sostituisce quelle protezioni.

Le condizioni su una riga http_access si combinano con AND. Due righe di autorizzazione separate ammetterebbero ogni condizione in modo indipendente, cambiando molto la politica. Più valori dentro un ACL di solito offrono alternative per quell’unico controllo.

Scegliere l’uscita separatamente

Un listener corrispondente può essere usato anche da tcp_outgoing_address per scegliere un indirizzo sorgente locale. È una scelta di routing, non un permesso a usare il proxy. Una regola sull’indirizzo in uscita non può far passare una richiesta negata attraverso http_access.

Se una configurazione con più indirizzi smette di funzionare dopo un aggiornamento, separa le prove: un errore di analisi indica la sintassi della configurazione; un rifiuto di accesso indica la corrispondenza delle regole; una richiesta consentita con l’uscita sbagliata indica la scelta dell’uscita o un NAT successivo. Modificare tutte e tre le cose insieme rende un piccolo errore ACL molto più difficile da trovare.