अ‍ॅप इंटरफेसला बांधलेले आहे? त्याचा VPN मार्ग डीफॉल्ट नाही

मशीनवरील एक अ‍ॅप VPN मधून बाहेर जाते आणि दुसरे जात नाही, आणि दोन्ही वापरकर्ते काहीही बदलले नाही अशी शपथ घेतात. फरक बहुतेक वेळा अ‍ॅपनेच घेतलेला बाइंडिंगचा निर्णय असतो: डिव्हाइसशी बांधलेला सॉकेट, कनेक्शनपूर्वी निवडलेला स्रोत पत्ता, किंवा स्वतःच्या राउटिंग टेबलसह नेमस्पेस. प्रत्येकजण कोणता मार्ग लागू होतो ते बदलतो, आणि त्यापैकी कोणीही ब्राउझरच्या सामान्य IP तपासणीत दिसत नाही.

तीन वेगवेगळे बाइंडिंग, तीन वेगवेगळे परिणाम

डिव्हाइसशी बांधणे आणि स्रोत पत्त्याशी बांधणे या संबंधित क्रिया आहेत पण परिणाम वेगळे आहेत. डिव्हाइस बाइंडिंग ट्राफिकला एका इंटरफेसून बाहेर पडण्यास भाग पाडू शकते आणि त्या सॉकेटचा नेहमीचा मार्ग शोध बायपास करू शकते. स्रोत पत्त्याचे बाइंडिंग तरीही मार्ग निवडीतून जाते, पण निवडलेला स्रोत कोणत्याही धोरण-नियमाशी जुळून पॅकेट अन्यत्र पाठवू शकतो. हा फरक नियम स्रोतानुसार मार्ग ठरवेपर्यंत शैक्षणिक वाटतो. मग तो सर्व ठरवतो.

नेटवर्क नेमस्पेस ही तिसरी स्थिती. त्याचे स्वतःचे इंटरफेस आणि राउटिंग टेबल असते, त्यामुळे आतल्या अ‍ॅपवर होस्टच्या डीफॉल्टचा मुळीच परिणाम होत नाही. तिन्हींना एकच गोष्ट मानल्यास पहिल्या चाचणीत टिकणार नाहीत अशा आत्मविश्वासू स्पष्टीकरणांची निर्मिती होते.

अ‍ॅप प्रत्यक्षात काय सेट करते ते ठरवा

मार्गांना हात लावण्यापूर्वी अ‍ॅपची नेटवर्किंग कॉन्फिगरेशन किंवा त्याचे दस्तऐवजीकृत वर्तन वाचा. जर ते इंटरफेस निवड, स्रोत पत्ता फील्ड किंवा नेमस्पेस पर्याय देते, तर तेच सेटिंग पहिल्यांदा तपासायचे. नसल्यास बाइंडिंग अंतर्गत असू शकते आणि फक्त ट्रेसिंग किंवा त्याच्या स्वतःच्या डायग्नोस्टिक्समधून दिसू शकते.

Linux मध्ये SO_BINDTODEVICE सारख्या सॉकेट पर्यायांना दस्तऐवजीकृत व्याप्ती आणि परवानगीच्या अटी असतात, आणि विशेषाधिकार नसलेल्या प्रक्रियेला ते अजिबात सेट करता येणार नाहीत. ही मर्यादा उपयुक्त सुगावा आहे: पर्याय लागू करता येत नसेल, तर फरकाचा स्रोत अ‍ॅप नसावा.

धोरण राउटिंग स्रोत वाचते

धोरण राउटिंग कॉन्फिगर केलेले असताना, नियम पॅकेटच्या स्रोतावर आधारित टेबल निवडू शकतो. त्यामुळे स्रोत पत्ता बांधणारा सॉकेट डीफॉल्ट मार्ग कधीही स्पर्श न करणाऱ्या नियमाचे पालन करू शकतो, जरी कोणताही इंटरफेस स्पष्टपणे नामनिर्देशित केलेला नसला तरी.

अ‍ॅप वापरते तोच पत्ता-कुटुंब, स्रोत आणि नेमस्पेस वापरून शोध पुन्हा करा. होस्टच्या नेमस्पेसमधील शेलमधून केलेला सामान्य मार्ग शोध वेगळ्या प्रश्नाचे उत्तर देतो, आणि हीच विसंगती कार्यरत मार्ग तुटलेला दिसण्याचे सर्वात सामान्य कारण आहे.

स्प्लिट टनेलिंग आणि सहायक प्रक्रिया

प्रत्येक अ‍ॅपसाठी स्प्लिट टनेलिंग आणखी एक थर जोडते. क्लायंट अ‍ॅपचे पॅकेज किंवा प्रक्रिया जुळवू शकतो, आणि स्वतःचे सॉकेट उघडणारा सहायक वेगळा विषय आहे. लाँचर आणि त्याची पार्श्वभूमी सेवा एकाच दृश्यमान नावाखाली वेगवेगळे कनेक्शन निर्माण करू शकतात.

स्प्लिट-टनेल नियम प्रत्यक्षात जोडणाऱ्या प्रक्रियेला समाविष्ट करतो का ते तपासा. अ‍ॅप विशिष्ट इंटरफेसला बांधलेले असेल आणि VPN क्लायंट पॅकेजनुसार जुळवत असेल, तर दोन्ही निर्णय कोणतेही चुकीचे नसतानाही वेगळे पडू शकतात.

अ‍ॅपचा स्वतःचा मार्ग तपासा

प्रत्येक बदलानंतर अ‍ॅपमधून नवीन विनंती चालवा. तुम्हाला हवा असलेला एक्झिट दाखवणारा ब्राउझर दुसऱ्या इंटरफेसला बांधलेल्या दुसऱ्या प्रोग्रामसाठी समान पुरावा नाही, आणि कॅशे केलेली कनेक्शन्स सेटिंग बदलल्यानंतरही बराच काळ जुना मार्ग वापरू शकतात. नवीन नियमाचे मूल्यांकन करण्यापूर्वी जुने सत्र बंद करा. अन्यथा चाचणी भूतकाळ मोजते.

Linux सॉकेट संदर्भ SO_BINDTODEVICE आणि त्याच्या अटींचे दस्तऐवजीकरण करतो. आधी अ‍ॅपचे स्वतःचे कॉन्फिगरेशन वाचा, त्याच संदर्भात शोध पुन्हा करा आणि त्यानंतरच मार्ग की बाइंडिंग बदलायचे का ते ठरवा.