एप कुनै इन्टरफेसमा बाँधिएको हो? यसको VPN मार्ग डिफल्ट होइन

मेसिनमा एउटा एप्लिकेसन VPN बाट बाहिर जान्छ र अर्को जाँदैन, र दुवै प्रयोगकर्ताले केही पनि नबदलेको कसम खान्छन्। फरक प्रायः एप्लिकेसनले नै लिएको बाइन्डिङ निर्णय हो: यन्त्रसँग बाँधिएको सकेट, जडान अघि छानिएको स्रोत ठेगाना, वा आफ्नै राउटिङ तालिका भएको नेमस्पेस। प्रत्येकले कुन मार्ग लागू हुन्छ भन्ने बदल्छ, र तीमध्ये कुनै पनि ब्राउजरको सामान्य IP जाँचमा देखिँदैन।

तीन फरक बाइन्डिङ, तीन फरक प्रभाव

यन्त्रसँग बाँध्नु र स्रोत ठेगानासँग बाँध्नु सम्बन्धित कार्य हुन् तर परिणाम फरक छन्। यन्त्र बाइन्डिङले ट्राफिकलाई एउटा इन्टरफेसबाट बाहिर जान बाध्य पार्न सक्छ र त्यो सकेटको सामान्य मार्ग खोजलाई बाइपास गर्न सक्छ। स्रोत ठेगानाको बाइन्डिङ अझै मार्ग छनोटबाट जान्छ, तर छानिएको स्रोत कुनै नीति-नियमसँग मिलेर प्याकेट अन्यत्र पठाउन सक्छ। यो भिन्नता नियमले स्रोतअनुसार मार्ग निर्धारण नगरेसम्म शैक्षिक सुनिन्छ। त्यसपछि यसले सबै निर्धारण गर्छ।

नेटवर्क नेमस्पेस तेस्रो अवस्था हो। यसका आफ्नै इन्टरफेस र राउटिङ तालिका हुन्छन्, त्यसैले भित्रको एप्लिकेसनमा होस्टको डिफल्टले केही असर गर्दैन। तीनवटैलाई एउटै कुरा मान्दा पहिलो परीक्षामै नटिक्ने आत्मविश्वासी व्याख्या उत्पन्न हुन्छन्।

एपले वास्तवमा के सेट गर्छ निर्धारण गर्नुहोस्

मार्ग छुनुअघि एप्लिकेसनको नेटवर्किङ कन्फिगरेसन वा यसको अभिलेखित व्यवहार पढ्नुहोस्। यदि यसले इन्टरफेस छनोट, स्रोत ठेगाना फिल्ड वा नेमस्पेस विकल्प दिन्छ भने त्यही सेटिङ पहिले जाँच्नुपर्ने कुरा हो। नभए बाइन्डिङ आन्तरिक हुन सक्छ र ट्रेसिङ वा यसको आफ्नै डायग्नोस्टिक्सबाट मात्र देखिन सक्छ।

Linux मा SO_BINDTODEVICE जस्ता सकेट विकल्पको अभिलेखित दायरा र अनुमति आवश्यकता हुन्छ, र विशेषाधिकार नभएको प्रक्रियाले ती सेट गर्नै नसक्ने हुन सक्छ। यो सीमा उपयोगी संकेत हो: विकल्प लागू गर्न नसकिने भए फरकको स्रोत एप नहुन सक्छ।

नीति राउटिङले स्रोत पढ्छ

नीति राउटिङ कन्फिगर हुँदा नियमले प्याकेटको स्रोतका आधारमा तालिका छान्न सक्छ। त्यसैले स्रोत ठेगाना बाँध्ने सकेटले डिफल्ट मार्गले कहिल्यै नछुने नियम पछ्याउन सक्छ, कुनै इन्टरफेस स्पष्ट रूपमा नाम नदिइए पनि।

एप्लिकेसनले प्रयोग गर्ने त्यही ठेगाना परिवार, स्रोत र नेमस्पेससँग खोज दोहोर्‍याउनुहोस्। होस्टको नेमस्पेसमा शेलबाट गरिने सामान्य मार्ग खोजले अर्को प्रश्नको उत्तर दिन्छ, र यही असंगति काम गर्ने मार्ग बिग्रिएको देखिने सबैभन्दा सामान्य कारण हो।

स्प्लिट टनेलिङ र सहायक प्रक्रिया

प्रत्येक एपका लागि स्प्लिट टनेलिङले अर्को तह थप्छ। क्लाइन्टले एपको प्याकेज वा प्रक्रिया मिलाउन सक्छ, र आफ्नै सकेट खोल्ने सहायक छुट्टै विषय हो। लन्चर र यसको पृष्ठभूमि सेवाले एउटै देखिने नाममुनि फरक जडान उत्पादन गर्न सक्छन्।

स्प्लिट-टनेल नियमले वास्तवमा जोडिने प्रक्रियालाई समेट्छ कि जाँच्नुहोस्। एप कुनै निश्चित इन्टरफेसमा बाँधिएको छ र VPN क्लाइन्टले प्याकेजअनुसार मिलाउँछ भने दुवै निर्णय कुनै पनि गलत नभई फरक पर्न सक्छन्।

एपको आफ्नै मार्ग परीक्षण गर्नुहोस्

प्रत्येक परिवर्तनपछि एप्लिकेसनबाट नयाँ अनुरोध चलाउनुहोस्। तपाईंले चाहेको निकास देखाउने ब्राउजर अर्को इन्टरफेसमा बाँधिएको अर्को प्रोग्रामका लागि समान प्रमाण होइन, र क्यास गरिएका जडानले सेटिङ बदलिएपछि पनि लामो समय पुरानो मार्ग प्रयोग गर्न सक्छन्। नयाँ नियमको मूल्याङ्कन गर्नुअघि पुरानो सत्र बन्द गर्नुहोस्। नत्र परीक्षाले विगत नाप्छ।

Linux सकेट सन्दर्भ ले SO_BINDTODEVICE र यसका आवश्यकता अभिलेख गर्छ। पहिले एपको आफ्नै कन्फिगरेसन पढ्नुहोस्, त्यही सन्दर्भमा खोज दोहोर्‍याउनुहोस्, र त्यसपछि मात्र मार्ग वा बाइन्डिङ बदल्नुपर्ने होइन निर्धारण गर्नुहोस्।