Vereis beide 'n Squid-aanmelding en die regte kliënt-IP

'n Korrekte wagwoord is slegs die helfte van hierdie beleid: die rekening moet ook vanaf een goedgekeurde kliëntadres werk. In Squid is dit die verskil tussen daardie vereiste en twee afsonderlike toegangsweë om albei kontroles op dieselfde toegangsreël te plaas.

As verifikasie reeds opgestel is, soos 'n Squid 6.13 NCSA-opstelling, is die kernbeleid:

acl approved_login proxy_auth alex
acl approved_source src 192.0.2.40/32
http_access allow approved_source approved_login
http_access deny all

Gebruik die bron wat Squid werklik ontvang; die voorbeeld is 'n dokumentasieadres. Behou vroeëre beskermings vir onveilige bestemmingspoorte, plaaslike dienste en CONNECT-verkeer. Hierdie fragment wys die gekombineerde voorwaarde eerder as 'n volledige luisteraarkonfigurasie.

Kontroleer die reëls bo dit

'n Vroeëre breë toestaan kan 'n versoek aanvaar voordat dit die nuwe voorwaarde bereik. Die http_access-verwysing beskryf geordende passing. Lees die volle volgorde, insluitend ingeslote lêers.

Een toestaan vir die gebruikersnaam en 'n ander vir die bron vereis nie albei nie. Enige van die twee reëls kan onafhanklik slaag. Dit is 'n ander beleid.

Die proxy_auth ACL hang van 'n verifikasiehulpmiddel af. Om dit te definieer is nie hoe jy die gebruiker skep of die wagwoord valideer nie. Hierdie voorbeeld is vir 'n eksplisiete proxy wie se kliënte op proxy-verifikasie-uitdagings kan reageer.

Bronidentiteit het ook perke. Mense agter een NAT kan 'n adres deel, en 'n beweegbare skootrekenaar kan van adres verander. Die ekstra voorwaarde vernou die rekening se bruikbare netwerklokasie; dit identifiseer nie betroubaar 'n fisiese rekenaar nie. Maak seker daardie beperking pas by die rede waarom jy die voorwaarde oorspronklik bygevoeg het.