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 छनोट हो, प्रोक्सी प्रयोगको अनुमति होइन। outgoing-address नियमले अस्वीकृत अनुरोधलाई http_access बाट पार गराउन सक्दैन।

बहु-ठेगाना कन्फिगरेसन अपग्रेडपछि काम गर्न छोड्यो भने प्रमाण छुट्याउनुहोस्: parse त्रुटिले कन्फिगरेसन सिन्ट्याक्सतर्फ संकेत गर्छ; access denial ले नियम मिलानतर्फ; गलत exit भएको अनुमत अनुरोधले outgoing selection वा पछिको NAT तर्फ। तीनवटै एकैचोटि बदल्दा सानो ACL गल्ती खोज्न धेरै गाह्रो हुन्छ।