पुरानो 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 सेवा बनाउँदैन, र डेस्कटप प्याकेज स्थापना गर्नाले मोबाइल समर्थनबारे केही प्रमाणित गर्दैन।