गेल्या आठवड्यात एका सहकाऱ्याने मला त्याचा 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 givenDevice situationWhat to use
An .ovpn or WireGuard configPersonal phoneProvider app; the native form cannot load it
IKEv2 host plus CA namePersonal or managedProfile, or the app's own IKEv2 mode
IKEv2 with username and secretPersonal phoneEither; the profile is simpler if you never switch servers
A management-installed profileSupervised, MDMNative client; do not add a second app entry
A per-app tunnelling requirementPersonal phoneApp, or accept a full tunnel; iOS cannot split by app without management
IPsec blocked on your main networkAnyApp with a transport that survives the block

दोन ओळी दुसऱ्या नजरेस पात्र आहेत। वैयक्तिक फोनवरील प्रति-ॲप आवश्यकता हे असे प्रकरण आहे जे लोक चुकीचे वाचतात: सेटिंग iOS मध्ये आहे पण व्यवस्थापन ती चालवते, त्यामुळे व्यवस्थापित नसलेले डिव्हाइस ती देणार नाही। अडवलेले नेटवर्क IKEv2 वर अविश्वासाचे कारण नाही; हेच कारण आहे की प्रदात्याचे ॲप अस्तित्वात आहे।

एका चाचणीने निवड सत्यापित करा

अयशस्वी होण्याच्या पद्धती तपासा, कनेक्ट बटण नाही। एकदा जोडा, VPN निर्देशक दिसतो याची खात्री करा, नंतर तुमचा सार्वजनिक पत्ता परत देणारे पृष्ठ उघडा आणि मागील पत्त्याशी तुलना करा। VPN ला हात न लावता Wi-Fi वरून मोबाइल डेटावर जा आणि पुनर्कनेक्शन पाहा, नंतर फोनला एअरप्लेन मोडमधून जाऊ द्या। पुन्हा सुरू करा आणि टनेल स्वतः परत येतो का पाहा: OnDemandEnabled असलेले प्रोफाइल परत आले पाहिजे, तर अनेक ॲप आधी उघडावे लागतात।

जेव्हा तो परत येत नाही, तेव्हा बिघाड टनेल आहे की नाही यावर विभागा। VPN निर्देशक नसणे म्हणजे टनेल कधीच उभा राहिला नाही: एकतर हँडशेक RemoteIdentifier, पिन केलेल्या CA किंवा क्रेडेन्शियलवर अयशस्वी झाला, किंवा कनेक्शनचा प्रयत्नच झाला नाही कारण मागणीनुसार नियम जुळला नाही आणि कोणत्याही ॲपने तो सुरू केला नाही। निर्देशक असेल पण रहदारी अयशस्वी असेल तर ते राउटिंग, DNS किंवा सर्व्हर-बाजू धोरण आहे, आणि क्लायंट पुन्हा स्थापित करणे यापैकी कशालाही लागत नाही।

डिव्हाइस पुढच्या व्यक्तीसाठी समजावता येण्याजोगे ठेवण्यासाठी छोटी यादी:

  • एक VPN नोंद, दोन नाही;
  • प्रोफाइल किंवा ॲप ज्या सर्व्हरशी जोडते त्याच्या नावाने;
  • ओळखीची मूल्ये जिथे तुम्हाला सापडतील तिथे लिहिलेली।

तक्त्यातील प्रोटोकॉल ओळीपासून सुरुवात करा, आणि जर ती प्रश्नाचे उत्तर देते तर तिथेच थांबा।

संबंधित लेख