Mac वर SonicWall VPN: SSL क्लायंट की मूळ L2TP?

Mac पासून सुरुवात करा आणि नंतर बाहेरच्या दिशेने जा, कारण क्लायंटचा निर्णय फायरवॉल घेतो आणि तो फक्त डेस्कटॉपवर प्रतिबिंबित होतो। सिस्टम सेटिंग्ज उघडा, आधीच कोणते VPN कॉन्फिगरेशन आहे ते पहा, आणि पासवर्ड टाइप करण्यापूर्वी प्रशासकाला एक प्रश्न विचारा। उत्तर सक्षम रिमोट-ॲक्सेस सेवा आहे, लॉगिन पृष्ठावरील उपकरण मॉडेल नाही। एका लॅपटॉपवर दोन क्लायंट असू शकतात आणि त्यापैकी एकही योग्य नसू शकतो।

कोणती सेवा सुरू आहे हे गेटवेला विचारा

एकाच उत्पादन नावाखाली दोन रिमोट-ॲक्सेस सेवा दिसतात आणि त्या पूर्णपणे वेगळ्या पद्धतीने वागतात। एक SSL VPN आहे ज्यावर विक्रेत्याच्या क्लायंटने पोहोचता येते, आणि दुसरी IPsec किंवा L2TP आहे जी macOS चा अंगभूत क्लायंट डायल करू शकतो। त्या पोर्ट, प्रमाणीकरण आणि पत्ता वाटपात भिन्न आहेत, म्हणून एकाचे प्रोफाइल दुसऱ्यासाठी निरुपयोगी आहे। फक्त Mac बाजूने निवडणे हे कॉन्फिगरेशनच्या वेशातील अंदाज आहे।

एकाच वेळी तीन गोष्टी मागा: परवानाधारक आणि सक्षम सेवा, ती सेवा macOS वर ज्या क्लायंट आणि आवृत्तीला समर्थन देते, आणि ती अपेक्षित असलेला प्रमाणीकरण प्रवाह। यापेक्षा कमी काहीही पुढील अपयशात तुम्हाला अंदाज लावायला लावते।

मूळ L2TP चा मार्ग चाला

Mac वर प्रोफाइल जोडलेले असताना मूळ कनेक्शन असते, आणि सेटिंग्ज पॅनेल ते Wi-Fi आणि Ethernetच्या शेजारी दाखवते। जर यादी रिकामी असेल तर मशीनमध्ये कोणतेही VPN कॉन्फिगरेशन नाही आणि समस्या कनेक्टिव्हिटीत नाही, तर तरतुदीत आहे। खालील आदेश सिस्टम प्रत्यक्षात काय ठेवते ते छापते, इंटरफेस लपवू शकणाऱ्या कॉन्फिगरेशनसह।

काहीही जोडण्यापूर्वी आउटपुट वाचा, कारण परिचित नावाचे जुने प्रोफाइल नवीन सेटअप दुर्लक्षित वाटण्याचे सामान्य कारण आहे। नंतर सर्व्हरचा पत्ता प्रशासकाने दिलेल्या पत्त्याशी तुलना करा, जुन्या तिकिटातील पत्त्याशी नाही। दोन्ही तपासण्या एक मिनिट घेतात आणि नेहमीच्या दोन बंद मार्ग काढून टाकतात।

scutil --nc list
networksetup -listallnetworkservices

मूळ L2TP नोंदीसाठी सामायिक गुपित, वापरकर्तानाव आणि पासवर्ड, आणि अपेक्षित पोर्टवर ती सेवा देणारा गेटवे देखील आवश्यक आहे। त्यापैकी कोणतेही नसल्यास, Mac प्रमाणीकरण त्रुटी किंवा सर्व्हर प्रतिसाद देत नाही अशी त्रुटी नोंदवते, आणि कोणताही संदेश चुकीच्या गुपिताला कधीही सक्षम न केलेल्या सेवेपासून वेगळा करत नाही। प्रशासकासोबत नोंदी ताडून पाहताना तीनही मूल्ये एकत्र ठेवा।

SSL क्लायंटचा मार्ग चाला

SSL VPN क्लायंट TLS द्वारे पोर्टलशी जोडतो, नंतर स्वतःची बोगदा आणि स्वतःची पत्ता धोरण चालवतो। त्याला पोर्टलचा पत्ता, खाते आणि तैनाती लादते तो दुसरा घटक आवश्यक आहे, आणि तो प्रथमच चालवताना सामान्यतः नेटवर्क विस्तार स्थापित करतो। एका क्लायंटसाठी निर्यात केलेले प्रोफाइल दुसऱ्यात आयात होणे दुर्मिळ आहे, जरी दोन्ही खाली IPsec बोलत असले तरी। विस्तार मंजूर होईपर्यंत यापैकी काहीही सिस्टम सेटिंग्जच्या VPN यादीत दिसत नाही।

शेजारी शेजारी स्थापित दोन SSL क्लायंट एकाच नेटवर्क विस्तारासाठी स्पर्धा करू शकतात, आणि आधी लोड झालेला सामान्यतः जिंकतो। मंजूर क्लायंट स्थापित करण्यापूर्वी न वापरलेला क्लायंट काढा, नंतर विस्तार यादी पुन्हा तयार होण्यासाठी रीबूट करा।

स्थापित करण्यापूर्वी macOS आवृत्ती विक्रेत्याच्या सध्याच्या समर्थन विधानाशी तपासा, आणि इंस्टॉलर गोपनीयता आणि सुरक्षितता मध्ये मंजुरी मागेल अशी अपेक्षा ठेवा। अवरोधित विस्तार कधीही सुरू न होणाऱ्या कनेक्शनसारखाच दिसतो।

रीब्रँडिंग सूचना योग्यरित्या वाचा

क्लायंटची नावे बदलतात, आणि नाव बदलणे हे प्रोटोकॉल बदल नाही। विक्रेत्याची सूचना की Mobile Connect आता NetExtender होत आहे ब्रँडिंगचे वर्णन करते, म्हणून डेस्कटॉप प्लॅटफॉर्म समर्थनाबद्दलचे जुने विधान नवीन नाव असलेल्या प्रत्येक ॲपवर लागू करता येत नाही।

तुम्ही प्रत्यक्षात स्थापित केलेला क्लायंट बंडल ओळखकर्ता आणि आवृत्तीद्वारे ओळखा, आयकॉनवरील लेबलद्वारे नाही। हा फरक तुमच्या Mac वर कोणते समर्थन मॅट्रिक्स लागू होते हे ठरवतो।

सक्षम सेवा आणि समर्थित Mac क्लायंट यांच्यात कोणताही ओव्हरलॅप नसल्यास, प्रामाणिक पर्याय म्हणजे मंजूर पर्यायी सेवा किंवा नियोजित गेटवे बदल। एका लॅपटॉपला संतुष्ट करण्यासाठी सामायिक धोरण पुन्हा लिहिणे, किंवा फोरमच्या उत्तराने त्याचा उल्लेख केला म्हणून ॲप खरेदी करणे, सुसंगततेचा प्रश्न जिथे सुरू झाला तिथेच ठेवते।