एकै पटक दुई 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 कागजात सहअस्तित्व नियमको स्रोत हो।