Android VPN ते Cisco IOS: आधी घ्यायचा करार

फोनला Cisco गेटवेपर्यंत पोहोचायचे आहे. कोणता क्लायंट स्थापित करायचा हे कुणीतरी आधीच सांगितले आहे. तो प्रक्रियेचा चुकीचा टोक आहे, आणि म्हणूनच एक तास क्रेडेन्शियल पुन्हा टाइप केल्यावर टनेल अयशस्वी होते.

आधी तुम्हाला कनेक्शन करार हवा: प्रोटोकॉल, प्रमाणीकरण, ओळख, विश्वास सामग्री, पत्ता वाटप आणि राउटिंग, जो गेटवे चालवणारा लिहील.

तो लिखित स्वरूपात मिळाला तर क्लायंटची निवड फक्त शोध बनते. तो वगळला तर प्रत्येक अयशस्वीता चुकीच्या पासवर्डसारखी वाटते.

काहीही स्थापित करण्यापूर्वी माहिती गोळा करा

गेटवेच्या मालकाला यादी पाठवा आणि उत्पादनाचे नाव नाही, उत्तरे मागा. नऊ मुद्दे रिमोट-अ‍ॅक्सेस प्रोफाइल पूर्णपणे व्यापतात:

1. क्लायंटने डायल करायचे गेटवेचे होस्टनाव किंवा पत्ता, आणि ते बाहेरून पोहोचण्यायोग्य आहे का.
2. प्रोटोकॉल आणि आवृत्ती: IKEv2, IPsec ची दुसरी पिढी, किंवा TLS आधारित सेवा.
3. गेटवे अपेक्षित असलेली पीअर ओळख, आणि ते स्वतः बदल्यात काय सादर करते.
4. विश्वास सामग्री: कोणते CA गेटवेच्या प्रमाणपत्रावर स्वाक्षरी करते, किंवा आधीच सामायिक केलेली किल्ली वापरली जाते का.
5. वापरकर्ता प्रमाणीकरण: प्रमाणपत्र, EAP वापरकर्तानाव आणि पासवर्ड, किंवा आधीच सामायिक केलेली किल्ली.
6. क्लायंट ज्या पत्ता पूलमध्ये उतरतो, मास्क आणि गेटवेसह.
7. टनेलमध्ये वापरण्याचे DNS सर्व्हर, आणि क्लायंटने ते स्वीकारावे का.
8. परवानगी दिलेली गंतव्य उपसर्ग, आणि त्यांच्या बाहेरील रहदारी अवरोधित करावी का.
9. समर्थित क्लायंट आवृत्त्या आणि फोनच्या ऑपरेटिंग सिस्टम आवृत्त्या, तसेच नोंदणीची आवश्यकता असल्यास ती.

या मुद्द्यांपैकी दोन सर्वाधिक टाळता येण्याजोग्या अयशस्वीतेस कारणीभूत ठरतात. विश्वास सामग्रीशिवाय तुम्ही गेटवेची पडताळणी करू शकत नाही, त्यामुळे बरोबर क्लायंटही खराब दिसतो. परवानगी दिलेल्या उपसर्गांशिवाय तुम्ही राउटिंग मर्यादा आणि सेवा समस्या वेगळी करू शकत नाही.

विक्रेत्याचे नाव प्रोटोकॉल नाही

Cisco IOS आणि IOS XE अनेक रिमोट-अ‍ॅक्सेस व्यवस्था देतात, आणि त्या एकच वायर फॉरमॅट सामायिक करत नाहीत. FlexVPN शैलीच्या प्रोफाइलसह IKEv2 जुन्या IKEv1 कॉन्फिगरेशनसारखी सेवा नाही, आणि TLS आधारित क्लायंट सेवा हे पुन्हा दुसरे उत्पादन आहे, बहुतेक वेळा त्याच वातावरणातील दुसऱ्या प्लॅटफॉर्मवर.

म्हणून ज्या क्लायंटच्या नावात राउटर विक्रेत्याचा उल्लेख आहे तो काहीही सिद्ध करत नाही. तो त्या सेवांपैकी एक चांगल्या प्रकारे अंमलात आणू शकतो आणि बाकीच्या नाही. कोणती सेवा कॉन्फिगर केलेली आहे ते विचारा, नंतर क्लायंटचे दस्तऐवज त्या सेवेचा समर्थित असा उल्लेख करतात का ते तपासा.

Cisco चे स्वतःचे IKEv2 दस्तऐवज प्रस्ताव, धोरण, प्रोफाइल आणि किल्ली-वलय वेगवेगळ्या वस्तू म्हणून विभक्त करतात. एखाद्याने तुमच्यासमोर पेस्ट केलेले कॉन्फिगरेशन वाचताना ही रचना उपयुक्त असते: संपूर्ण फाइल एक गठ्ठा मानण्याऐवजी दूरच्या फोनसाठी महत्त्वाच्या सेटिंग्ज कोणत्या वस्तूत आहेत ते सांगते.

