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 लिख लें।
- एक ही वस्तु बदलें, नीति क्रम, एक शर्त या एक समूह, और दर्ज करें कि कौन सी।
- नया सत्र खोलें, पुष्टि करें कि लॉग में अनुमति दिखती है और संसाधन वास्तव में खुलता है।
- ऐसे उपयोगकर्ता को जाँचें जिसे अभी भी अस्वीकार होना चाहिए, ताकि सुधार ने नीति को गलती से चौड़ा न किया हो।
अगर अनुमति सही है और संसाधन फिर भी नहीं खुलता, तो प्राधिकरण पार होते ही समस्या रूटिंग या नाम समाधान की ओर बढ़ गई है। इन दो खराबियों को अलग रखें, अगला टिकट आधे दिन के बजाय मिनटों में लगेगा।