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 വഴിയും പ്രാദേശിക ഉറവിട വിലാസം തിരഞ്ഞെടുക്കാൻ ഉപയോഗിക്കാം. അത് റൂട്ടിംഗ് തിരഞ്ഞെടുപ്പാണ്, പ്രോക്സി ഉപയോഗിക്കാനുള്ള അനുമതിയല്ല. പുറത്തേക്കുള്ള വിലാസ നിയമത്തിന് നിരസിച്ച അഭ്യർത്ഥന http_access വഴി കടത്താൻ കഴിയില്ല.

ഒന്നിലധികം വിലാസമുള്ള ക്രമീകരണം അപ്‌ഗ്രേഡിന് ശേഷം പ്രവർത്തിക്കാതായാൽ തെളിവുകൾ വേർതിരിക്കുക: പാഴ്‌സ് പിശക് ക്രമീകരണ വാക്യഘടനയെ സൂചിപ്പിക്കുന്നു; പ്രവേശന നിരസനം നിയമ പൊരുത്തത്തെ; തെറ്റായ പുറത്തേക്കുള്ള വഴിയിൽ അനുവദിച്ച അഭ്യർത്ഥന പുറത്തേക്കുള്ള തിരഞ്ഞെടുപ്പിനെയോ പിന്നീടുള്ള NAT-നെയോ സൂചിപ്പിക്കുന്നു. മൂന്നും ഒരുമിച്ച് മാറ്റുന്നത് ചെറിയ ACL പിശക് കണ്ടെത്താൻ വളരെ ബുദ്ധിമുട്ടാക്കുന്നു.