Kombinera Squids myportname och src med separata ACL:er

Kombinera en namngiven Squid-lyssnare med ett tillåtet klientnätverk utan att sätta två ACL-typer i samma definition.

Konfigurationen verkar rimlig vid första anblicken:

acl team_a myportname 3128 src 198.51.100.0/24

Men en ACL-definition har bara en typ. Här är myportname typen; att lägga till ordet src startar inte ett andra test. De återstående orden tillhör värdelistan för den första typen. Den raden uttrycker inte ”den här lyssnaren och det här klientnätet”.

Ge varje villkor ett namn

Använd ett namn för den lyssnande socketen och en separat käll-ACL. Det här utdraget använder dokumentationsadresser, som måste bytas ut mot adresser som passar driftsättningen:

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

Placera tillåtelseregeln efter de befintliga skydden för osäkra målportar, begränsade CONNECT-mål och administrationsåtkomst. Utdraget illustrerar klient/lyssnar-villkoret; det ersätter inte dessa skydd.

Villkor på en http_access-rad kombineras med AND. Två separata tillåtelseregler skulle släppa igenom varje villkor oberoende, vilket skulle ändra policyn avsevärt. Flera värden i en ACL ger vanligtvis alternativ för det enda testet.

Välj utgången separat

En matchande lyssnare kan också användas av tcp_outgoing_address för att välja en lokal källadress. Det är vägval, inte tillstånd att använda proxyn. En regel för utgående adress kan inte få en nekad begäran att passera http_access.

Om en konfiguration med flera adresser slutar fungera efter en uppgradering, separera bevisen: ett tolkningsfel pekar på konfigurationssyntaxen; en åtkomstnekad begäran pekar på regelmatchen; en tillåten begäran med fel utgång pekar på utgångsvalet eller senare NAT. Att ändra alla tre samtidigt gör ett litet ACL-fel mycket svårare att hitta.

Relaterade artiklar