एउटै सबनेटका वेबसाइटहरूले गेटवेको पारदर्शी प्रोक्सी बाइपास गर्न सक्छन्
इन्टरनेट अनुरोधहरू यसको लगमा देखिने भए पनि एउटै सबनेटको ट्राफिकले गेटवेको अवरोध नियम किन बाइपास गर्न सक्छ भन्ने व्याख्या गर्छ।
इन्टरनेट ब्राउजिङ गेटवे प्रोक्सीको लगमा देखिन्छ। अफिस LAN मा रहेको वेबसाइट देखिँदैन। URL फिल्टर बदल्नु अघि त्यो LAN अनुरोध गेटवेसम्म पुगेको थियो कि थिएन निश्चित गर्नुहोस्।
सिधै जोडिएको IPv4 गन्तव्यका लागि क्लाइन्टले गन्तव्यको लिङ्क-लेयर ठेगाना समाधान गरी स्थानीय खण्डमा त्यहाँ पठाउन सक्छ। यसको पूर्वनिर्धारित गेटवे त्यो मार्गमा स्वतः हुँदैन। गेटवेमा रहेको पारदर्शी अवरोध नियमले गेटवेले कहिल्यै नपाउने प्याकेट पुनर्निर्देशित गर्न सक्दैन।
उदाहरणका लागि, एउटै अन-लिङ्क सबनेटका दुई होस्टले स्विचमार्फत ट्राफिक साटासाट गर्न सक्छन् जबकि प्रोक्सी मेसिन अर्को स्विच पोर्टमा जोडिएको हुन्छ। त्यो LAN मा हुनु मात्रले प्रोक्सीलाई फर्वार्डिङ बिन्दु बनाउँदैन।
इच्छित मार्ग छान्नुहोस्
स्पष्ट प्रोक्सी सेटिङले लक्ष्य वेबसाइट स्थानीय भए पनि सहभागी अनुप्रयोगको अनुरोध प्रोक्सीमा पठाउन सक्छ। बाइपास नियम र PAC निर्णय पनि जाँच्नुहोस्: तिनीहरूले निजी नाम वा ठेगानाका लागि जानाजान DIRECT छान्न सक्छन्।
अवरोध आवश्यक भएमा, नेटवर्कले अवरोध बिन्दु साँच्चै मार्गमा राख्नुपर्छ; Linux गेटवेमा स्थानीय र फर्वार्ड गरिएका प्याकेट मार्ग छुट्याउनुहोस्। राउटेड सबनेट विभाजन वा जानाजान इनलाइन ब्रिजले उपयुक्त डिजाइनमा त्यो गर्न सक्छन्, तर प्रत्येकले फर्वार्डिङ र असफलता व्यवहार बदल्छ। LAN मा अन्यत्र रहेको ब्रिज स्वतः इनलाइन हुँदैन।
अनुप्रयोग प्रोटोकलको आवश्यकता अलग राख्नुहोस्। ट्राफिक उपकरण पार गरेपछि पनि श्रोताले अवरोध मोड समर्थन गर्नुपर्छ। प्याकेट सार्नु HTTPS डिक्रिप्ट गर्ने अनुमति होइन र सामान्य SOCKS पोर्टले तिनलाई स्वीकार गर्ने ग्यारेन्टी पनि होइन।
क्लाइन्टले छानेको मार्ग, स्थानीय खण्ड र वास्तविक फर्वार्डिङ उपकरण रेकर्ड गर्नुहोस्। प्रोक्सी लग नहुनु लगिङ असफलता नभई टोपोलोजीको सही वर्णन हुन सक्छ।