Squidin myportname ja src erillisillä ACLillä

Asetelma näyttää ensisilmäyksellä uskottavalta:

acl team_a myportname 3128 src 198.51.100.0/24

Mutta ACL-määritelmällä on vain yksi tyyppi. Tässä myportname on tyyppi; sanan src lisääminen ei aloita toista testiä. Loput sanat kuuluvat ensimmäisen tyypin arvoluetteloon. Se rivi ei ilmaise ”tätä kuuntelijaa ja tätä asiakasverkkoa”.

Anna jokaiselle ehdolle nimi

Käytä nimeä kuuntelevalle socketille ja erillistä lähde-ACL:ää. Tämä katkelma käyttää dokumentaation osoitteita, jotka on korvattava käyttöönottoon sopivilla osoitteilla:

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

Sijoita sallintasääntö olemassa olevien suojausten jälkeen, jotka koskevat vaarallisia kohdeportteja, rajoitettuja CONNECT-kohteita ja hallintakäyttöä. Katkelma havainnollistaa asiakas/kuuntelija-ehtoa; se ei korvaa näitä suojauksia.

Yhden http_access-rivin ehdot yhdistetään AND-operaattorilla. Kaksi erillistä sallintariviä hyväksyisi kumman tahansa ehdon itsenäisesti, mikä muuttaisi käytäntöä huomattavasti. Useat arvot yhdessä ACL:ssä tarjoavat yleensä vaihtoehtoja tuolle yksittäiselle testille.

Valitse lähtö erikseen

Sopivaa kuuntelijaa voidaan käyttää myös tcp_outgoing_address-direktiivillä paikallisen lähdeosoitteen valitsemiseen. Se on reitityksen valinta, ei lupa käyttää välityspalvelinta. Lähtevän osoitteen sääntö ei voi saada hylättyä pyyntöä kulkemaan http_access-säännön läpi.

Jos moniosoiteasetelma lakkaa toimimasta päivityksen jälkeen, erottele todisteet: jäsennysvirhe viittaa asetusten syntaksiin; käytön esto viittaa sääntöjen täsmäämiseen; sallittu pyyntö väärällä lähdöllä viittaa lähdön valintaan tai myöhempään NATiin. Kaikkien kolmen muuttaminen kerralla tekee pienestä ACL-virheestä paljon vaikeamman löytää.