આ નીતિ મોટેથી વાંચો: ઓફિસ નેટવર્કને મંજૂર ગંતવ્ય માટે પ્રોક્સી વાપરવા દો. જો એ શરતો સાથે જ હોય, તો નિયમમાં પણ તેમને સાથે રાખો.

http_access allow office_clients approved_destination

એ લાઇન વિનંતી મંજૂર કરે તે માટે બંને ACL મેળ ખાવા જોઈએ. તેને વિભાજિત કરવાથી નીતિ બદલાય છે:

http_access allow office_clients
http_access allow approved_destination

હવે ઓફિસ ક્લાયન્ટને ગંતવ્ય પ્રતિબંધ વગર મંજૂરી આપી શકાય, અને તે ગંતવ્યની વિનંતીઓને ઓફિસ પ્રતિબંધ વગર, જો અગાઉના નિયમે તેમને નકાર્યા ન હોય. બે લાઇન એ એક લાઇનની વધુ વાંચનીય જોડણી નથી.

ક્રમ નીતિનો ભાગ છે

Squid એક્સેસ નિયમોનું ક્રમિક મૂલ્યાંકન કરે છે. પ્રથમ મેળ ખાતો નિર્ણય વિનંતીને નિયંત્રિત કરે છે. અગાઉનો allow all પછીના કાળજીપૂર્વકના પ્રતિબંધને નિષ્ફળ કરે છે; અગાઉનો મેળ ખાતો ઇનકાર પછીની મંજૂરી સુધી પહોંચવાથી રોકે છે.

http_access દસ્તાવેજ આ ક્રમ સમજાવે છે. વાચક ગર્ભિત ડિફોલ્ટ વર્તન યાદ રાખશે તેવી આશા રાખવાને બદલે ઇરાદાપૂર્વક અંતિમ ઇનકાર રાખો.

ઘણી ACL વ્યાખ્યાઓમાં અલગ OR સંબંધ હોય છે: એક નામવાળી સ્રોત ACL ઘણા મંજૂર શ્રેણીઓ સૂચિબદ્ધ કરી શકે. તે સ્રોત અને ગંતવ્યની ઓળખને એક જ ACL પ્રકાર બનાવતું નથી. તેમને અલગ વ્યાખ્યાયિત કરો, પછી એક્સેસ નિર્ણયમાં નામો જોડો.

ખાનગી એક્ઝિટ માટે, આ તમારા બહારના IP નો ઉપયોગ કોણ કરી શકે તેને અસર કરે છે. ચાર કિસ્સા ધ્યાનમાં લો: મંજૂર ક્લાયન્ટથી મંજૂર ગંતવ્ય, મંજૂર ક્લાયન્ટ બીજે, બીજો ક્લાયન્ટ મંજૂર ગંતવ્ય, અને બીજો ક્લાયન્ટ બીજે. જો નિયમો નીતિ કરતાં વધુ કિસ્સા મંજૂર કરે, તો લિસનર પહોળું કરતા પહેલા તર્ક સુધારો. વ્યાકરણની દૃષ્ટિએ માન્ય રૂપરેખાંકન હજી પણ ખોટી પરવાનગીઓ વ્યક્ત કરી શકે છે.

સંબંધિત લેખો