Një fjalëkalim i saktë është vetëm gjysma e kësaj politike: llogaria duhet të funksionojë edhe nga një adresë klienti e miratuar. Në Squid, vendosja e të dyja kontrolleve në të njëjtin rregull aksesi është dallimi midis atij kushti dhe dy rrugëve të hyrjes të veçanta.

Duke supozuar se vërtetimi është konfiguruar tashmë, si për shembull një konfigurim NCSA i Squid 6.13, politika bazë është:

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

Përdorni burimin që Squid merr në të vërtetë; shembulli është një adresë dokumentacioni. Mbani mbrojtjet e mëparshme për portat e destinacionit të pasigurt, shërbimet lokale dhe trafikun CONNECT. Ky fragment tregon kushtin e kombinuar, jo një konfigurim të plotë dëgjuesi.

Kontrolloni rregullat sipër

Një leje e mëparshme e gjerë mund ta pranojë kërkesën përpara se ajo të arrijë kushtin e ri. Referenca http_access përshkruan përputhjen e renditur. Lexoni të gjithë sekuencën, përfshirë skedarët e përfshirë.

Një leje për emrin e përdoruesit dhe një tjetër për burimin nuk kërkojnë të dyja. Çdo rresht mund të ketë sukses në mënyrë të pavarur. Kjo është një politikë tjetër.

ACL proxy_auth varet nga një ndihmës vërtetimi. Përcaktimi i tij nuk është mënyra për të krijuar përdoruesin ose për të vërtetuar fjalëkalimin. Ky shembull është për një proxy të qartë, klientët e të cilit mund t'u përgjigjen sfidave të vërtetimit të proxy-t.

Edhe identiteti i burimit ka kufij. Njerëzit pas një NAT mund të ndajnë një adresë, dhe një laptop në lëvizje mund të ndryshojë adresa. Kushti shtesë ngushton vendndodhjen e rrjetit të përdorshëm të llogarisë; ai nuk identifikon me besueshmëri një kompjuter fizik. Sigurohuni që ky kufizim përputhet me arsyen pse e shtuat kushtin në fillim.

Artikuj të ngjashëm