Kombini myportname kaj src de Squid per apartaj ACL-oj

La agordo ŝajnas kredebla unuavide:

acl team_a myportname 3128 src 198.51.100.0/24

Sed ACL-difino havas unu tipon. Ĉi tie myportname estas la tipo; aldoni la vorton src ne komencas duan teston. La ceteraj vortoj apartenas al la valorlisto de la unua tipo. Tiu linio ne esprimas «ĉi tiu auskultanto kaj ĉi tiu klienta reto».

Donu nomon al ĉiu kondiĉo

Uzu nomon por la auskulta soketo kaj apartan fontan ACL-on. Ĉi tiu eltiraĵo uzas dokumentajn adresojn, kiujn oni anstataŭigu per adresoj taŭgaj por la deplojo:

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

Metu la permesan regulon post la ekzistantaj protektoj por nesekuraj celhavenoj, limigitaj CONNECT-celoj kaj administra aliro. La eltiraĵo ilustras la kondiĉon kliento/auskultanto; ĝi ne anstataŭas tiujn protektojn.

Kondiĉoj sur unu http_access-linio estas kombinitaj per AND. Du apartaj permesaj linioj akceptus ĉiun kondiĉon sendepende, kio grave ŝanĝus la politikon. Pluraj valoroj en unu ACL kutime donas alternativojn por tiu ununura testo.

Elektu la eliron aparte

Kongrua auskultanto ankaŭ povas esti uzata de tcp_outgoing_address por elekti lokan fontadreson. Tio estas enkursiga elekto, ne permeso uzi la prokuron. Regulo pri elira adreso ne povas igi rifuzitan peton pasi tra http_access.

Se plur-adresa agordo ĉesas funkcii post ĝisdatigo, apartigu la pruvojn: analiza eraro indikas la sintakson de la agordo; alirrifuzo indikas kongruon de reguloj; permesita peto kun malĝusta eliro indikas eliran elekton aŭ postan NAT. Ŝanĝi ĉiujn tri samtempe igas malgrandan ACL-eraron multe pli malfacile trovebla.