Android घरच्या IPsec VPN ला जोडतो पण Windows का जोडत नाही

फोन कोणत्याही तक्रारीशिवाय राउटरच्या VPN मध्ये जातो, पण त्याच Wi-Fi वरील लॅपटॉप जाऊ शकत नाही. तीच लॉगिन माहिती, तोच सर्व्हर, तोच मिनिट. फरक प्रोटोकॉल समर्थनाचा आहे, पासवर्डचा नाही: राउटर असे प्रोफाइल दाखवतो जे एक ऑपरेटिंग सिस्टम राबवते आणि दुसऱ्याकडे कधीच नव्हते.

आधी प्रोफाइल ओळखा, मग प्रत्येक क्लायंट प्रत्यक्षात काय बोलतो त्याशी तुलना करा.

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

एका IPsec शीर्षकाखाली ग्राहक फर्मवेअर तीन पूर्णपणे वेगळ्या बोगद्यांचे लपवू शकते. पहिले XAUTH सह IKEv1 आहे: सामायिक गट रहस्य आणि त्यावर वापरकर्तानाव व पासवर्ड. दुसरे L2TP/IPsec आहे, जिथे PPP सामायिक किल्लीने संरक्षित IPsec वाहतुकीत चालते. तिसरे IKEv2 आहे, प्रमाणपत्रे किंवा EAP ने प्रमाणित.

फील्ड वाचा, लेबल नाही. गट रहस्य आणि वापरकर्ता यादी म्हणजे IKEv1 XAUTH. आधीच सामायिक केलेली किल्ली आणि PPP खाते म्हणजे L2TP/IPsec. गट रहस्य नसलेले सर्व्हर प्रमाणपत्र म्हणजे IKEv2.

फोन आणि लॅपटॉपमधील समर्थनाची दरी

Android मध्ये 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 उपलब्ध आहे, तिथे ते स्थलांतर कोणत्याही क्लायंट पर्यायापेक्षा जास्त मूल्यवान आहे.

बाहेरून आत निदान करा

आधी फोनवरून एक कार्यरत सत्र घ्या, जेणेकरून लॅपटॉप येण्यापूर्वी सर्व्हर बाजू सिद्ध होईल. नंतर राउटरचे निर्यात केलेले प्रोफाइल बदलल्याशिवाय आयात करा आणि राउटरच्या स्थिती पानाऐवजी क्लायंट लॉग वाचा. लॉगमध्ये बाहेर जाणारा प्रस्ताव न दिसल्यास लॅपटॉप उत्तरदात्यापर्यंत कधीच पोहोचला नाही. प्रस्तावांची देवाणघेवाण होऊन नंतर अपयश आल्यास मतभेद अल्गोरिदम, ओळख किंवा लॉगिन माहितीबाबत आहे.

कार्यरत फोन प्रोफाइल नियंत्रण म्हणून ठेवा. फर्मवेअर अपग्रेडनंतर फक्त लॅपटॉप बिघडल्यास सर्व्हर बाजू पूर्वीप्रमाणे वागते. दोन्ही बिघडल्यास कोणत्याही क्लायंटला स्पर्श करण्यापूर्वी प्रमाणपत्र किंवा श्रोत्याकडे पाहा.