एपमा आधारित र गन्तव्यमा आधारित स्प्लिट टनेलिङ: कुन छान्ने

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

दुई नियम फरक तहमा काम गर्छन्

एप नियम नेटवर्क तहमाथि, अपरेटिङ सिस्टमले पठाउनेलाई दिने पहिचानविरुद्ध लागू हुन्छ। 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 प्याकेट पठाउँदा स्ट्याकले उत्तर दिने त्यही प्रश्नको उत्तर दिन्छ। इन्टरफेस टनेल हो भने, नियम मिल्यो।

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