जुना IOS SSL VPN: पॅकेज, प्रोफाइल, गेटवे, सत्र

तुम्हाला राउटरच्या फ्लॅशवर क्लायंट इंस्टॉलर सापडतो आणि SSL VPN संरचित आहे असा निष्कर्ष तुम्ही काढता. तो चारपैकी एक घटक आहे, आणि उरलेले तीन कोणीही कनेक्ट होऊ शकेल का हे ठरवतात. जुन्या IOS SSL VPN मध्ये भाग वेगवेगळे ऑब्जेक्ट आहेत: हेडएंड क्लायंट पॅकेज, ऐच्छिक क्लायंट प्रोफाइल, TLS संपवणारा WebVPN गेटवे, आणि प्रमाणीकरण व सत्र सेटिंग्ज ठेवणारा कॉन्टेक्स्ट तसेच गट धोरण. एक चुकला तर बाहेरून अपयश सारखेच दिसते.

IOS 15.3 वर AnyConnect 3.1 सह बांधलेले Cisco चे IOS SSL VPN संरचना उदाहरण उपयुक्त आहे कारण ते ती ऑब्जेक्ट वेगळी ठेवते. ते त्या जुन्या अंमलबजावणीचे वर्णन म्हणून वाचा, त्या आवृत्त्या तैनात करण्याची शिफारस म्हणून नाही.

प्रथम, पॅकेज: ते काय आहे आणि काय नाही

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

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

दुसरे, प्रोफाइल: सॉफ्टवेअर नसून सेटिंग्ज

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

दोन्ही आर्टिफॅक्टची यादी करा आणि गेटवे प्रत्यक्षात कोणाचा संदर्भ देतो ते नोंदवा. ती एक ओळ दोन माणसे वेगवेगळ्या फाइलींविषयी बोलत असलेल्या सपोर्ट तिकिटांचा एक वर्ग टाळते.

तिसरे, लिसनर आणि TLS ओळख

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

अपेक्षित ओळख कुठेतरी लिहून ठेवा. नूतनीकृत किंवा बदललेले प्रमाणपत्र हे गेल्या महिन्यात चाललेली तैनाती या महिन्यात थांबण्याचे सर्वात सामान्य कारण आहे.

चौथे, कॉन्टेक्स्ट आणि त्याच्या व्हर्च्युअल टेम्प्लेटसह धोरण

कॉन्टेक्स्ट आणि गट धोरण प्रमाणीकरणाला सत्र वर्तनाशी जोडतात: पत्ता पूल, विभाजित मार्ग, DNS, आणि वापरकर्ता कोणत्या अंतर्गत नेटवर्कपर्यंत पोहोचू शकतो. नोंदवलेले उदाहरण त्याचे कॉन्टेक्स्ट अशा व्हर्च्युअल टेम्प्लेटला जोडते जे प्रत्येक सत्रासाठी इंटरफेस वर्तन पुरवते, आणि ते सर्व्हर-बाजूचे ऑब्जेक्ट वापरकर्ता जे डाउनलोड करतो त्यापासून स्वतंत्रपणे अस्तित्वात असतात.

वापरकर्ता प्रमाणीकृत होतो पण कुठेही पोहोचत नाही तेव्हा दोष सामान्यतः क्लायंटमध्ये नसून इथे असतो. पूल, क्लायंटला दिलेले मार्ग आणि पुढील रहदारीस परवानगी देणारा ACL यांची तुलना करा, आणि रचनेने हेतू ठेवलेल्या गोष्टीशी नाही तर वापरकर्ता जे नोंदवतो त्याशी ते तपासा.

क्रमाने तपासा आणि पहिल्या अपयशावर थांबा

कनेक्शन ज्या क्रमाने त्यांना भेटते त्या क्रमाने चार घटक चाला: लिसनर, प्रमाणीकरण, धोरण, नंतर क्लायंट वर्तन. अपेक्षित ओळखीसह TLS निश्चित करा, ज्ञात चांगले खाते प्रमाणीकृत करा, सत्रातून नेमलेला पत्ता व मार्ग वाचा, आणि त्यानंतरच क्लायंटचा प्लॅटफॉर्म पॅकेजशी तुलना करा. पहिल्या अपयशावर थांबणे खेळात एकच चल ठेवते, आणि दुरुस्ती व अंदाज यातील फरक तोच आहे.

त्या ऐतिहासिक डेस्कटॉप उदाहरणाबाहेरील फोन किंवा कोणत्याही क्लायंटसाठी, Windows प्रवाह सामान्यीकृत होईल असे गृहीत धरण्याऐवजी प्रत्यक्षात समर्थित क्लायंट व गेटवे करार मिळवा. मागितलेला प्रोटोकॉल बदलल्याने IKEv2 प्रोफाइल ही SSL VPN सेवा होणार नाही, आणि डेस्कटॉप पॅकेज स्थापित करणे मोबाइल समर्थनाबद्दल काहीही सिद्ध करत नाही.