अॅप-आधारित vs गंतव्य-आधारित स्प्लिट टनेलिंग: काय निवडावे

अॅप-आधारित आणि गंतव्य-आधारित स्प्लिट टनेलिंग एकाच कामाच्या दोन सेटिंग नाहीत. एक विचारते कोणती प्रक्रिया पॅकेट पाठवत आहे; दुसरे विचारते ते पॅकेट कुठे जात आहे. पहिल्या प्रश्नासाठी बनवलेला नियम ट्रॅफिक सहाय्यक प्रक्रियेतून आल्यावर शांतपणे अयशस्वी होतो, आणि दुसऱ्यासाठी बनवलेला नियम होस्टनाव तुम्ही कधीही सूचीबद्ध न केलेल्या पत्त्यावर सोडवले जाते तेव्हा अयशस्वी होतो. आवश्यकतेशी जुळणारी वस्तू निवडा, नंतर दोन चाचणी पॅकेटने ते सिद्ध करा: एकाने टनेल वापरायला हवे आणि दुसऱ्याने नाही.

दोन नियम वेगवेगळ्या स्तरांवर काम करतात

अॅप नियम नेटवर्क स्तराच्या वर, ऑपरेटिंग सिस्टम पाठवणाऱ्याला दिलेल्या ओळखीविरुद्ध लागू होतो. 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 पॅकेट पाठवताना स्टॅक ज्या प्रश्नाचे उत्तर देईल त्याच प्रश्नाचे उत्तर देते. इंटरफेस टनेल असेल, तर नियम जुळला.

नंतर वगळायचे दुसरे पॅकेट दुसऱ्या अॅप्लिकेशनमधून त्याच गंतव्याकडे तपासा. तिकिटात क्लायंट आवृत्ती, नियमाचा प्रकार, प्रीफिक्स किंवा पॅकेज सूची आणि दिसलेले दोन निकाल नोंदवा. तोच निकालांचा जोड पुढील अभियंत्याला सांगतो की धोरण चुकीचे संरचित आहे की ट्रॅफिक कधीच त्याचे नव्हते.