दोन्ही VPN ॲप्स Connected दाखवतात, आणि रहदारी आता दोन्हींमधून जाते, एक दुसऱ्याच्या आत असे गृहीत धरले जाते। सहसा असे होत नाही। iOS ला विशिष्ट सहअस्तित्व मॉडेल आहे, आणि ते साखळी नाही। एक कॉन्फिगरेशन वर्ग एकाच सुरू केलेल्या इन्स्टन्सपुरता मर्यादित आहे, दुसरा त्याच्या शेजारी चालू शकतो, आणि मार्ग प्राधान्य संघर्ष ठरवते। दोन चालू स्विचेस दोन हॉप्स नाहीत। मॉडेल दस्तऐवजीकृत आहे, म्हणजे आयकॉनमधून अंदाज करण्याऐवजी मार्ग आधीच ठरवता येतो।

गैरसमज: दोन जोडलेले VPN एक साखळी आहेत

दोन-हॉप साखळीसाठी निश्चित बाह्य वाहतूक, निश्चित आंतरिक बोगदा, सुसंगत एंडपॉइंट राउटिंग आणि दोन्हींपैकी एक अयशस्वी झाल्यास काय होईल याची योजना आवश्यक आहे। दोन स्वतंत्र कॉन्फिगरेशन एकाच वेळी असण्यानेच ते तयार करत नाहीत। मार्ग प्राधान्य एन्कॅप्सुलेशनसारखे नाही, आणि एका कॉन्फिगरेशनचा मार्ग शोध जिंकणे हे दुसरे परिणामी पॅकेट वाहून नेते की नाही याबद्दल काहीही सांगत नाही।

तुम्हाला नेस्टिंग हवे असल्यास ते नेस्टिंग म्हणून रचा। दोन कनेक्शन निर्देशकांवरून त्याचा अंदाज लावू नका। हा फरक भरपूर डीबगिंग वाचवतो।

त्या गैरसमजामागील दस्तऐवजीकृत मॉडेल

Apple चे NETunnelProviderManager नेहमीच्या एंटरप्राइझ VPN कॉन्फिगरेशनचे वर्णन करते आणि सांगते की त्या प्रकारचे एकच एकाच वेळी सुरू करता येते। तेच संदर्भ Personal VPN ला त्याच्या शेजारी सुरू आणि जोडलेले राहू देतात, आणि दोन्ही ओव्हरलॅप होतात तिथे एंटरप्राइझ मार्गांना प्राधान्य देतात।

येथे Personal VPN म्हणजे NEVPNManager द्वारे व्यवस्थापित अंगभूत IPsec किंवा IKEv2 अंमलबजावणीची API संज्ञा। NETunnelProviderManager हे बोगदा-पुरवठादार मॉडेल आहे। ग्राहक ॲप पुरवठादार मॉडेल वापरू शकते, म्हणून personal असलेले उत्पादन नाव त्याचे वर्गीकरण करत नाही।

Apple एका परवानगीयोग्य संयोजनाचे दस्तऐवजीकरण करते, आणि परवानगी दोन विक्रेत्यांचे प्रोफाइल सुसंगत आहेत असे सांगत नाही, म्हणून कोणती जोडी समर्थित आहे हे प्रत्येक विक्रेत्याला विचारा। त्यांचे कॉन्फिगरेशन प्रकार, मार्ग आणि धोरणे अजूनही निकाल ठरवतात।

गैरसमज: वैयक्तिक VPN ला ब्राउझिंग रहदारी मिळते

