एंड्रॉइड घर के IPsec VPN से क्यों जुड़ता है और Windows क्यों नहीं

फ़ोन बिना किसी शिकायत के राउटर के VPN में जुड़ जाता है, जबकि उसी Wi-Fi पर लैपटॉप नहीं जुड़ पाता। वही लॉगिन जानकारी, वही सर्वर, वही मिनट। अंतर प्रोटोकॉल समर्थन का है, पासवर्ड का नहीं: राउटर ऐसा प्रोफ़ाइल दिखाता है जिसे एक ऑपरेटिंग सिस्टम लागू करता है और दूसरे के पास कभी नहीं था।

पहले प्रोफ़ाइल पहचानें, फिर उसकी तुलना करें कि हर क्लाइंट वास्तव में क्या बोलता है।

एक मेन्यू, तीन प्रोटोकॉल

एक ही IPsec शीर्षक के नीचे उपभोक्ता फ़र्मवेयर तीन बिल्कुल अलग सुरंगें छिपा सकता है। पहला IKEv1 है XAUTH के साथ: साझा समूह रहस्य और उसके ऊपर उपयोगकर्ता नाम और पासवर्ड। दूसरा 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 उपलब्ध है, वहाँ वह स्थानांतरण किसी भी क्लाइंट वैकल्पिक उपाय से अधिक मूल्यवान है।

बाहर से भीतर निदान करें

पहले फ़ोन से एक कार्यशील सत्र लें, ताकि लैपटॉप आने से पहले सर्वर पक्ष सिद्ध हो जाए। फिर राउटर का निर्यात किया गया प्रोफ़ाइल बिना बदले आयात करें और राउटर के स्टेटस पृष्ठ के बजाय क्लाइंट लॉग पढ़ें। यदि लॉग कोई बाहर जाता प्रस्ताव नहीं दिखाता, तो लैपटॉप उत्तरदाता तक कभी नहीं पहुँचा। यदि प्रस्तावों का आदान-प्रदान होकर फिर विफलता आती है, तो मतभेद एल्गोरिदम, पहचान या लॉगिन जानकारी पर है।

काम करने वाले फ़ोन प्रोफ़ाइल को नियंत्रण के रूप में रखें। फ़र्मवेयर अपडेट के बाद यदि केवल लैपटॉप टूटता है, तो सर्वर पक्ष पहले जैसा व्यवहार करता है। यदि दोनों टूटते हैं, तो किसी भी क्लाइंट को छूने से पहले प्रमाणपत्र या श्रोता देखें।