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 प्रविष्टि, दो नहीं;
- प्रोफ़ाइल या ऐप उस सर्वर के नाम पर जिससे वह जुड़ता है;
- पहचान के मान वहाँ लिखे हुए जहाँ आप उन्हें पा सकें।
तालिका में प्रोटोकॉल की पंक्ति से शुरू करें, और अगर वह सवाल का जवाब देती है तो वहीं रुकें।