एक IPv4 गंतव्य को OpenVPN सुरंग से बाहर कैसे भेजें

अधिकांश फुल-टनल सेटअप हर पैकेट को VPN से भेजते हैं, और redirect-gateway वही निर्देश है जो ऐसा करता है। एक अकेले गंतव्य को फिर भी छूट दी जा सकती है। उस पते के लिए net_gateway प्लेसहोल्डर के साथ होस्ट रूट जोड़ना क्लाइंट से कहता है कि वह मशीन के मूल गेटवे से वहाँ पहुँचे, जबकि बाकी सब सुरंग का इस्तेमाल करता रहता है।

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

net_gateway असल में किसका नाम लेता है

उस छूट के लिए प्रोफ़ाइल प्रविष्टि एक ही पंक्ति है: route 198.51.100.77 255.255.255.255 net_gateway। पहला पता गंतव्य के लिए दस्तावेज़ी प्लेसहोल्डर है, मास्क उसे एक-होस्ट रूट बनाता है, और अंतिम टोकन गेटवे प्लेसहोल्डर का नाम लेता है। OpenVPN रूट इंस्टॉल करते समय गेटवे प्लेसहोल्डर हल करता है। vpn_gateway का मतलब सुरंग का अपना गेटवे है, यानी VPN लिंक का दूर वाला सिरा। net_gateway का मतलब वह डिफ़ॉल्ट गेटवे है जो VPN के कुछ भी बदलने से पहले होस्ट के पास था, जो आमतौर पर भौतिक नेटवर्क का स्थानीय राउटर होता है।

तीसरा प्लेसहोल्डर, remote_host, VPN सर्वर के पते की ओर इशारा करता है, और यह इसलिए है ताकि सुरंग भौतिक रास्ते से सर्वर तक पहुँच सके। इन तीनों को मिला देना ही सबसे आम कारण है कि कोई छूट गलत जगह जाती है, या इंस्टॉल ही नहीं होती।

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

होस्ट रूट सुरंग के डिफ़ॉल्ट को क्यों हराता है

रूटिंग सबसे विशिष्ट मिलते प्रीफ़िक्स से तय होती है। redirect-gateway def1 आमतौर पर डिफ़ॉल्ट रूट की जगह नहीं लेता; यह दो आधे जोड़ता है, पता-स्थान के निचले आधे के लिए एक रूट और ऊपरी आधे के लिए एक, ताकि मूल डिफ़ॉल्ट रूट दूसरे उपयोगों के लिए सुरक्षित रहे। ये आधे एक अकेले पते से चौड़े हैं।

255.255.255.255 मास्क वाले एक पते का रूट /32 होता है, जो IPv4 की अधिकतम विशिष्टता है। उस पते के लिए पैकेट का मूल्यांकन करते समय /32 मेल खाता है और जीत जाता है, चाहे कौन-सा रूट पहले इंस्टॉल हुआ हो। यही छूट के पीछे की क्रियाविधि है, और जब तक रूट सचमुच मौजूद है, यह Linux, macOS और Windows पर एक जैसा काम करती है।

Windows एक दूसरा आयाम जोड़ता है। जब दो रूट समान रूप से विशिष्ट हों, तो कम मीट्रिक वाला जीतता है, और VPN अडैप्टर ऐसी इंटरफ़ेस मीट्रिक ले जा सकता है जो नतीजा बदल देती है। /32 अब भी आधों से अधिक विशिष्ट है, इसलिए छूट आमतौर पर टिकी रहती है, लेकिन पिछले सत्र का पुराना रूट समान रूप से विशिष्ट हो तो भ्रमित करने वाला नतीजा दे सकता है।

छूट क्या नहीं ढकती

DNS पहला अंतराल है। क्लाइंट आंतरिक रिज़ॉल्वर सेटिंग्स धकेल सकता है, और ऑपरेटिंग सिस्टम उन्हें लुकअप के लिए इस्तेमाल करता रहेगा। कनेक्ट करने से पहले नाम हल करने वाला एप्लिकेशन उस सेवा के लिए आंतरिक पता पा सकता है जिसे सीधे जाना चाहिए, या ऐसा बाहरी पता पा सकता है जो सही ढंग से हल होता है पर फिर अगले अंतराल पर ठोकर खाता है।

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

एप्लिकेशन दायरा तीसरा है। नियम गंतव्य-आधारित है, इसलिए उस पते से जुड़ने वाला हर प्रोसेस सीधा रास्ता इस्तेमाल करता है, चाहे वह आपके मन में हो या न हो। उलटे तौर पर, कोई वेबसाइट कई पतों से जवाब दे सकती है, इसलिए एक /32 को छूट देने से साइट को छूट नहीं मिलती। अगर असली ज़रूरत प्रति-एप्लिकेशन रूटिंग है, तो Community क्लाइंट की रूट तालिका गलत औज़ार है।

खुद को धोखा दिए बिना छूट जाँचना

ब्राउज़र से नहीं, इंस्टॉल किए गए रूट से शुरू करें। Linux पर कर्नेल से पूछें कि वह उस खास पते के लिए कौन-सा रूट और अगली हॉप इस्तेमाल करेगा; Windows पर उस /32 के लिए रूट तालिका पढ़ें। पुष्टि करें कि गेटवे भौतिक है, सुरंग नहीं। अगर प्रविष्टि नहीं है, तो प्रोफ़ाइल लागू नहीं हुआ या क्लाइंट के पास रूट बदलने का अधिकार नहीं था।

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

अंत में, उन नियंत्रणों की जाँच करें जो रूट को दरकिनार कर सकते हैं। क्लाइंट-साइड kill switch या Windows की block-outside-dns सेटिंग सीधे ट्रैफ़िक को मना कर सकती है, जो ऐसे कनेक्शन के रूप में दिखता है जो रूट सही होने पर भी विफल होता है। छूट को काम करता दिखाने के लिए उन नियंत्रणों को बंद न करें; अगर नीति सीधे रास्ते को मना करती है, तो छूट VPN सेवा के मालिक के लिए डिज़ाइन की समस्या है।

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