VPN वापरकर्त्याची नोंदणी: आधी ओळखीचा मालक शोधा

कोणीतरी VPN प्रवेश मागतो, आणि पहिली प्रवृत्ती सर्व्हरवर adduser चालवण्याची असते। ती प्रवृत्ती फक्त मोजक्या तैनातींमध्येच बरोबर आहे। काहीही तयार करण्यापूर्वी, सर्व्हरचे कॉन्फिगरेशन उघडा आणि तिथे कोणते उत्पादन चालते आणि ते ओळखपत्रे कुठे सत्यापित करते हे शोधा, कारण खाते उत्पादनाच्या डेटाबेसमध्ये, ओळख पुरवठादाराकडे किंवा होस्टच्या स्वतःच्या प्रमाणीकरण स्टॅकमध्ये असू शकते। चुकीच्या प्रकारचे खाते तयार केल्यास व्यक्तीकडे चालणारे लॉगिन राहते आणि टनेल नाही।

OpenVPN असे म्हणणारे क्लायंट प्रोफाइल प्रोटोकॉलचे वर्णन करते, त्यामागील ओळख प्रणालीचे नाही।

adduser पासून नाही, सर्व्हरपासून सुरुवात करा

आधी उत्पादन ओळखा। Community OpenVPN म्हणजे डेमन आणि तुम्ही त्याला जोडलेले कोणतेही प्रमाणीकरण, तर Access Server हे स्वतःचा वापरकर्ता स्तर असलेले उत्पादन आहे। कॉन्फिगरेशन, युनिटचे नाव आणि पॅकेज यादी मागा, आणि वापरकर्ता व्यवस्थापनासाठी वेब इंटरफेस आहे का ते तपासा। नंतर तैनात प्रोफाइल क्लायंटकडून त्यांची ओळख कशी सिद्ध करायची असे अपेक्षित आहे ते पहा: प्रमाणपत्र, वापरकर्तानाव आणि पासवर्ड, किंवा दोन्ही। तेच उत्तर खात्याचा मालक असलेल्या प्रणालीचे नाव सांगते।

त्यानंतरच वापरकर्ता तयार करणे या वाक्यांशाला अर्थ येतो। फक्त प्रमाणपत्रे असलेल्या तैनातीत याचा अर्थ मंजूर प्रक्रियेद्वारे उपकरणाची ओळख जारी करणे, आणि Unix लॉगिन काहीही बदलत नाही। पासवर्ड तैनातीत याचा अर्थ पासवर्ड खरोखर सत्यापित करणारा बॅकएंड.

चार बॅकएंड, खाते तयार करण्याची चार ठिकाणे

Access Server चे स्थानिक प्रमाणीकरण खाती त्याच्या स्वतःच्या डेटाबेसमध्ये ठेवते, म्हणून ती तयार करण्याचा इंटरफेस होस्टचा नाही, उत्पादनाचा आहे। PAM सत्यापन ऑपरेटिंग सिस्टमच्या स्टॅककडे सोपवते, म्हणून सेवेने तोच स्टॅक निवडला असेल तर स्थानिक Unix खाते नोंदणीचा भाग होऊ शकते। LDAP, RADIUS आणि SAML सत्यापन बाह्य सेवेकडे हलवतात, जिथे प्रोव्हिजनिंग, पासवर्ड धोरण आणि MFA असतात. Access Server चारही प्रकरणांमध्ये वापरकर्त्यानुसार प्रमाणपत्रे आणि परवानग्या ठेवू शकतो, आणि विभाजन गोंधळाचे करणारी गोष्ट तीच आहे।

जागतिक डीफॉल्ट नाही, या विशिष्ट वापरकर्त्यासाठी प्रभावी पद्धत तपासा। Access Server 2.10 आणि नंतरच्या आवृत्त्या गट किंवा वापरकर्त्यानुसार वेगळ्या प्रमाणीकरण पद्धती लागू करू शकतात, म्हणून डीफॉल्ट स्थानिक असणे म्हणजे तुमच्यासमोरचे खाते स्थानिक पातळीवर सत्यापित होते असा पुरावा नाही।

हक्क हा वेगळा निर्णय आहे

प्रमाणीकरण व्यक्ती कोण आहे याचे उत्तर देते; हक्क ती कुठपर्यंत पोहोचू शकते याचे उत्तर देतो। हे दोन टप्पे म्हणून ठेवा, कारण यशस्वी लॉगिन म्हणजे देणगी नाही। इच्छित मार्ग, संसाधन परवानग्या आणि प्रशासकीय हक्क जाणीवपूर्वक द्या, आणि असंबंधित प्रवेश नाकारलेलाच राहतो याची खात्री करा। जिथे तैनाती वैयक्तिक ओळखींना आधार देते, तिथे दुसऱ्याचे प्रोफाइल पुढे पाठवण्याऐवजी प्रत्येक व्यक्तीसाठी एक जारी करा, कारण सामायिक प्रोफाइल एका व्यक्तीसाठी रद्द करता येत नाही।

क्लायंट सामग्रीही महत्त्वाची आहे। स्वयं-लॉगिन प्रोफाइल आणि परस्परसंवादी वापरकर्ता लॉगिन वेगवेगळे प्रमाणीकरण संबंध दर्शवतात, आणि एकाच्या जागी दुसरे आणल्यास सर्व्हर प्रत्यक्षात काय सत्यापित करतो ते बदलते।

प्रवेश रद्द करणे नोंदणीचा भाग आहे

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

नंतर नोंदणी हल्लेखोर जशी करेल तशी तपासा: नव्या ओळखीने एकदा जोडा, इच्छित संसाधनातील प्रवेशाची खात्री करा, आणि असंबंधित संसाधन अजूनही नाकारते याची खात्री करा। चालणारी पहिली जोडणी आणि नकारात्मक चाचणी मिळून पूर्ण नोंदणी होय.

नोंद ती ज्या प्रोफाइलची आहे त्याबरोबर ठेवा। पुढील लेखापरीक्षक विचारेल की दिलेल्या महिन्यात कोण जोडू शकत होते, आणि उत्तर त्या तीन मालकांमध्ये आहे।