एउटा 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 अघिको गेटवे र उपलब्ध बाटो प्रोफाइलका नभई क्षणका गुण हुन्।