एक साथ दो iPhone VPN: आपका ट्रैफ़िक कौन ले जाता है?
iPhone पर दो जुड़े VPN कोई श्रृंखला नहीं हैं। दस्तावेज़ित सहअस्तित्व मॉडल पढ़ें, फिर जाँचें कि कौन-सा कॉन्फ़िगरेशन हर प्रवाह ले जाता है।
दोनों 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 दस्तावेज़ सहअस्तित्व नियम का स्रोत हैं।