Squid ના myportname અને src ને અલગ ACL સાથે જોડવા

રૂપરેખા પ્રથમ નજરે વિશ્વસનીય લાગે છે:

acl team_a myportname 3128 src 198.51.100.0/24

પણ ACL વ્યાખ્યામાં એક જ પ્રકાર હોય છે. અહીં myportname પ્રકાર છે; src શબ્દ ઉમેરવાથી બીજી કસોટી શરૂ થતી નથી. બાકીના શબ્દો પ્રથમ પ્રકારની મૂલ્ય-યાદીમાં આવે છે. એ લીટી “આ listener અને આ ક્લાયન્ટ નેટવર્ક” વ્યક્ત કરતી નથી.

દરેક શરતને નામ આપો

સાંભળતા socket માટે નામ અને સ્રોત માટે અલગ ACL વાપરો. આ અંશ દસ્તાવેજી સરનામાં વાપરે છે, જેને તૈનાતીને અનુરૂપ સરનામાંથી બદલવા પડશે:

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

અસુરક્ષિત લક્ષ્ય પોર્ટ, મર્યાદિત CONNECT લક્ષ્યો અને વ્યવસ્થાપન પ્રવેશ માટેના હાલના રક્ષણો પછી allow નિયમ મૂકો. અંશ ક્લાયન્ટ/listener શરત દર્શાવે છે; તે એ રક્ષણોનો વિકલ્પ નથી.

એક http_access લીટીની શરતો AND સાથે જોડાય છે. બે અલગ allow લીટીઓ દરેક શરતને સ્વતંત્ર રીતે મંજૂર કરે, જે નીતિને ઘણી બદલી નાખે. એક ACL માં અનેક મૂલ્યો સામાન્ય રીતે એ એક કસોટી માટે વિકલ્પો આપે છે.

બહાર જવાનો માર્ગ અલગ પસંદ કરો

મેળ ખાતો listener tcp_outgoing_address દ્વારા પણ સ્થાનિક સ્રોત સરનામું પસંદ કરવા વપરાઈ શકે છે. તે routing પસંદગી છે, proxy વાપરવાની પરવાનગી નથી. outgoing-address નિયમ નકારાયેલી વિનંતીને http_access થી પસાર કરી શકતો નથી.

જો બહુ-સરનામાં રૂપરેખા અપગ્રેડ પછી કામ કરવાનું બંધ કરે, તો પુરાવા અલગ કરો: parse ભૂલ રૂપરેખા સિન્ટેક્સ તરફ ઇશારો કરે છે; access denial નિયમ મેળ તરફ; ખોટા exit સાથે મંજૂર વિનંતી outgoing selection કે પછીના NAT તરફ. ત્રણેય એકસાથે બદલવાથી નાની ACL ભૂલ શોધવી ઘણી અઘરી બને છે.