ऐप किसी इंटरफ़ेस से बँधा है? उसका VPN रास्ता डिफ़ॉल्ट नहीं है

मशीन पर एक ऐप VPN से बाहर जाता है और दूसरा नहीं, और दोनों उपयोगकर्ता कसम खाते हैं कि उन्होंने कुछ नहीं बदला। अंतर अक्सर ऐप का ही लिया गया बाइंडिंग निर्णय होता है: डिवाइस से बँधा सॉकेट, कनेक्शन से पहले चुना गया स्रोत पता, या अपनी रूटिंग तालिका वाला नेमस्पेस। हर एक बदलता है कि कौन-सा रास्ता लागू होता है, और इनमें से कोई ब्राउज़र की सामान्य IP जाँच में नहीं दिखता।

तीन अलग बाइंडिंग, तीन अलग असर

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

नेटवर्क नेमस्पेस तीसरा मामला है। इसके अपने इंटरफ़ेस और अपनी रूटिंग तालिका होती है, इसलिए इसके अंदर का ऐप मेज़बान के डिफ़ॉल्ट से बिल्कुल प्रभावित नहीं होता। तीनों को एक ही चीज़ मानने से ऐसे आत्मविश्वासी स्पष्टीकरण बनते हैं जो पहली परीक्षा में टिकते नहीं।

तय करें कि ऐप वास्तव में क्या सेट करता है

रूट छूने से पहले ऐप का नेटवर्क कॉन्फ़िगरेशन या उसका प्रलेखित व्यवहार पढ़ें। अगर वह इंटरफ़ेस चयन, स्रोत पता फ़ील्ड या नेमस्पेस विकल्प देता है, तो वही सेटिंग सबसे पहले देखने की चीज़ है। अगर नहीं, तो बाइंडिंग आंतरिक हो सकती है और सिर्फ़ ट्रेसिंग या उसके अपने डायग्नोस्टिक्स से दिख सकती है।

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

नीति रूटिंग स्रोत पढ़ती है

जब नीति रूटिंग कॉन्फ़िगर होती है, तो कोई नियम पैकेट के स्रोत के आधार पर तालिका चुन सकता है। इसलिए स्रोत पता बाँधने वाला सॉकेट ऐसे नियम का पालन कर सकता है जिसे डिफ़ॉल्ट रास्ता कभी नहीं छूता, भले ही कोई इंटरफ़ेस स्पष्ट रूप से नामित न हो।

ऐप जिस पता-परिवार, स्रोत और नेमस्पेस का उपयोग करता है, उसी के साथ खोज दोहराएँ। मेज़बान के नेमस्पेस में शेल से सामान्य रूट खोज किसी दूसरे प्रश्न का उत्तर देती है, और यही असंगति काम करते रास्ते के टूटा दिखने का सबसे आम कारण है।

स्प्लिट टनलिंग और सहायक प्रक्रियाएँ

प्रति-ऐप स्प्लिट टनलिंग एक और परत जोड़ती है। क्लाइंट ऐप के पैकेज या प्रक्रिया से मेल कर सकता है, और अपना सॉकेट खोलने वाला सहायक अलग विषय है। लॉन्चर और उसकी बैकग्राउंड सेवा एक ही दिखने वाले नाम के तहत अलग कनेक्शन बना सकते हैं।

जाँचें कि स्प्लिट-टनल नियम उस प्रक्रिया को कवर करता है जो वास्तव में जुड़ती है। अगर ऐप किसी खास इंटरफ़ेस से बँधा है और VPN क्लाइंट पैकेज के आधार पर मेल करता है, तो दोनों निर्णय बिना किसी के गलत होकर भी अलग हो सकते हैं।

ऐप का अपना रास्ता जाँचें

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

Linux सॉकेट संदर्भ SO_BINDTODEVICE और उसकी शर्तों का दस्तावेज़ीकरण करता है। पहले ऐप का अपना कॉन्फ़िगरेशन पढ़ें, उसी संदर्भ में खोज दोहराएँ और तभी तय करें कि रूट या बाइंडिंग बदलनी चाहिए या नहीं।