Kombineer Squid se myportname en src met afsonderlike ACL's

Die konfigurasie lyk met die eerste oogopslag aanneemlik:

acl team_a myportname 3128 src 198.51.100.0/24

Maar ’n ACL-definisie het een tipe. Hier is myportname die tipe; die byvoeging van die woord src begin nie ’n tweede toets nie. Die oorblywende woorde hoort by die waardelys van die eerste tipe. Daardie reël druk nie “hierdie luisteraar en hierdie kliëntnetwerk” uit nie.

Gee elke voorwaarde ’n naam

Gebruik ’n naam vir die luistersok en ’n aparte bron-ACL. Hierdie uittreksel gebruik dokumentasie-adresse, wat deur adresse geskik vir die ontplooiing vervang moet word:

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

Plaas die toelaatreël ná die bestaande beskermings vir onveilige bestemmingspoorte, beperkte CONNECT-teikens en bestuurstoegang. Die uittreksel illustreer die kliënt/luisteraar-voorwaarde; dit vervang nie daardie beskermings nie.

Voorwaardes op een http_access-reël word met AND gekombineer. Twee afsonderlike toelaatreëls sou elkeen van die voorwaardes onafhanklik toelaat, wat die beleid aansienlik sou verander. Verskeie waardes binne een ACL bied gewoonlik alternatiewe vir daardie enkele toets.

Kies die uitgang afsonderlik

’n Passende luisteraar kan ook deur tcp_outgoing_address gebruik word om ’n plaaslike bronadres te kies. Dit is roeteseleksie, nie toestemming om die proxy te gebruik nie. ’n Uitgaande-adresreël kan nie ’n geweierde versoek deur http_access laat slaag nie.

As ’n multi-adres-konfigurasie ná ’n opgradering ophou werk, skei die bewyse: ’n parseerfout dui op konfigurasiesintaksis; ’n toegangsweiering dui op reëlpassing; ’n toegelate versoek met die verkeerde uitgang dui op uitgaande seleksie of latere NAT. Om al drie gelyktydig te verander maak ’n klein ACL-fout baie moeiliker om te vind.