एक लिनक्स गेटवे प्रॉक्सी प्रक्रिया चला सकता है और साथ ही उसके बगल से ट्रैफ़िक रूट भी कर सकता है। ये एक ही पैकेट पथ नहीं हैं।

कनेक्शनप्रासंगिक स्थानीय भूमिका
क्लाइंट गेटवे पर प्रॉक्सी तक पहुँचता हैस्थानीय होस्ट को संबोधित ट्रैफ़िक
क्लाइंट गेटवे से होकर किसी अन्य होस्ट तक पहुँचता हैअग्रेषित ट्रैफ़िक
प्रॉक्सी वेबसाइट कनेक्शन खोलता हैस्थानीय प्रक्रिया द्वारा उत्पन्न ट्रैफ़िक

Netfilter इनपुट, फ़ॉरवर्ड और आउटपुट पथों में अंतर करता है। गेटवे के अपने प्रॉक्सी श्रोता तक पहुँच को नियंत्रित करने वाला नियम उस मशीन से गुज़रने वाले हर रूट किए गए कनेक्शन को स्वतः सीमित नहीं करता।

निर्धारित करें कि क्या लागू करना है

यदि क्लाइंटों को स्वीकृत प्रॉक्सी का उपयोग करना ही है, तो नीति को इच्छित श्रोता की अनुमति देने के साथ-साथ उनके वैकल्पिक आउटबाउंड मार्गों को भी संबोधित करना होगा। केवल इसलिए कि कोई दूरस्थ सेवा परिचित प्रॉक्सी पोर्ट का उपयोग करती है, उससे कनेक्शन की अनुमति देना, केवल अपने प्रॉक्सी एंडपॉइंट की अनुमति देने के समान नहीं है।

प्रॉक्सी की अपनी आगे की पहुँच को अलग रखें। Squid के लिए, आउटबाउंड अनुमति लागू करने से पहले स्थानीय सॉकेट स्वामित्व को LAN उपयोगकर्ता पहचान से अलग करें। प्रॉक्सी से सभी उपयोगी आउटबाउंड कनेक्शन अस्वीकार करने से आवश्यक पथ अनुपलब्ध हो जाएगा। प्रबंधन ट्रैफ़िक, नाम विश्लेषण और समर्थित ग़ैर-वेब संचालनों को भी परिनियोजन की नीति में सुविचारित व्यवहार की आवश्यकता है।

प्रोटोकॉल का दायरा मायने रखता है। TCP नियम स्वयं UDP ट्रैफ़िक का वर्णन नहीं करता, जिसमें QUIC भी शामिल है। ट्रैफ़िक को रोकना एक और डिज़ाइन है; एक स्पष्ट HTTPS प्रॉक्सी वेबसाइट सत्र को डिक्रिप्ट किए बिना CONNECT दे सकता है।

नियम-समुच्चय संपादित करने से पहले इच्छित कनेक्शनों का मानचित्र बनाएँ। ब्राउज़र वरीयता भाग लेने वाले क्लाइंटों के लिए मार्ग चुनती है। नेटवर्क प्रवर्तन तय करता है कि कौन-से अन्य मार्ग सफल हो सकते हैं। इनमें से किसी को भी केवल प्रॉक्सी में सफल लॉगिन से अनुमान नहीं लगाना चाहिए।

संबंधित लेख