Android चा अंगभूत स्टॅक काय व्यापतो

Android प्लॅटफॉर्मचे IKEv2/IPsec प्रोफाइल Ikev2VpnProfile द्वारे उघड करते, आधीच सामायिक केलेली किल्ली, RSA प्रमाणपत्र आणि EAP वापरकर्तानाव-पासवर्डसाठी वेगळे प्रमाणीकरण प्रकारांसह. Ikev2VpnProfile संदर्भ हा बिल्डर काय स्वीकारतो याचा अधिकृत स्रोत आहे, त्यात गेटवेचे होस्टनाव आणि ते पडताळण्यासाठी वापरले जाणारे सर्व्हर रूट CA समाविष्ट आहे.

ती API क्षमतेचे विधान आहे, सुसंगततेचे वचन नाही. त्या प्रमाणीकरण प्रकारांसह प्लॅटफॉर्म IKEv2 करू शकते असे ते सांगते. एखादी विशिष्ट OEM सेटिंग्ज स्क्रीन प्रत्येक फील्ड दाखवते, किंवा दुसऱ्या उत्पादनातून निर्यात केलेली प्रोफाइल फाइल आयात होईल असे ते सांगत नाही.

याचा अर्थ असाही की गेटवे प्लॅटफॉर्मने अंमलात न आणलेली सेवा चालवत असेल तर अंगभूत स्टॅक तुम्हाला वाचवणार नाही. त्या बाबतीत ऑपरेटरने समर्थित विक्रेत्याचा क्लायंट हवा, ऑपरेटरच्या दस्तऐवजानुसार स्थापित आणि कॉन्फिगर केलेला, फोन ज्याच्याशी बोलत नाही अशा प्रोटोकॉलवर बांधलेला मार्ग नाही.

करार ज्या क्रमाने लिहिला आहे त्याच क्रमाने चाचणी करा

एका वेळी एक स्तर पडताळा आणि पहिल्या अयशस्वीतेवर थांबा, कारण आधीचे उत्तीर्ण होईपर्यंत पुढील चाचण्या अर्थहीन आहेत.

विश्वास. क्लायंटने गेटवेचे प्रमाणपत्र नाकारले तर बाकी काही महत्त्वाचे नाही. तुम्हाला दिलेले CA गेटवे सादर करते त्या प्रमाणपत्रावर स्वाक्षरी करते आणि तुम्ही डायल केलेले होस्टनाव त्यात आहे याची खात्री करा. पडताळणी सुरू ठेवा; ती बंद करणे ओळखीची समस्या अडवणुकीच्या जोखमीत बदलते.

प्रमाणीकरण. नाकारलेले क्रेडेन्शियल आणि न जुळणारा प्रस्ताव वेगळ्या त्रुटी पण दिसायला सारख्याच अयशस्वीता देतात. गेटवेचा लॉग निर्णायक आहे: वापरकर्त्याबद्दल काही सांगण्यापूर्वी प्रस्ताव स्वीकारार्ह होता का ते सांगेल.

पत्ता आणि DNS. फोनला दस्तऐवजी पूलमधून पत्ता मिळाला याची खात्री करा, नंतर एक अंतर्गत नाव सोडवा. पत्त्यासह पण रिझॉल्व्हरशिवाय वर येणारे टनेल जोडलेले दिसते आणि काहीच चालत नसल्यासारखे वागते.

पोहोच. एका परवानगी दिलेल्या गंतव्याची चाचणी पत्त्याने, नंतर नावाने करा. पत्ता चालतो पण नाव चालत नाही तर तुम्ही पुन्हा DNS वर आहात. दोन्ही चालत नाहीत तर क्लायंटला स्पर्श करण्यापूर्वी तुम्ही चाचणी करत असलेला उपसर्ग परवानगी दिलेल्या यादीशी तुलना करा.

अयशस्वीतेचे प्रकार आणि रोलबॅक

काहीही बदलण्यापूर्वी आधीची कार्यरत प्रोफाइल निर्यात केलेली आणि दस्तऐवजी ठेवा, CA उपनाव आणि पत्ता पूलसह. मग रोलबॅक म्हणजे ज्ञात प्रोफाइल पुनर्संचयित करणे, अडथळ्यादरम्यान स्मरणातून ती पुन्हा बांधणे नाही.

ते चालले की प्रोफाइलजवळ नऊ गोळा-उत्तरे लिहून ठेवा. पुढचा फोन, पुढचे OS अपडेट आणि पुढचा गेटवे बदल—सर्व दस्तऐवजाशी तुलना बनतात, अजून एका दुपारच्या अंदाजाऐवजी.