स्प्लिट टनेलिङले कुन ट्राफिकले VPN प्रयोग गर्छ भनेर कसरी निर्धारण गर्छ

स्प्लिट टनेलिङ भनेको नियमहरूको समूहका रूपमा व्यक्त गरिएको रुटिङ नीति हो, र क्लाइन्ट भनेको तिनीहरूलाई स्थापना गर्ने कुरा मात्र हो। विभाजन दुई ठाउँमा हुन्छ: प्रत्येक प्याकेटका लागि बाटो छान्ने मिलान नियमहरू, र तालिका जे भने पनि एप्लिकेसनलाई एउटै इन्टरफेसमा राख्ने बाइन्डिङहरू। तपाईंको क्लाइन्ट कुन मेकानिजममा निर्भर छ भन्नेले मानिसहरूले रिपोर्ट गर्ने अधिकांश अचम्म व्याख्या गर्छ।

एक लाइनमा भन्न सकिने नीति परीक्षणयोग्य हुन्छ। छिटो ब्राउजिङ भनेर वर्णन गरिएको नीति त्यस्तो हुँदैन, र अनुरोध गलत दिशामा गएपछि कुन नियम बदल्ने भनेर त्यसले भन्दैन।

क्लाइन्टले नियम स्थापना गर्छ, कर्नेलले छनोट गर्छ

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

त्यसैले स्प्लिट टनेल स्वेच्छाचारी देखिन सक्छ। एउटै एपका दुई गन्तव्य फरक बाटो लिन सक्छन्, केवल एउटा प्रिफिक्स अर्कोभन्दा साँघुरो भएर।

त्यही छनोट प्रत्येक प्लेटफर्ममा छ, नामहरू बदलिए पनि। Windows ले निर्णय आफ्नो फिल्टर प्लेटफर्ममा धकेल्छ, Android ले आफ्नो VPN सेवामार्फत प्रति-एप अनुमति सूची देखाउँछ, र macOS ले रुटिङ तालिका अझै मान्ने यन्त्रसँग टनेल जोड्छ। Microsoft का रुटिङ नोटहरू Windows अवस्थाका लागि पढ्नयोग्य छन्, र एउटा प्लेटफर्मका लागि लेखिएको गाइड परिवर्तनबिना अर्कोमा जान्छ भन्ने विरलै हुन्छ।

प्रति-एप बाइन्डिङ र गन्तव्य प्रिफिक्स फरक औजार हुन्

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

नाममा आधारित नीतिलाई कुनै पनि दृष्टिकोणले सहायताबिना टिकाउन सक्दैन। ठूला साइटका ठेगानाहरू सामग्री सञ्जालहरूबीच घुम्छन्, त्यसैले होस्टनामलाई केही प्रिफिक्समा पिन गर्दा चुपचाप मिल्न छोड्ने नियम बन्छ। नामहरू पछ्याउनुपर्ने नीतिलाई स्थिर रुटको सट्टा रिजोल्भर-सचेत घटक चाहिन्छ।

DNS र किल स्विच आफ्नै नियम पछ्याउँछन्

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

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

दुवैतर्फबाट विभाजन जाँच्नुहोस्

समावेश गरिएको बाटो र बहिष्कृत बाटो छुट्टाछुट्टै परीक्षण गर्नुहोस्, र नतिजा सार्वजनिक ठेगानाबाट होइन, इन्टरफेस नामबाट निर्णय गर्नुहोस्। यी आदेशहरूले टनेल यन्त्र पहिले नै माथि भएको Linux होस्ट मान्छन्। 203.0.113.10 लाई तपाईंको नीतिले भित्र रुट गर्ने गन्तव्यले, र 198.51.100.25 लाई त्यसले बाहिर पठाउने गन्तव्यले बदल्नुहोस्।

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

पहिलो दुई उत्तर सँगै पढ्नुहोस्, किनभने प्रत्येकमा नाम दिइएको इन्टरफेसले त्यो गन्तव्य टनेलमा राखिएको छ कि छैन देखाउँछ। रिजोल्भर प्रश्नले आन्तरिक नाममा कुन सर्भरले उत्तर दियो देखाउँछ, र अन्तिम आदेशले टनेल यन्त्रले अनुरोध बोक्न सक्छ भनेर प्रमाणित गर्छ। पहिलो लाइन सफल हुँदा दोस्रोमा असफलता भन्नुको अर्थ नीतिले भनिएको कुरा ठ्याक्कै गरिरहेको छ।

पुनः जडानपछि र सञ्जाल परिवर्तनपछि समूह दोहोर्याउनुहोस्। लिज नवीकरण र इन्टरफेसको हलचल ती ठाउँ हुन् जहाँ विभाजन आफू निर्माण गरिएको उद्देश्यसँग मिल्न छोड्छ, र प्रत्येक रनको सुरक्षित आउटपुटले विचलन स्पष्ट पार्छ।