फक्त समाविष्ट करा किंवा फक्त वगळा स्प्लिट टनेलिंग: डीफॉल्ट कोणता?
यादी तयार करण्यापूर्वी डीफॉल्ट ठरवा: तुम्ही नाव देतात तेच टनेलमधून पाठवा, किंवा सर्व पाठवून अपवाद कापून काढा. मग कोणीही यादीत न घातलेले अॅप तपासा.
तुमच्या 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 टनेलमधून अजिबात न जाणाऱ्या रहदारीसाठी अंतर्गत नावे सुटतात का हे ठरवते। यादीतले अॅप, यादीत नसलेले अॅप, एक नाव शोध आणि एक पुन्हा जोडणी चालवा, आणि निकाल संरचनेसोबत ठेवा।
डीफॉल्ट पुढच्या माणसाला सापडेल तिथे लिहा
निवडलेला डीफॉल्ट, अपवाद आणि त्यांचा मालक क्लायंट प्रोफाइल असलेल्याच ठिकाणी नोंदवा, कारण पुढचा प्रशासक हे कारण न वाचता नोंद जोडेल। तारीख आणि प्रत्येक अपवादाचे कारण नोंदवा, म्हणजे नंतर दुरुस्त झालेल्या साइटसाठीचा जुना अपवाद आत्मविश्वासाने काढता येईल। कारण नसलेली यादी अंतहीन वाढते।
कोणी एक बिघडलेले गंतव्य नोंदवले की पाया नाही, अपवाद बदला। एक साइट दुरुस्त करण्यासाठी डीफॉल्ट उलटवल्यास यादीत नसलेली प्रत्येक अॅप गुपचूप टनेलच्या दुसऱ्या बाजूला सरकते।