Android VPN से Cisco IOS तक: पहले वह अनुबंध लें
Cisco IOS गेटवे के लिए Android क्लाइंट स्थापित करने से पहले प्रोटोकॉल, प्रमाणीकरण, पहचान और रूटिंग जुटाएँ। उस चरण के लिए मार्गदर्शिका।
फ़ोन को Cisco गेटवे तक पहुँचना है। किसी ने पहले ही बता दिया है कि कौन-सा क्लाइंट स्थापित करना है। यह प्रक्रिया का गलत सिरा है, और इसीलिए एक घंटे तक क्रेडेंशियल दोबारा टाइप करने के बाद टनल विफल हो जाता है।
पहले आपको कनेक्शन अनुबंध चाहिए: प्रोटोकॉल, प्रमाणीकरण, पहचान, विश्वास सामग्री, पता आवंटन और रूटिंग, जो गेटवे चलाने वाला लिखे।
उसे लिखित में ले लें और क्लाइंट का चयन एक खोज बन जाता है। छोड़ दें तो हर विफलता गलत पासवर्ड जैसी लगती है।
कुछ भी स्थापित करने से पहले जानकारी जुटाएँ
गेटवे के मालिक को सूची भेजें और उत्तर माँगें, उत्पाद का नाम नहीं। नौ मदें रिमोट-एक्सेस प्रोफ़ाइल को पूरी तरह ढकती हैं:
- गेटवे का होस्टनाम या पता जिसे क्लाइंट डायल करे, और क्या वह बाहर से पहुँच योग्य है।
- प्रोटोकॉल और संस्करण: IKEv2, IPsec की कोई दूसरी पीढ़ी, या TLS आधारित सेवा।
- वह पीयर पहचान जिसकी गेटवे अपेक्षा करता है, और वह स्वयं बदले में क्या प्रस्तुत करता है।
- विश्वास सामग्री: कौन-सी CA गेटवे का प्रमाणपत्र हस्ताक्षरित करती है, या पहले से साझा कुंजी उपयोग होती है।
- उपयोगकर्ता प्रमाणीकरण: प्रमाणपत्र, EAP उपयोगकर्ता नाम और पासवर्ड, या पहले से साझा कुंजी।
- वह पता पूल जिसमें क्लाइंट उतरता है, मास्क और गेटवे सहित।
- टनल के भीतर उपयोग होने वाले DNS सर्वर, और क्या क्लाइंट को उन्हें स्वीकार करना है।
- अनुमत गंतव्य उपसर्ग, और क्या उनके बाहर का ट्रैफ़िक अवरुद्ध होना चाहिए।
- समर्थित क्लाइंट संस्करण और फ़ोन के ऑपरेटिंग सिस्टम संस्करण, साथ ही कोई नामांकन आवश्यकता।
इनमें से दो मदें सबसे अधिक टालने योग्य विफलताओं का कारण बनती हैं। विश्वास सामग्री के बिना आप गेटवे को सत्यापित नहीं कर सकते, इसलिए सही क्लाइंट भी खराब दिखता है। अनुमत उपसर्गों के बिना आप रूटिंग प्रतिबंध को सेवा समस्या से अलग नहीं कर सकते।
विक्रेता का नाम प्रोटोकॉल नहीं है
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 पर आ गए। दोनों न चलें तो क्लाइंट को छूने से पहले जिस उपसर्ग का परीक्षण कर रहे हैं उसे अनुमत सूची से मिलाएँ।
विफलता के प्रकार और रोलबैक
| Symptom | Contract item to re-check |
|---|---|
| Profile rejected at import | Protocol or client release unsupported for that service |
| No proposal chosen | IKE version or encryption proposal mismatch |
| Certificate error, correct credentials | Trust material or peer identity |
| Tunnel up, no address | Address pool or authorization on the gateway |
| Tunnel up, names fail | DNS servers or split-tunnel DNS behaviour |
कुछ भी बदलने से पहले पिछली कार्यशील प्रोफ़ाइल को निर्यात और प्रलेखित रखें, जिसमें CA उपनाम और पता पूल शामिल हो। तब रोलबैक का अर्थ ज्ञात प्रोफ़ाइल बहाल करना है, बाधा के दौरान उसे स्मृति से फिर बनाना नहीं।
जब यह चले, तो प्रोफ़ाइल के पास नौ जानकारी-उत्तर लिख लें। अगला फ़ोन, अगला OS अपडेट और अगला गेटवे परिवर्तन—सब दस्तावेज़ से तुलना बन जाते हैं, एक और दोपहर के अनुमान की जगह।