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 लेख्नुहोस्।
- एउटै वस्तु बदल्नुहोस्, नीति क्रम, एउटा सर्त वा एउटा समूह, र कुन बदल्यो लेख्नुहोस्।
- नयाँ सत्र खोल्नुहोस्, लगमा अनुमति देखिन्छ र स्रोत साँच्चै खुल्छ भनी पुष्टि गर्नुहोस्।
- अझै अस्वीकार गर्नुपर्ने प्रयोगकर्ता जाँच्नुहोस्, सुधारले नीति गल्तीले फराकिलो नबनाओस्।
अनुमति ठीक भए पनि स्रोत नखुल्ने हो भने, अधिकार पार भएको क्षणमै समस्या मार्ग वा नाम समाधानतर्फ सरेको छ। ती दुई खराबी अलग राख्नुहोस्, अर्को टिकट मिनेटमा सकिन्छ।