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 अद्यावधिक र अर्को गेटवे परिवर्तन सबै दस्तावेजसँगको तुलना बन्छन्, अर्को दिउँसोको अनुमानको सट्टा।