प्रत्येक गंतव्याचा दावा करणारे कार्य प्रोफाइल सार्वजनिक ब्राउझिंगसाठीचा मार्ग शोधही जिंकेल, म्हणून वैयक्तिक एक्झिट त्यातून काहीही वाहून नेते नाही। दस्तऐवजीकृत प्राधान्यानुसार एंटरप्राइझ मार्ग जिथे भिडतात तिथे जिंकतात, म्हणून सार्वजनिक ब्राउझिंग ते ॲपही जोडलेले असल्याचे नोंदवते या कारणाने आपोआप वैयक्तिक एक्झिट घेत नाही। अरुंद कार्य कॉन्फिगरेशन राउटिंग चित्र बदलू शकते, पण संस्थेचा क्लायंट अजूनही DNS, ब्लॉकिंग किंवा डिव्हाइसच्या आवश्यकता लादू शकतो। समर्थित व्यवस्था तिच्या मालकाकडून घ्या, त्या आवश्यकता स्थानिक पातळीवर संपादित करण्याऐवजी।

व्यवस्थापित प्रति-ॲप कॉन्फिगरेशनची स्वतःची व्याप्ती आहे। डिव्हाइस-स्तरीय नियम प्रत्येक व्यवस्थापित तैनातीपर्यंत वाढवू नका।

चाचणीपूर्वी दोन्ही प्रवाह लिहा: कार्य सेवेचे खाजगी नाव आणि श्रेणी, आणि नवीन सार्वजनिक ब्राउझिंग विनंती। दोन्ही वैध आहेत, आणि दोन्हींना वेगवेगळ्या तपासण्या लागतात।

विभाजित बोगद्याचे कार्य प्रोफाइल आणि मार्ग प्राधान्य

विभाजित बोगद्याचे कार्य प्रोफाइल त्याच्या सूचीबद्ध खाजगी उपसर्गांचा आणि अंतर्गत DNS प्रत्ययाचा दावा करते, आणि ते मार्ग त्यांच्याशी जुळणारा कोणताही शोध जिंकतात। कोणत्याही एंटरप्राइझ मार्गाशी न जुळणारी सार्वजनिक गंतव्ये वैयक्तिक VPN आधी दावा करत नसेल तर भौतिक दुव्यावर पडतात। प्राधान्य नियम फक्त ओव्हरलॅपिंग जुळण्या ठरवतो, म्हणून दोन्ही प्रोफाइल आयकॉन म्हणून नाही तर मार्ग तक्ते म्हणून वाचली पाहिजेत।

जोडी दोन ओळींत लिहा आणि प्रत्येकासाठी अपेक्षित विजेत्याचे नाव द्या: 10.x किंवा 172.16.x मध्ये सोडवले जाणारे कार्य होस्ट नाव एंटरप्राइझ बोगद्यातून बाहेर पडावे, आणि जुळणारा उपसर्ग नसलेल्या सार्वजनिक पत्त्याने उर्वरित डीफॉल्ट मार्ग घ्यावा। दोन्ही ओळींनी एकच एक्झिट नाव दिले तर विभाजन दस्तऐवजात वर्णन केल्याप्रमाणे करत नाही।

दोन प्रवाह लिहा आणि प्रत्येक तपासा

प्रत्येक प्रवाहासाठी, कोणते मंजूर कॉन्फिगरेशन तो वाहून नेले पाहिजे आणि कोणता निराकरणकर्ता प्रत्येक प्रकारचे नाव घेतले पाहिजे याची नोंद करा। नंतर कॅशे केलेले कार्य पृष्ठ किंवा जुना IP निकाल न वापरता नवीन विनंत्या घेऊन पडताळा।

एक कॉन्फिगरेशन थांबवा आणि दोन्ही प्रवाह पुन्हा करा। अयशस्वीतेचे वर्तन रचनेचा भाग आहे, आणि तोच वापरकर्त्यांच्या लक्षात येणारा भाग आहे। दोन्ही पुरवठादार संयोजनाला आधार देऊ शकत नसल्यास, एका मंजूर कॉन्फिगरेशनवर थांबा आणि ते कोणता प्रवाह वाहून नेते याचे दस्तऐवजीकरण करा, किंवा व्यवस्थापित एकल-बोगदा रचनेकडे जा। NETunnelProviderManager दस्तऐवज सहअस्तित्व नियमाचा स्रोत आहेत।

संबंधित लेख