ऐप-आधारित बनाम गंतव्य-आधारित स्प्लिट टनलिंग: किसे चुनें

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

दोनों नियम अलग-अलग परतों पर लागू होते हैं

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

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

ऐप नियम मोबाइल क्लाइंट और प्रबंधित एजेंट के लिए उपयुक्त हैं

Android विकल्प सीधे प्रस्तुत करता है: VpnService.Builder.addAllowedApplication() और addDisallowedApplication() पैकेज नाम लेते हैं और हर UID के लिए निर्णय लागू करते हैं, जैसा Android की VPN डेवलपर गाइड में वर्णित है। iOS में बंडल पहचानकर्ताओं पर आधारित प्रति-ऐप VPN नियमों के ज़रिए समतुल्य व्यवस्था है, जो आमतौर पर हाथ से लिखने के बजाय MDM प्रोफ़ाइल से दिए जाते हैं।

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

एक परिणाम जो लोग चूक जाते हैं: उन प्लेटफ़ॉर्म पर रूट से ऐप नियम की नकल नहीं की जा सकती। ऐप के सर्वर के लिए होस्ट रूट जोड़ने पर सबका ट्रैफ़िक उस सर्वर की ओर टनल हो जाता है, ब्राउज़र और अपडेटर सहित।

गंतव्य नियम सबनेट सूचियों और साइट पहुँच के लिए उपयुक्त हैं

WireGuard मॉडल को स्पष्ट करता है। AllowedIPs क्रिप्टोकी रूटिंग है: जिस आंतरिक पैकेट का गंतव्य किसी पीयर की सूची में आता है वह उस पीयर की ओर एन्क्रिप्ट होता है, और बाकी सब सामान्य पथ से बिना एन्क्रिप्शन निकलता है। नाम देने के लिए कोई प्रक्रिया नहीं और क्या शामिल है इस पर कोई अस्पष्टता नहीं।

OpenVPN धकेली गई रूटिंग तालिका के ज़रिए उसी स्थान पर पहुँचता है। route-nopull सर्वर को रूट थोपने से रोकता है, उसके बाद क्लाइंट-पक्षीय route 10.20.0.0 255.255.0.0 vpn_gateway ठीक ऑफ़िस प्रीफ़िक्स को कवर करता है। IPv6 इनमें से हर क्लाइंट में अलग कथन है, और उसे भूल जाना सही दिखने वाले IPv4 स्प्लिट के इर्द-गिर्द लीक होने का सबसे आम तरीका है।

होस्टनाम रूट नहीं है। यदि प्रोफ़ाइल डोमेन फ़ील्ड देता है, तो उसे ऐसे नाम के रूप में लें जिसे क्लाइंट एक बार हल करता है, स्थायी पता-सीमा के रूप में नहीं; कंटेंट डिलीवरी नेटवर्क और लोड बैलेंसर कल अलग पते देंगे।

दोनों मॉडल कहाँ टूटते हैं: सहायक प्रक्रियाएँ, साझा सेवाएँ, रिज़ॉल्वर

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

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

रिज़ॉल्वर दोनों को काटते हैं। यदि क्लाइंट आंतरिक DNS सर्वर सेट करता है पर ऑपरेटिंग सिस्टम किसी सार्वजनिक रिज़ॉल्वर तक HTTPS पर DNS का उपयोग करता है, तो उत्तर टनल के बाहर से आता है और गंतव्य नियम शायद कभी मेल न खाए। नियम गलत है इस निष्कर्ष पर पहुँचने से पहले जाँचें कि वास्तव में किस रिज़ॉल्वर ने उत्तर दिया, और क्लाइंट की ओर पुष्टि करें कि उसने टनल रिज़ॉल्वर स्थापित किया भी या नहीं। जो स्प्लिट DNS को टनल के बाहर छोड़ता है वह रूटिंग तालिका में उत्तम दिखता है और फिर भी हर आंतरिक नाम पर विफल होता है।

रनबुक: चुनें, लागू करें, सत्यापित करें

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

जो सबसे सँकरा रूप आप व्यक्त कर सकते हैं उसे लागू करें, फिर क्लाइंट के स्थिति आइकन के बजाय रूटिंग तालिका से पूछकर सत्यापित करें:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

पहली दो पंक्तियाँ उस इंटरफ़ेस का नाम देती हैं जिसका वास्तविक गंतव्य उपयोग करेगा; wg show कॉन्फ़िगर की गई प्रीफ़िक्स सूची छापता है; Windows पर, Find-NetRoute उसी प्रश्न का उत्तर देता है जो पैकेट भेजे जाने पर स्टैक देगा। यदि इंटरफ़ेस टनल है, तो नियम मेल खाया।

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