iPhone मा VPN एप वा अन्तर्निहित IKEv2: कसरी छान्ने
iPhone को VPN एप र अन्तर्निहित IKEv2 क्लाइन्टले फरक फरक समस्या समाधान गर्छन्। पहिले प्रोटोकल समर्थन, प्रमाणीकरण, यन्त्र नियन्त्रण र पुनःप्राप्ति तुलना गर्नुहोस्।
गत हप्ता एक सहकर्मीले मलाई आफ्नो iPhone दिए, सेटिङमा दुई VPN प्रविष्टि थिए: एउटा प्रदायक एपले छाडेको, अर्को सहायता पृष्ठबाट टाँसिएको IKEv2 प्रोफाइलको। यी एउटै कुराका प्रतिस्पर्धी संस्करण होइनन्। प्रदायक एप एउटा कन्टेनर हो जसले आफ्नै सुरुङ कोड बोक्न सक्छ, जबकि Apple को अन्तर्निहित क्लाइन्ट IKEv2 क्लाइन्ट हो, हातले वा प्रोफाइलद्वारा कन्फिगर गरिने। प्रोटोकल, प्रमाणहरूको व्यवस्थापन, यन्त्र नियन्त्रण र पुनःप्राप्तिले छनोट निर्धारण गर्छन्।
एप र मूल क्लाइन्ट फरक तहमा छन्
Apple को अन्तर्निहित VPN क्लाइन्ट व्यवहारमा IKEv2 क्लाइन्ट हो। हातले भरिने फारम अझै अप्रचलित IPsec माथि L2TP र Cisco IPsec विकल्प सूचीबद्ध गर्छ, तर प्रदायक ट्रान्सपोर्टका लागि फिल्ड र OpenVPN वा WireGuard कन्फिगरेसन टाँस्ने ठाउँ छैन। तपाईं या त सेटिङ > सामान्य > VPN & यन्त्र व्यवस्थापनमा फारम भर्नुहुन्छ या VPN पेलोड भएको प्रोफाइल आयात गर्नुहुन्छ; सतह सर्भर ठेगाना, दुई पहिचान, एक प्रमाणीकरण विधि र वैकल्पिक माग अनुसारका नियम हुन्।
प्रदायक एप एक तह माथि काम गर्छ। यसले Network Extension प्याकेट सुरुङ प्रदायक दिन्छ, त्यसैले प्रोटोकल कोड र राउटिङ तर्क एपमा बस्छन् र iOS ले प्याकेट मात्र पठाउँछ। केही एपले WireGuard वा OpenVPN लागू गर्छन्, केहीले आफ्नै अस्पष्ट ट्रान्सपोर्ट, र केहीले मात्र IKEv2 प्रोफाइल स्थापना गरेर मूल क्लाइन्टलाई राम्रो स्क्रिनपछाडि चलाउँछन्। यही अन्तिम समूहका कारण एप वा प्रोफाइलको छनोट कहिलेकाहीँ झुटो हुन्छ।
नतिजा व्यावहारिक छ: .ovpn वा WireGuard फाइलले ती फिल्ड प्रतिस्थापन गर्दैन, किनकि ह्यान्डसेक अर्को प्रोटोकल हो।
सुविधा तुलना गर्नु अघि पेलोड पढ्नुहोस्
जब प्रोफाइल IKEv2 हुन्छ, पेलोडका कुञ्जीहरूले कुनै पनि सुविधा तुलनाभन्दा बढी खराबी व्याख्या गर्छन्। Apple को IKEv2 सेटिङ सन्दर्भ ले हरेक कुञ्जीको दस्तावेजीकरण गर्छ; छोटो पारिएको पेलोड यस्तो देखिन्छ:
<key>VPNType</key><string>IKEv2</string>
<key>RemoteAddress</key><string>vpn.example.net</string>
<key>RemoteIdentifier</key><string>vpn.example.net</string>
<key>LocalIdentifier</key><string>[email protected]</string>
<key>AuthenticationMethod</key><string>Certificate</string>
<key>ServerCertificateIssuerCommonName</key><string>Example Issuing CA</string>तीन फिल्डले निदानात्मक भारको ठूलो भाग बोक्छन्। RemoteIdentifier त्यो नाम हो जुन क्लाइन्टले सर्भरबाट अपेक्षा गर्छ, त्यसैले NAT पछाडिको गेटवे वा जसको प्रमाणपत्रले ठेगानाको सट्टा पूल नाम दिन्छ त्यस्तो लोड ब्यालेन्सर ठेगाना सही हुँदा पनि असफल हुन्छ। LocalIdentifier त्यो पहिचान हो जुन सर्भरले तपाईंलाई ठान्छ, र प्रमाणपत्र प्रमाणीकरणमा त्यो तपाईंको खातासँग जोडिएको पहिचानसँग मिल्नुपर्छ। ServerCertificateIssuerCommonName जारी गर्ने CA पिन गर्छ, त्यसैले प्रमाणपत्र पुनः जारी हुने दिन प्रोफाइल असफल हुन सक्छ, र कुनै त्रुटि सन्देशमा प्रमाणपत्रको उल्लेख हुँदैन।
यदि AuthenticationMethod SharedSecret बराबर छ भने, सर्भरले EAP प्रयोगकर्ता प्रमाणीकरण गरिरहेको छ र तपाईंलाई दिइएको गोप्य कुरा वास्तवमा खाता प्रमाण हो। यो तब महत्त्वपूर्ण हुन्छ जब प्रदायकले दुई कागजात पठाउँछ, एउटा प्रयोगकर्ता नाम र पासवर्डका लागि र अर्को प्रमाणपत्रका लागि, र एउटा मात्र तपाईंको आयातसँग मिल्छ।
एपले के गर्न सक्छ र मूल क्लाइन्टले गर्न सक्दैन
प्रोटोकलको छनोट स्पष्ट फाइदा हो। यदि तपाईंको सर्भर WireGuard वा OpenVPN बोल्छ भने, एप मात्र त्यस्तो iOS क्लाइन्ट हो जसले यो प्रयोग गर्न सक्छ, र मूल फारम सम्पादन गर्दा यसमा वार्ता हुँदैन। एपले गन्तव्य वा एप अनुसार विभाजित सुरुङ, आफ्नै DNS व्यवस्थापन, kill switch शैलीको रोक, सर्भर छनोट र आफ्नै नेटवर्कमा मिलाइएको पुनःजडान पनि लागू गर्न सक्छ।
मूल्य त्यो सफ्टवेयर हो जसको तपाईंले अडिट गर्नुभएको छैन र जो नेटवर्क एक्सटेन्सनका विशेषाधिकारमा चल्छ। गुणस्तर स्टोर कार्डले संकेत गरेभन्दा बढी बदलिन्छ: एउटा एप सफा पुनः जोडिन्छ जबकि अर्को नेटवर्क परिवर्तनपछि केही सेकेन्ड चुहिन्छ, र एपभित्रको kill switch त्यही एपको सुविधा हो, iOS को होइन। व्यवस्थापित यन्त्रमा पहिले स्वीकृत सूची जाँच्नुहोस्।
अन्तर्निहित IKEv2 प्रोफाइलले के सही गर्छ
कम चल्ने भागहरू नै सम्पूर्ण तर्क हुन्। IKEv2 क्लाइन्ट र यसको IPsec स्ट्याक प्रणालीसँगै आउँछन्, त्यसैले क्र्यास हुन सक्ने एक्सटेन्सन छैन, हरेक एपका लागि जीवित राख्नुपर्ने प्रक्रिया छैन, र तपाईं र काम गर्ने सुरुङबीच तेस्रो पक्षको अद्यावधिक चक्र छैन। प्रोफाइल लक पनि गर्न सकिन्छ: निरीक्षित यन्त्रमा प्रयोगकर्ताले व्यवस्थापनले स्थापना गरेको कुरा हटाउन सक्दैन, र प्रयोगकर्ता स्विचबिना कुनै पनि नेटवर्कमा पुनः जोडिने Always On VPN त्यही निरीक्षित, प्रोफाइल-व्यवस्थापित रूपमा मात्र अवस्थित छ।
अन्तर्निहित बाटोले नदिने कुरा लचिलोपन हो। व्यवस्थापित एपबिना प्रति-एप VPN छैन, प्रयोगकर्ताका लागि kill switch छैन, र IPsec अवरुद्ध गर्ने नेटवर्कमा HTTPS जस्तो देखिने ट्रान्सपोर्ट छैन। UDP 500 र 4500 छाड्ने होटेल नेटवर्कमा अन्तर्निहित IKEv2 सँग वैकल्पिक बाटो छैन।
अधिकांश अवस्था टुंग्याउने निर्णय तालिका
व्यवहारमा प्रोटोकलको प्रश्नले सुविधाहरू महत्त्वपूर्ण हुनुअघि नै अधिकांश अवस्था टुंग्याउँछ।
| What you were given | Device situation | What to use |
|---|---|---|
| An .ovpn or WireGuard config | Personal phone | Provider app; the native form cannot load it |
| IKEv2 host plus CA name | Personal or managed | Profile, or the app's own IKEv2 mode |
| IKEv2 with username and secret | Personal phone | Either; the profile is simpler if you never switch servers |
| A management-installed profile | Supervised, MDM | Native client; do not add a second app entry |
| A per-app tunnelling requirement | Personal phone | App, or accept a full tunnel; iOS cannot split by app without management |
| IPsec blocked on your main network | Any | App with a transport that survives the block |
दुई पङ्क्ति दोस्रो नजरका लायक छन्। व्यक्तिगत फोनमा प्रति-एप आवश्यकता त्यो अवस्था हो जुन मानिसहरूले गलत पढ्छन्: सेटिङ iOS मा छ तर व्यवस्थापनले चलाउँछ, त्यसैले व्यवस्थापित नभएको यन्त्रले त्यो दिँदैन। अवरुद्ध नेटवर्क IKEv2 मा अविश्वासको कारण होइन; यही कारण हो कि प्रदायकको एप अवस्थित छ।
एउटा परीक्षणले छनोट प्रमाणित गर्नुहोस्
असफलताका तरिका जाँच्नुहोस्, जडान बटन होइन। एकचोटि जोडिनुहोस्, VPN सूचक देखिन्छ भनी पुष्टि गर्नुहोस्, त्यसपछि तपाईंको सार्वजनिक ठेगाना फर्काउने पृष्ठ खोलेर अघिल्लोसँग तुलना गर्नुहोस्। VPN लाई नछोइकन Wi-Fi बाट मोबाइल डेटामा जानुहोस् र पुनःजडान हेर्नुहोस्, त्यसपछि फोनलाई एयरप्लेन मोडबाट गुजार्नुहोस्। पुनः सुरु गर्नुहोस् र सुरुङ आफै फर्किन्छ कि हेर्नुहोस्: OnDemandEnabled भएको प्रोफाइल फर्किनुपर्छ, जबकि धेरै एप पहिले खोल्नुपर्छ।
जब त्यो फर्किँदैन, असफलतालाई सुरुङ छ कि छैन भन्ने आधारमा बाँड्नुहोस्। VPN सूचक नहुनु भनेको सुरुङ कहिल्यै उठेन: या त ह्यान्डसेक RemoteIdentifier, पिन गरिएको CA वा प्रमाणमा असफल भयो, या जडानको प्रयास नै भएन किनकि माग अनुसारको नियम मिलेन र कुनै एपले त्यो सुरु गरेन। सूचक छ तर ट्राफिक असफल छ भने त्यो राउटिङ, DNS वा सर्भर-पक्ष नीति हो, र क्लाइन्ट पुनः स्थापना गर्दा यीमध्ये कुनैलाई छुँदैन।
यन्त्र अर्को व्यक्तिका लागि बुझ्नयोग्य राख्न छोटो सूची:
- एउटा VPN प्रविष्टि, दुई होइन;
- प्रोफाइल वा एप जुन सर्भरसँग जोडिन्छ त्यसको नाममा;
- पहिचानका मान तपाईंले भेट्न सक्ने ठाउँमा लेखिएका।
तालिकाको प्रोटोकल पङ्क्तिबाट सुरु गर्नुहोस्, र यदि त्यसले प्रश्नको उत्तर दिन्छ भने त्यहीँ रोकिनुहोस्।