Konfigurationen ser umiddelbart plausibel ud:

acl team_a myportname 3128 src 198.51.100.0/24

Men en ACL-definition har én type. Her er myportname typen; tilføjelsen af ordet src starter ikke en anden test. De resterende ord hører til værdilisten for den første type. Den linje udtrykker ikke »denne lytter og dette klientnetværk«.

Giv hver betingelse et navn

Brug et navn til lytte-socketten og en separat kilde-ACL. Dette uddrag bruger dokumentationsadresser, som skal erstattes med adresser, der passer til udrulningen:

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

Placer tilladelsesreglen efter de eksisterende beskyttelser for usikre destinationsporte, begrænsede CONNECT-mål og administrationsadgang. Uddraget illustrerer klient/lytter-betingelsen; det erstatter ikke disse beskyttelser.

Betingelser på én http_access-linje kombineres med AND. To separate tilladelseslinjer ville tillade hver betingelse uafhængigt, hvilket ville ændre politikken betydeligt. Flere værdier i én ACL giver normalt alternativer til den enkelte test.

Vælg udgangen separat

En matchende lytter kan også bruges af tcp_outgoing_address til at vælge en lokal kildeadresse. Det er rutevalg, ikke tilladelse til at bruge proxyen. En regel for udgående adresse kan ikke få en afvist anmodning til at passere http_access.

Hvis en opsætning med flere adresser holder op med at virke efter en opgradering, skal du adskille beviserne: en parsefejl peger på konfigurationssyntaks; en adgangsafvisning peger på regelmatchning; en tilladt anmodning med den forkerte udgang peger på udgående valg eller senere NAT. At ændre alle tre på én gang gør en lille ACL-fejl meget sværere at finde.

Relaterede artikler