Squid-en myportname eta src ACL bereiziekin konbinatzea

Konfigurazioa sinesgarria dirudi lehen begiradan:

acl team_a myportname 3128 src 198.51.100.0/24

Baina ACL definizioak mota bakarra du. Hemen myportname da mota; src hitza gehitzeak ez du bigarren proba bat hasten. Gainerako hitzak lehen motaren balio-zerrendakoak dira. Lerro horrek ez du esaten «entzule hau eta bezero-sare hau».

Eman izen bat baldintza bakoitzari

Erabili izen bat entzuten duen socketarentzat eta ACL bereizi bat iturriarentzat. Pasarte honek dokumentazioko helbideak erabiltzen ditu, hedapenaren araberako helbide egokiekin ordeztu behar direnak:

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

Jarri baimen-araua lehendik dauden babesenen ondoren: helmuga-portu arriskutsuak, CONNECT helburu mugatuak eta kudeaketa-sarbidea. Pasarteak bezero/entzule baldintza erakusten du; ez ditu babes horiek ordezten.

http_access lerro bateko baldintzak AND bidez konbinatzen dira. Bi baimen-lerro bereizik baldintza bakoitza modu independentean onartuko lukete, eta horrek politika nabarmen aldatuko luke. ACL bateko balio anitzek proba bakar horretarako aukerak ematen dituzte normalean.

Aukeratu irteera bereizita

Entzule egoki bat tcp_outgoing_address bidez ere erabil daiteke tokiko iturri-helbide bat aukeratzeko. Hori bideratze-hautaketa da, ez proxy-a erabiltzeko baimena. Irteera-helbidearen arauak ezin du ukatutako eskaera bat http_access bidez pasa arazi.

Helbide anitzeko konfigurazio batek bertsio-berritze baten ondoren funtzionatzeari uzten badio, bereizi frogak: analisi-erroreak konfigurazioaren sintaxira eramaten du; sarbide-ukapenak arauen bat-etortera; irteera okerreko eskaera baimenduak irteera-hautaketara edo geroagoko NAT-era. Hirurak aldi berean aldatzeak ACL errore txiki bat askoz zailagoa egiten du aurkitzeko.