Squid-ന്റെ ഒരു allow നിയമം AND എന്നർത്ഥം; രണ്ടെണ്ണം OR ആകാം

ഈ നയം ഉറക്കെ വായിക്കുക: ഓഫീസ് നെറ്റ്വർക്കിന് അനുവദിച്ച ലക്ഷ്യത്തിലേക്ക് പ്രോക്സി ഉപയോഗിക്കാൻ അനുവദിക്കുക. ആ വ്യവസ്ഥകൾ ഒരുമിച്ചാണെങ്കിൽ, നിയമത്തിലും അവ ഒരുമിച്ച് നിർത്തുക.

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 ആർക്ക് ഉപയോഗിക്കാം എന്നതിനെ ഇത് ബാധിക്കുന്നു. നാല് സാഹചര്യങ്ങൾ പരിഗണിക്കുക: അനുവദിച്ച ക്ലയന്റിൽ നിന്ന് അനുവദിച്ച ലക്ഷ്യത്തിലേക്ക്, അനുവദിച്ച ക്ലയന്റിൽ നിന്ന് മറ്റൊരിടത്തേക്ക്, മറ്റൊരു ക്ലയന്റിൽ നിന്ന് അനുവദിച്ച ലക്ഷ്യത്തിലേക്ക്, മറ്റൊരു ക്ലയന്റിൽ നിന്ന് മറ്റൊരിടത്തേക്ക്. ഒരു പക്ഷേ നിയമങ്ങൾ നയം ഉദ്ദേശിച്ചതിലും കൂടുതൽ സാഹചര്യങ്ങൾ അനുവദിക്കുന്നെങ്കിൽ, ലിസണർ വിശാലമാക്കുന്നതിന് മുൻപ് യുക്തി തിരുത്തുക. വ്യാകരണപരമായി ശരിയായ കോൺഫിഗറേഷനും തെറ്റായ അനുമതികൾ പ്രകടിപ്പിക്കാം.