केवल समावेश वा केवल बहिष्कार स्प्लिट टनेलिङ: कुन पूर्वनिर्धारित?
सूची बनाउनु अघि पूर्वनिर्धारित छान्नुहोस्: तपाईंले नाम दिएको मात्र टनेलमा पठाउनुहोस्, वा सबै पठाएर अपवाद काटेर निकाल्नुहोस्। त्यसपछि कसैले पनि सूचीमा नराखेको एप परीक्षण गर्नुहोस्।
आफ्नो VPN क्लाइन्टको राउटिङ खण्ड खोल्नुहोस् र तपाईंले प्रायः एउटै लेबल लगाएका, आकार फरक भएका दुई नियन्त्रण देख्नुहुन्छ। एउटाले टनेलभित्र पर्ने गन्तव्यहरू सूचीबद्ध गर्न भन्छ र बाँकी सबै स्थानीय सञ्जाल प्रयोग गरिरहन्छ। अर्कोले सबै टनेलबाट जान्छ भनी मानेर के बाहिर काट्ने भनी सोध्छ। दुवैले पहिलो परीक्षणमा चल्ने टनेल दिन्छन् र दुवै सूचीमा हरफ थपेर मर्मत गरिन्छन्, त्यसैले कोही नयाँ कुरा स्थापना नगरेसम्म फरक देखिँदैन।
यो सुविधा होइन, पूर्वनिर्धारितको छनोट हो। सूचीमा बीस प्रविष्टि हुनुअघि यो टुङ्गो लगाउनुहोस्।
पूर्वनिर्धारित ब्रोसरबाट होइन, क्लाइन्टबाट पढ्नुहोस्
WireGuard मा यो निर्णय असाधारण रूपमा देखिन्छ, किनभने AllowedIPs समावेश सूची मात्र हो, अरू केही होइन। 0.0.0.0/0, ::/0 भएको पियरले सबै टनेल गर्छ, अनि 10.20.0.0/16 भएको पियरले त्यो सञ्जाल मात्र टनेल गर्छ। बहिष्कार वाक्यविन्यास छैन, त्यसैले एउटा सबनेट बाहिर राख्न चाहनुभयो भने बाँकी सबै प्रिफिक्स गन्नुपर्छ वा इन्टरफेसबाहिर नीतिगत राउटिङ थप्नुपर्छ।
OpenVPN विपरीत दिशाबाटै त्यही ठाउँमा पुग्छ: redirect-gateway def1 पूरा टनेल बनाउँछ र छुट्टै route निर्देशनहरूले निश्चित प्रिफिक्स थप्छन् वा पुनः लेख्छन्। व्यापारिक क्लाइन्टहरूले प्रायः दुवैलाई चेकबक्स र गन्तव्य तालिकाभित्र लुकाउँछन्, त्यसैले लेबलमा विश्वास गर्नुअघि तालिकाले वास्तवमा कुन सम्पादन गर्छ पढ्नुहोस्।
सोध्नुपर्ने कुरा चेकबक्सको नाम होइन। दुवै सूचीमा नभएको गन्तव्य भएको प्याकेटलाई के हुन्छ भन्ने हो। त्यसको लिखित उत्तर दिनुहोस्, बाँकी कन्फिगरेसन त्यहीँबाट निस्कन्छ। यो प्रश्न छोड्नुभयो भने पहिलो अस्पष्ट बिग्रेपछि त्यो दिन क्लाइन्टको सबैभन्दा नजिकको मान्छेले निर्णय गर्नेछ।
कसैले पनि सूचीमा नराखेको एप पछ्याउनुहोस्
केवल समावेश ढाँचामा त्यो एप स्थानीय सञ्जाल र स्थानीय DNS प्रयोग गरी सिधै जान्छ। केवल बहिष्कार ढाँचामा यो सर्भरले अनुमति दिएसम्म टनेलबाट जान्छ, र नयाँ SaaS उपकरण पहिलो दिन चल्ने कि VPN ले बिगार्यो भन्ने टिकट खुल्ने भन्ने फरक प्रायः यहीँ हुन्छ।
कुनै पनि पूर्वनिर्धारित आफैंमा बढी सुरक्षित हुँदैन। केवल समावेशले टनेलले बोक्ने दायरा साँघुरो बनाई स्थानीय सञ्जाललाई सबैभन्दा कम प्रतिरोधको बाटो बनाउँछ, अनि केवल बहिष्कारले टनेललाई सामान्य बाटो मानी अपवादलाई अपवादकै रूपमा लिन्छ, जुन धेरै कर्पोरेट नीतिले वास्तवमा खोजेको कुरा नजिक छ।
| Question | Include-only | Exclude-only |
|---|---|---|
| Unlisted new app | goes direct | goes through the tunnel |
| A site that breaks over the VPN | add it to the list | carve it out |
| Internal names still resolve | only if routed and served | usually, until split DNS says otherwise |
| Upkeep | one entry per internal service | one entry per misbehaving public service |
प्लेटफर्मले कस्ता वस्तु सूचीबद्ध गर्छ ध्यान दिनुहोस्
Android को VpnService.Builder अनुमति दिइएका एपको सूची र रोकिएका एपको सूचीलाई दुई छुट्टै मोडेलका रूपमा खोल्छ, र प्रत्येक एपका नियमले गन्तव्यले होइन, प्याकेजले छनोट गर्छ। यस्तो सूचीमा राखिएको ब्राउजरले खोल्ने हरेक गन्तव्य सँगै बोक्छ, यो राउट तालिकाभन्दा फरक सूक्ष्मता हो र चलिरहेको एपभित्रको एउटा बिग्रेको साइट पनि सुधार्न सक्दैन।
डेस्कटप क्लाइन्टहरूले प्रायः दुवै प्रकार एउटै इन्टरफेसमा मिसाउँछन्, त्यसैले तपाईंले थपिरहेको हरफ प्याकेज हो, होस्ट नाम हो वा प्रिफिक्स हो जाँच्नुहोस्। ती फरक तरिकाले बिग्रन्छन् र फरक ठाउँमा समाधान हुन्छन्। होस्ट नामको हरफ प्रायः राउट र नाम बन्छ, अनि प्याकेजको हरफ क्लाइन्टभित्रको नीति निर्णय बन्छ। कुन थप्नुभयो लेख्नुहोस्, किनभने पछि डिबग गर्नेले अर्कै मानेर हिँड्छ।
असफलताको अवस्था जाँच्नुहोस्, सहज बाटो मात्र होइन
टनेलबाट बाहिर राखिएको एपले स्वतः सफा सिधा पहुँच पाउँदैन। यदि क्लाइन्टले VPN बिना ब्लक गर्ने नियम पनि लागू गर्छ भने बाहिर राखिएको ट्राफिक पूरै खारेज हुन सक्छ, र त्यो राउटिङ निर्णय होइन, बिग्रेको एपजस्तो देखिन्छ। त्यो अवस्था प्रयोगकर्ताको उजुरीबाट थाहा पाउनुको सट्टा जानाजान परीक्षण गर्नुहोस्।
त्यसपछि DNS र IPv6 छुट्टाछुट्टै कुराका रूपमा जाँच्नुहोस्। केवल IPv4 बोक्ने टनेलले v6 सक्षम एपलाई वरिपरि जाने बाटो छोड्छ, र split DNS ले टनेलबाटै नजाने ट्राफिकका लागि आन्तरिक नाम समाधान हुन्छन् कि भन्ने तय गर्छ। सूचीमा भएको एप, सूचीमा नभएको एप, एउटा नाम खोज र एउटा पुनः जडान चलाउनुहोस्, र नतिजा कन्फिगरेसनसँगै राख्नुहोस्।
पूर्वनिर्धारित अर्को मान्छेले भेट्ने ठाउँमा लेख्नुहोस्
छानिएको पूर्वनिर्धारित, अपवादहरू र तिनका मालिक क्लाइन्ट प्रोफाइल भएकै ठाउँमा अभिलेख गर्नुहोस्, किनभने अर्को प्रशासकले यो तर्क नपढी प्रविष्टि थप्नेछ। मिति र प्रत्येक अपवादको कारण लेख्नुहोस्, ताकि पछि सुधारिएको साइटका लागि पुरानो अपवाद विश्वासका साथ हटाउन सकियोस्। कारण नभएको सूची असीमित बढ्छ।
कसैले एउटा बिग्रेको गन्तव्य रिपोर्ट गरेपछि आधार होइन, अपवाद बदल्नुहोस्। एउटा साइट सुधार्न पूर्वनिर्धारित उल्टाउँदा सूचीमा नभएका सबै एप चुपचाप टनेलको अर्को छेउमा सर्छन्।