VPN गटात वापरकर्ता जोडल्याने स्वतः प्रवेश मिळत नाही
गट सदस्यत्व ही एक अट आहे, परवानगी नाही. गेटवेने प्रत्यक्षात काय जुळवले ते पहा, स्वीकार किंवा नकार नोंद वाचा आणि दोन्ही निकाल तपासा.
खाते योग्य गटात आहे, लॉगिन यशस्वी झाले, तरीही कनेक्शन नाकारले जाते किंवा काही उपयुक्त गाठत नाही. काही सैल होईपर्यंत अधिक गट जोडणे ही नेहमीची प्रतिक्रिया, आणि अशा रीतीने संस्था तिकिटाने मागितलेल्यापेक्षा कितीतरी अधिक अधिकार देतात. गट सदस्यत्व हे अधिकृतता निर्णयाचे एक इनपुट आहे, कधीही निर्णय नाही: गेटवे सत्राची काही तथ्ये गोळा करते, क्रमबद्ध धोरणाशी जुळवते आणि मगच सत्र कशाला स्पर्श करू शकेल हे ठरवते. दुसरी अट अपयशी झाली तर गट बदलल्याने फक्त तुमचे प्रदर्शन बदलते.
गट सदस्यत्व अट आहे, परवानगी नाही
RADIUS मध्ये गट अधिकृतता गुणधर्म म्हणून येतो, आणि गुणधर्म सत्राचे वर्णन करतात, परवानगी देत नाहीत. सर्व्हर Access-Accept किंवा Access-Reject ने उत्तर देतो; स्वीकारताना Filter-Id, Class किंवा RFC 2868 मधील बोगदा गुणधर्म जोडू शकतो, आणि पलीकडील नेटवर्क उपकरण उत्पादकाच्या निर्णयानुसार त्यांचा अर्थ लावते. प्रोटोकॉलमध्ये गटाला पूर्ण प्रवेशात बदलणारे काहीही नाही; ते मॅपिंग गेटवे किंवा नेटवर्क प्रवेश सर्व्हरवर धोरण ठरवणारा लिहितो.
म्हणूनच एकच गटनाव दोन प्रणालींवर वेगळे वागते. Microsoft NPS अटी, मर्यादा आणि सेटिंग्जमधून नेटवर्क धोरणे तयार करून ठरलेल्या क्रमाने मूल्यांकन करते. OpenVPN Access Server चे स्वतःचे गट व प्रवेश नियम मॉडेल आहे, तर समुदाय OpenVPN सर्व्हर बहुतेकदा संपूर्ण प्रश्न client-connect स्क्रिप्ट किंवा client-config-dir फाइलकडे सोपवतो.
ठरवते ते जुळलेला नियम, तुम्ही अपेक्षिलेला गट नाही
बहुतेक इंजिन पहिल्या जुळणाऱ्या धोरणावर किंवा सर्वात विशिष्ट धोरणावर थांबतात. धोरण 3 नकार देत असेल आणि धोरण 7 परवानगी देत असेल, तर सत्र ते पार करणाऱ्या नियमापर्यंत न पोहोचताच अपयशी होऊ शकते. क्रम हा NPS आणि बहुतेक नेटवर्क प्रवेश नियंत्रण उत्पादनांमध्ये खरा सेटिंग आहे.
गटासोबत जाणाऱ्या अटी उरलेला अर्धा भाग: उपकरणाची स्थिती, प्रमाणीकरण पद्धत, पूर्ण MFA, स्रोत नेटवर्क, प्रमाणपत्राचा विषय किंवा वेळ खिडकी. एकही पूर्ण न झाल्यास धोरण जुळत नाही, इंजिन पडते आणि मूलभूत नकार लागू होतो. वापरकर्त्याच्या बाजूने गट दुर्लक्षित वाटतो; इंजिनच्या बाजूने गटाला विचारलेच नाही.
डिरेक्टरी तपशील तोच भ्रम निर्माण करतात. Windows गट सदस्यत्वावर जुळणारे धोरण टोकनमधील SID वाचते, तिथे फक्त सुरक्षा गट सूचीबद्ध असतात; वितरण गट कधीच दिसत नाही. प्राथमिक गट स्वतंत्र क्षेत्रात असतो, त्यामुळे त्याला जोडलेले धोरण शांतपणे अपयशी होऊ शकते.
गटाला हात लावण्यापूर्वी स्वीकार किंवा नकार नोंद वाचा
आधी एक प्रश्न: विनंती अधिकृतता टप्प्यापर्यंत पोहोचली का? NPS वर उत्तर इव्हेंट लॉगमध्ये आहे, जिथे 6272 दिलेला प्रवेश, 6273 नकार आणि 6274 धोरण मूल्यांकनापूर्वी सर्व्हरने टाकून दिलेली विनंती नोंदवते. ते तीन आकडे समस्या तीन तपासण्यांत विभागतात, आणि फक्त एक गटांबद्दल आहे.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
लॉग उपलब्ध नसल्यास सर्व्हरला थेट विचारा आणि तो काय परत देतो ते वाचा. Filter-Id आणि बोगदा गुणधर्म नसलेले उत्तर म्हणजे सर्व्हर सत्र सामान्य मानतो आणि गेटवे स्वतःचे नियम लावतो. अंमलबजावणी बिंदू अमलात न आणणाऱ्या गुणधर्मांसह उत्तर वेगळी बिघाडी: अधिकृतता पार गेली आणि उपकरणाने निकाल दुर्लक्षित केला.
radtest alice 'password' 10.0.0.5 0 testing123परत आलेल्या गुणधर्मांची गेटवे दस्तऐवजीकरण करते त्याशी तुलना करा, गटनाव सुचवते त्याशी नाही. ती तुलना सहसा धोरणाची समस्या अंमलबजावणीच्या समस्येपासून वेगळी करते.
गट बदल मागेपर्यंत लागू होत नाही
अधिकृतता गुणधर्म सत्र प्रमाणित होताना एकदाच परत येतात. गेटवे ते सत्रावर ठेवते आणि प्रत्येक पॅकेटसाठी डिरेक्टरी पुन्हा वाचत नाही, म्हणून एखाद्याला गटातून काढल्यावरही प्रस्थापित सत्र चालू राहते.
बदल लागू होण्यासाठी नवा अधिकृतता निर्णय हवा, फक्त नव्या किल्ल्या नाहीत. सर्व्हर RFC 5176 ला आधार देत असेल तर UDP 3799 वर Disconnect-Request किंवा CoA-Request सत्र पुनर्मूल्यांकनास भाग पाडते; नाहीतर क्लायंट तोडून पुन्हा जोडू द्या. पुनर्वाटाघाटी बोगदा किल्ल्या ताज्या करते आणि अधिकृतता निकाल सहसा अक्षत ठेवते.
अट दुरुस्त करा, गट नाही
कोणते धोरण चालले हे कळल्यावर दुरुस्ती सहसा लहान असते: इच्छित परवानगी झाकणारा नकार पुन्हा क्रमवारीत लावा, लक्ष्य धोरणात गहाळ उपकरण किंवा MFA अट जोडा, किंवा वापरकर्त्याला दहा अधिक गटात चढवण्याऐवजी एका संसाधनासाठी संकुचित नियम लिहा.
छोटा फेरा बदल प्रामाणिक ठेवतो:
- मूळ खात्याने नकार पुन्हा निर्माण करा आणि काहीही बदलण्यापूर्वी इव्हेंट ID लिहा.
- एकच घटक बदला, धोरण क्रम, एक अट किंवा एक गट, आणि कोणते बदलले ते नोंदवा.
- नवे सत्र उघडा, लॉगमध्ये परवानगी दिसते आणि संसाधन खरोखर उघडते याची खात्री करा.
- अजूनही नकार द्यायला हवा अशा वापरकर्त्याची चाचणी करा, दुरुस्तीने धोरण चुकून रुंदावू नये.
परवानगी बरोबर असूनही संसाधन उघडत नसेल, तर अधिकृतता पार होताच समस्या मार्गनिर्देशन किंवा नाव निराकरणाकडे सरकली आहे. त्या दोन बिघाडी वेगळ्या ठेवा, पुढील तिकीट अर्ध्या दिवसाऐवजी मिनिटांत होईल.