एन्ड्रोइड घरको IPsec VPN मा किन जोडिन्छ तर Windows जोडिँदैन

फोन कुनै गुनासो बिना राउटरको VPN मा पस्छ, तर त्यही Wi-Fi मा रहेको ल्यापटप पस्न सक्दैन। उही लगइन विवरण, उही सर्भर, उही मिनेट। फरक प्रोटोकल समर्थनको हो, पासवर्डको होइन: राउटरले एउटा प्रोफाइल देखाउँछ जुन एउटा अपरेटिङ सिस्टमले लागू गर्छ र अर्कोसँग कहिल्यै थिएन।

पहिले प्रोफाइल पहिचान गर्नुहोस्, त्यसपछि प्रत्येक क्लाइन्टले वास्तवमा के बोल्छ त्यससँग तुलना गर्नुहोस्।

एउटा मेनु, तीन प्रोटोकल

एउटै IPsec शीर्षकमुनि उपभोक्ता फर्मवेयरले तीन पूर्ण फरक सुरुङ लुकाउन सक्छ। पहिलो XAUTH सहित IKEv1 हो: साझा समूह रहस्य र त्यसमाथि प्रयोगकर्ता नाम र पासवर्ड। दोस्रो L2TP/IPsec हो, जहाँ PPP साझा कुञ्जीले सुरक्षित IPsec यातायातभित्र चल्छ। तेस्रो IKEv2 हो, प्रमाणपत्र वा EAP बाट प्रमाणित।

फिल्ड पढ्नुहोस्, लेबल होइन। समूह रहस्य र प्रयोगकर्ता सूची भनेको IKEv1 XAUTH। पहिले साझा गरिएको कुञ्जी र PPP खाता भनेको L2TP/IPsec। समूह रहस्य नभएको सर्भर प्रमाणपत्र भनेको IKEv2।

फोन र ल्यापटपबीचको समर्थन खाडल

एन्ड्रोइडमा IKEv1 XAUTH PSK क्लाइन्ट पहिले नै हुन्छ, र त्यसैले अरू केही नदिने राउटरविरुद्ध फोन सफल हुन्छ। Windows मा छैन: यसको मूल क्लाइन्टले L2TP/IPsec र IKEv2 सम्हाल्छ, र सक्रिय गर्न IKEv1 XAUTH विकल्प छैन। रहस्य फेरि हाल्नाले सहयोग गर्दैन, किनभने छुटेको भाग प्रोटोकल हो, लगइन विवरण होइन।

Apple पक्ष चलिरहने लक्ष्य हो। नयाँ macOS र iOS संस्करणहरू IKEv2 तिर ढल्कन्छन्, पुराना Cisco शैलीका प्रोफाइल केही बिल्डमा बाँच्छन्, र अपग्रेडले गत महिना चलेको कुरा हटाउन वा कडा बनाउन सक्छ। हिजो जोडिने र आज नजोडिने Mac, राउटर नबदली, सामान्यतया यही हो।

सही प्रोफाइल भाँच्ने दुई सेटिङ

Synology को L2TP/IPsec पृष्ठले Enable SHA2-256 compatible mode (96 bit) भन्ने चेकबक्स दिन्छ। iOS 14 र macOS Big Sur देखि Apple का क्लाइन्टहरूले त्यो काटिएको मोड अस्वीकार गर्छन्, त्यसैले तिनीहरूका लागि बक्स बन्द हुनुपर्छ। खुला रहे सुरुङ प्रमाणित भएर त्यसपछि खस्छ, जुन खराब लगइन विवरणजस्तो देखिन्छ तर होइन। निर्माताले स्विचको दस्तावेजीकरण गर्छ, र अपरेटिङ सिस्टम अपग्रेड नै यो महत्त्वपूर्ण हुन थाल्ने क्षण हो।

Windows ले प्रमाणपत्र दुई छुट्टै भण्डारमा राख्छ, र IKEv2 ले मेसिनको मात्र पढ्छ। क्लाइन्ट प्रमाणपत्र निजी कुञ्जीसहित कम्प्युटर खातामा आयात गर्नुहोस्; आफ्नै प्रयोगकर्ता खातामुनि राखिएको प्रमाणपत्र व्यवस्थापन कन्सोलमा देखिन्छ तर IKEv2 सेवासम्म कहिल्यै पुग्दैन। EAP-TLS मात्र यस्तो अवस्था हो जहाँ प्रयोगकर्ता प्रमाणपत्र उपयोगी हुन्छ, र हस्ताक्षर गर्ने CA मेसिनले अझै विश्वास गर्नुपर्छ। यहाँ गल्ती गरेमा प्रमाणीकरण असफलता देखिन्छ, हराएको प्रमाणपत्रको अनुरोध होइन।

राउटर जस्ताको तस्तै रहँदा

केवल XAUTH PSK बोल्ने राउटरले तीन बाटो छोड्छ: निर्माताको क्लाइन्ट, अझै प्रोफाइल लागू गर्ने तेस्रो पक्षको क्लाइन्ट, वा सुरुङको अन्त्य IKEv2 बोल्ने कुरामा सार्नु। उदाहरणका लागि AVM आफ्ना राउटरका लागि Windows क्लाइन्ट सफ्टवेयर र निर्यात गरिएको कन्फिगरेसन फाइल प्रकाशित गर्छ। त्यो बाटो समर्थित छ, र यसको अर्थ हरेक ल्यापटपमा निर्माताको उपकरण स्थापना गर्नु हो।

ल्यापटप तपाईंका होइनन् भने पुनः बनाउन, समर्थन सुन्दरताभन्दा महत्त्वपूर्ण छ।

सुरक्षा लागत पनि तौल्नुहोस्। एउटा समूह रहस्यले सबै प्रयोगकर्ता ढाक्छ, त्यसैले जससँग छ उसले सर्भरको ठाउँमा उभिएर क्लाइन्टले दिने प्रयोगकर्ता नाम र पासवर्ड समात्न सक्छ। जहाँ प्रमाणपत्रसहित IKEv2 उपलब्ध छ, त्यहाँ त्यो स्थानान्तरण कुनै पनि क्लाइन्ट विकल्पभन्दा बढी मूल्यवान छ।

बाहिरबाट भित्र निदान गर्नुहोस्

पहिले फोनबाट एउटा काम गर्ने सत्र लिनुहोस्, ताकि ल्यापटप आउनुअघि सर्भर पक्ष प्रमाणित होस्। त्यसपछि राउटरको निर्यात गरिएको प्रोफाइल नबदली आयात गर्नुहोस् र राउटरको स्थिति पृष्ठको सट्टा क्लाइन्ट लग पढ्नुहोस्। लगमा बाहिर जाने प्रस्ताव नदेखिए ल्यापटप उत्तरदातासम्म कहिल्यै पुगेन। प्रस्ताव आदानप्रदान भएर त्यसपछि असफल भए मतभेद एल्गोरिदम, पहिचान वा लगइन विवरणमा छ।

चल्ने फोन प्रोफाइललाई नियन्त्रणका रूपमा राख्नुहोस्। फर्मवेयर अपग्रेडपछि मात्र ल्यापटप बिग्रिए सर्भर पक्ष पहिलेजस्तै व्यवहार गर्छ। दुवै बिग्रिए कुनै पनि क्लाइन्ट छुनुअघि प्रमाणपत्र वा श्रोतालाई हेर्नुहोस्।