இந்தக் கொள்கையை சத்தமாகப் படியுங்கள்: அலுவலக வலையமைப்பு அங்கீகரிக்கப்பட்ட இலக்குக்கு ப்ராக்ஸியைப் பயன்படுத்த அனுமதிக்கவும். அந்த நிபந்தனைகள் ஒன்றாக இருந்தால், விதியிலும் அவற்றை ஒன்றாக வைத்திருங்கள்.

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-ஐ யார் பயன்படுத்தலாம் என்பதைப் பாதிக்கிறது. நான்கு நிகழ்வுகளைக் கவனியுங்கள்: அங்கீகரிக்கப்பட்ட வாடிக்கையாளர் அங்கீகரிக்கப்பட்ட இலக்குக்கு, அங்கீகரிக்கப்பட்ட வாடிக்கையாளர் வேறு இடத்திற்கு, மற்றொரு வாடிக்கையாளர் அங்கீகரிக்கப்பட்ட இலக்குக்கு, மற்றொரு வாடிக்கையாளர் வேறு இடத்திற்கு. ஒருவேளை விதிகள் கொள்கை நோக்கியதை விட அதிக நிகழ்வுகளை அனுமதித்தால், கேட்பவரை விரிவாக்கும் முன் தர்க்கத்தைச் சரிசெய்யுங்கள். இலக்கணப்படி சரியான கட்டமைப்பும் தவறான அனுமதிகளை வெளிப்படுத்தலாம்.

தொடர்புடைய கட்டுரைகள்