Postulu kaj Squid-an saluton kaj la ĝustan klientan IP

Ĝusta pasvorto estas nur duono de ĉi tiu politiko: la konto devus ankaŭ funkcii de unu aprobita klientadreso. En Squid, meti ambaŭ kontrolojn sur la saman alirregulon estas la diferenco inter tiu postulo kaj du apartaj eniroj.

Supozante, ke aŭtentikigo jam estas agordita, ekzemple Squid 6.13 NCSA-agordo, la ĉefa politiko estas:

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

Uzu la fonton, kiun Squid efektive ricevas; la specimeno estas dokumentada adreso. Konservu pli fruajn protektojn por nesekuraj celhavenoj, lokaj servoj kaj CONNECT-trafiko. Ĉi tiu fragmento montras la kombinatan kondiĉon, ne kompletan aŭskultan agordon.

Kontrolu la regulojn super ĝi

Pli frua vasta permeso povas akcepti la peton antaŭ ol ĝi atingas la novan kondiĉon. La http_access-referenco priskribas ordigitan kongruon. Legu la plenan sinsekvon, inkluzive de inkluditaj dosieroj.

Unu permeso por la uzantnomo kaj alia por la fonto ne postulas ambaŭ. Ĉiu linio povas sukcesi sendepende. Tio estas malsama politiko.

La ACL proxy_auth dependas de aŭtentikiga helpanto. Difini ĝin ne estas kiel vi kreas la uzanton aŭ validigas la pasvorton. Ĉi tiu ekzemplo estas por eksplicita prokzo, kies klientoj povas respondi al prokzaj aŭtentikigaj defioj.

Fontidenteco ankaŭ havas limojn. Homoj malantaŭ unu NAT povas dividi adreson, kaj moviĝanta tekkomputilo povas ŝanĝi adresojn. La plia kondiĉo mallarĝigas la uzeblan retan lokon de la konto; ĝi ne fidinde identigas fizikan komputilon. Certiĝu, ke tiu limigo kongruas kun la kialo, pro kiu vi aldonis la kondiĉon komence.