Eit rett passord er berre halvparten av denne policyen: kontoen skal òg fungere frå éi godkjend klientadresse. I Squid er skilnaden mellom det kravet og to separate inngangar å setje begge kontrollane på same tilgangsregel.

Føresett at autentisering alt er konfigurert, til dømes eit Squid 6.13 NCSA-oppsett, er kjerne policyen:

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

Bruk kjelda Squid faktisk tek imot; eksempelet er ei dokumentasjonsadresse. Hald på tidlegare vern for utrygge målportar, lokale tenester og CONNECT-trafikk. Dette fragmentet viser den kombinerte vilkåret, ikkje ein fullstendig lyttarkonfigurasjon.

Kontroller reglane over

Ei tidlegare brei tillating kan godta førespurnaden før han når det nye vilkåret. http_access-referansen skildrar ordna matching. Les heile sekvensen, inkludert inkluderte filer.

Éi tillating for brukarnamnet og ei anna for kjelda krev ikkje begge. Kvar linje kan lukkast uavhengig. Det er ein annan policy.

proxy_auth-ACL-en er avhengig av ein autentiseringshjelpar. Å definere han er ikkje korleis du opprettar brukaren eller validerer passordet. Dette eksempelet er for ein eksplisitt proxy der klientane kan svare på proxy-autentiseringsutfordringar.

Kjeldeidentitet har òg grenser. Folk bak éin NAT kan dele ei adresse, og ein flyttbar laptop kan skifte adresse. Tilleggsvilkåret snevrar inn den brukbare nettverksplasseringa til kontoen; det identifiserer ikkje ein fysisk datamaskin påliteleg. Sørg for at avgrensinga samsvarar med grunnen til at du la til vilkåret i utgangspunktet.

Relaterte artiklar