Squid લોગિન અને યોગ્ય ક્લાયન્ટ IP બંને જરૂરી બનાવો

યોગ્ય પાસવર્ડ આ નીતિનો ફક્ત અડધો ભાગ છે: ખાતું એક મંજૂર ક્લાયન્ટ સરનામાં પરથી પણ કાર્ય કરવું જોઈએ. Squid માં, બંને તપાસને એક જ એક્સેસ નિયમ પર મૂકવી એ તે જરૂરિયાત અને બે અલગ પ્રવેશ માર્ગો વચ્ચેનો તફાવત છે.

એમ ધારીને કે પ્રમાણીકરણ પહેલેથી ગોઠવાયેલું છે, જેમ કે Squid 6.13 NCSA સેટઅપ, મુખ્ય નીતિ આ છે:

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

Squid ખરેખર જે સ્રોત મેળવે છે તે વાપરો; નમૂનો દસ્તાવેજીકરણ સરનામું છે. અસુરક્ષિત ગંતવ્ય પોર્ટ, સ્થાનિક સેવાઓ અને CONNECT ટ્રાફિક માટે અગાઉના રક્ષણો જાળવી રાખો. આ ટુકડો સંયુક્ત શરત બતાવે છે, સંપૂર્ણ લિસનર ગોઠવણી નહીં.

તેની ઉપરની નિયમો તપાસો

અગાઉની વિશાળ પરવાનગી નવી શરત સુધી પહોંચતા પહેલા વિનંતી સ્વીકારી શકે છે. http_access સંદર્ભ ક્રમબદ્ધ મેળ વર્ણવે છે. સમાવિષ્ટ ફાઇલો સહિત સંપૂર્ણ ક્રમ વાંચો.

વપરાશકર્તા નામ માટે એક પરવાનગી અને સ્રોત માટે બીજી બંનેની માંગ કરતી નથી. કોઈપણ લાઇન સ્વતંત્ર રીતે સફળ થઈ શકે છે. તે અલગ નીતિ છે.

proxy_auth ACL પ્રમાણીકરણ સહાયક પર આધાર રાખે છે. તેને વ્યાખ્યાયિત કરવું એ વપરાશકર્તા બનાવવાનો અથવા પાસવર્ડ માન્ય કરવાનો રસ્તો નથી. આ ઉદાહરણ સ્પષ્ટ પ્રોક્સી માટે છે જેના ક્લાયન્ટ પ્રોક્સી પ્રમાણીકરણ પડકારોનો જવાબ આપી શકે છે.

સ્રોત ઓળખની પણ મર્યાદાઓ છે. એક NAT પાછળના લોકો સરનામું શેર કરી શકે છે, અને ફરતું લેપટોપ સરનામું બદલી શકે છે. વધારાની શરત ખાતાનું વપરાયોગ્ય નેટવર્ક સ્થાન સાંકડું કરે છે; તે ભૌતિક કમ્પ્યુટરને વિશ્વસનીય રીતે ઓળખતું નથી. ખાતરી કરો કે તે મર્યાદા તમે શરૂઆતમાં શરત ઉમેરવાના કારણ સાથે મેળ ખાય છે.