Combinarea myportname și src în Squid cu ACL-uri separate

Configurația pare plauzibilă la prima vedere:

acl team_a myportname 3128 src 198.51.100.0/24

Însă o definiție ACL are un singur tip. Aici myportname este tipul; adăugarea cuvântului src nu începe un al doilea test. Restul cuvintelor aparțin listei de valori a primului tip. Linia aceea nu exprimă „acest listener și această rețea de clienți”.

Dați un nume fiecărei condiții

Folosiți un nume pentru socketul de ascultare și un ACL de sursă separat. Acest fragment folosește adrese de documentație, care trebuie înlocuite cu adrese potrivite implementării:

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

Puneți regula de permitere după protecțiile existente pentru porturi de destinație nesigure, ținte CONNECT restricționate și acces administrativ. Fragmentul ilustrează condiția client/listener; nu înlocuiește acele protecții.

Condițiile de pe o linie http_access se combină cu AND. Două linii de permitere separate ar admite fiecare condiție independent, ceea ce ar schimba considerabil politica. Mai multe valori într-un ACL oferă de obicei alternative pentru acel singur test.

Alegeți ieșirea separat

Un listener potrivit poate fi folosit și de tcp_outgoing_address pentru a alege o adresă de sursă locală. Aceasta este selecție de rutare, nu permisiune de a folosi proxy-ul. O regulă de adresă de ieșire nu poate face o cerere respinsă să treacă prin http_access.

Dacă o configurație cu mai multe adrese încetează să funcționeze după o actualizare, separați dovezile: o eroare de analiză indică sintaxa configurației; o refuzare a accesului indică potrivirea regulilor; o cerere permisă cu ieșirea greșită indică selecția ieșirii sau un NAT ulterior. Schimbarea tuturor trei deodată face o mică greșeală de ACL mult mai greu de găsit.