RADIUS अस्वीकृति बनाम कुनै जवाफ छैन: स्थानीय लगइन कहिले चल्छ

आपत्कालीन स्थानीय खाता राख्नुले त्यसलाई हरेक अस्वीकृत लगइनका लागि दोस्रो अवसर बनाउँदैन। Cisco IOS र IOS XE AAA मोडेलमा त्यो डेटाबेसलाई केवल तब सोधिन्छ जब अघिल्लो विधि कुनै निश्चित तरिकाले असफल हुन्छ, र अस्वीकृतिसँग जवाफ दिने RADIUS सर्भर त्यस तरिकाले असफल भएको छैन। स्थानीय खाताले अप्राप्य विधिलाई समेट्छ, अस्वीकृत विधिलाई होइन। उल्टो मान्दा नीति निर्णय नभएको सर्भर खराबीको खोजीमा परिणत हुन्छ।

विधि सूची किन भर्याङजस्तो देखिन्छ

यस्तो लाइन aaa authentication login default group radius local बायाँबाट दायाँ पढिन्छ, र धेरैजसो मानिस यसलाई RADIUS प्रयास गर, त्यसपछि स्थानीय डेटाबेस प्रयास गर भनेर पढ्छन्। सूची एक क्रम भएकाले वाक्यरचनाले त्यस्तो पढाइलाई आमन्त्रण गर्छ। अर्थ साँघुरो छ: सूचीले प्रमाणीकरणका विधिहरूको नाम दिन्छ, र एकबाट अर्कोमा जाने नियम अघिल्लो विधिको नतिजामा निर्भर हुन्छ, प्रयोगकर्तालाई अर्को प्रयास दिनमा होइन।

त्रुटि फर्काउने विधि र असफलता फर्काउने विधि यहाँ फरक नतिजातर्फ लैजान्छन्। अस्वीकृति एक जवाफ हो, किनकि सर्भरले लगइन विवरण प्रशोधन गरी नाइँ भन्यो, र सूची त्यहीँ रोकिन्छ। अप्राप्य सर्भर, म्याद सकिएको अनुरोध वा प्रमाणित गर्न नसकिने जवाफ त्यो अवस्था हो जसले अर्को विधिलाई चल्न दिन्छ, र प्लेटफर्मको असफलता व्यवस्थापन त्यसरी कन्फिगर गरिएको ठाउँमा मात्र। त्यसैले local थप्ने पुरानो सल्लाह अवरोधमा काम गर्छ र गलत पासवर्डमा केही गर्दैन। सूचीलाई यसको सट्टा दुई प्रश्नका रूपमा पढ्नुहोस्: कुन विधिले जवाफ दिन्छ, र प्लेटफर्मले केलाई जवाफ मान्छ।

विधि सूचीलाई सर्भर समूहबाट अलग गर्नुहोस्

विधि सूची एक तह हो र सर्भर समूह अर्को। group radius शब्दले यस्तो समूहको नाम दिन्छ जसको आन्तरिक क्रम, पुनःप्रयास, समयसीमा र मृत सर्भर पहिचान समूहभित्र पर्छन्, जबकि स्थानीय विधि त्यसको माथिको तह हो। त्यसैले समूहभित्र केही ट्युन गर्दा अस्वीकृति फलब्याकमा परिणत हुन सक्दैन। दुईमध्ये कुनै तह बदल्नुअघि सेवाले वास्तवमा कुन सूचीको सन्दर्भ लिन्छ भनी पुष्टि गर्नुहोस्।

AAA कन्फिगरेसन प्रिन्ट गर्नुहोस् र सेवाले देखाउने सूची पढ्नुहोस्, तपाईंले लेखेको सम्झेको पूर्वनिर्धारित मान होइन। यो सेवा वास्तवमा अन्त्य हुने यन्त्रबाट गर्नुहोस्।

show running-config | section aaa
show radius server-group RAD-GRP
show aaa servers

सर्भर तालिकाले हरेक प्रविष्टिको अवस्था र गणक देखाउँछ, जसले प्रयासका क्रममा गेटवे सर्भरसम्म पुग्यो कि भनी बताउँछ। बढ्दो अनुरोध गणकसँग सक्रिय चिन्हित सर्भर जवाफ दिइरहेको थियो, त्यसैले असफल लगइन एक निर्णय हो, कनेक्टिभिटी समस्या होइन।

लग अघि जवाफ पढ्नुहोस्

जवाफ कोडले नतिजाको नाम दिन्छ र आफ्नै अर्को कदम संकेत गर्छ। Access-Reject भनेको ब्याकएन्डले निर्णय लियो, त्यसैले उपयोगी प्रमाण भनेको मिलेको नीति र त्यसपछिको खाता अवस्था हो। Access-Challenge भनेको आदानप्रदानले दोस्रो कारकजस्तो अर्को समर्थित कदम चाहन्छ, र स्थानीय फलब्याकले नीतिले मागेको कुरा चुपचाप छोडिदिन्थ्यो।

तोकिएको परीक्षण खातासँग एक प्रयास पुनरुत्पादन गर्नुहोस् ताकि जवाफ र ब्याकएन्ड अभिलेख एउटै समयछापमा तुलना गर्न सकियोस्। असफल गर्न अनुमति भएको लगइन विवरण प्रयोग गर्नुहोस्।

test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authentication

RADIUS क्लाइन्ट प्रविष्टि नहुनु वा नचिनिनु शान्त समयसीमाको सामान्य कारण हो, किनकि सर्भरले अनुरोध पाउँछ, मिल्ने क्लाइन्ट परिभाषा भेट्दैन र जवाफ नदिई त्यसलाई फ्याँकिदिन्छ। साझा गोप्यको नमिल्दोपन पनि सामान्यतया समयसीमाजस्तै देखिन्छ, किनकि जवाफ प्रमाणीकरणमा असफल भई फ्याँकिन्छ। तीमध्ये कुनै पनि Access-Rejectजस्तो देखिँदैन, र तीमध्ये कुनै पनि स्थानीय खाता थपेर सुधारिँदैन। विधि सूचीलाई छुनुअघि दुवैतर्फ क्लाइन्ट परिभाषा र गोप्य जाँच्नुहोस्।

स्थानीय खाताले किन कहिल्यै केही प्रमाणित गरेन

सूचीमा समूहपछि बसेको खाताले कसैले अवरोधको योजना बनाएको मात्र प्रमाणित गर्छ। योजना काम गर्छ कि गर्दैन भन्नेबारे यसले केही भन्दैन, किनकि यसलाई परख्ने अवस्था नै त्यो अवस्था हो जसको कसैले अभ्यास गर्दैन: सर्भरले जवाफ दिन छोड्यो। सामान्य सञ्चालनमा कहिल्यै नपुगिने स्थानीय लगइनले महिनौंसम्म म्याद सकिएको पासवर्ड वा ताल्चा लागेको अवस्था बोक्न सक्छ, कसैले याद गर्दैन।

आपत्कालीन पहुँच एक डिजाइन निर्णय हो, कन्फिगरेसनको साइड इफेक्ट होइन। यसलाई आफ्नै सीमित खाता, आफ्नै जिम्मेवार व्यक्ति र लिखित पुनःप्राप्ति प्रक्रिया दिनुहोस्, र साझा गोप्यको घुमाइ त्यो प्रक्रियामा समावेश गर्नुहोस्। हरेक केन्द्रीय प्रयोगकर्ताका लागि एउटै नामको स्थानीय पासवर्ड राख्नु त्यो ढाँचा हो जसले तपाईंले हटाएँ भन्ने पहुँच चुपचाप फर्काउँछ।

महत्त्वपूर्ण परीक्षण जानाजान गरिएको हुन्छ, र चल्दा यसले लगइनमा बाधा पुर्याउँछ। त्यसैले यो रोलब्याक कदम पहिले लेखिएको निर्धारित विन्डोमा पर्छ।

मर्मत विन्डोमा फलब्याक मार्ग जाँच्नुहोस्

अन्तिम प्रवेश मार्ग कहिल्यै नहटाउने गरी परीक्षण मिलाउनुहोस्। पहिले स्वतन्त्र व्यवस्थापन मार्ग, त्यसपछि सामान्य अनुमत पहुँच, त्यसपछि जानाजान अस्वीकृति, त्यसपछि स्वीकृत अवरोध व्यवहार पुष्टि गर्नुहोस्। यी चार अवस्थाका अपेक्षित नतिजा फरक छन्, र तिनलाई एउटै परीक्षणमा मिलाउनु त्यही तरिका हो जसले मानिसहरू आफूलाई अझै आवश्यक यन्त्रबाट बाहिर ताल्चा लगाउँछन्।

हरेक जाँच कन्सोल सत्रबाट वा ब्यान्डबाहिरको मार्गबाट चलाउनुहोस्, ताकि गल्तीले तपाईं काम गरिरहेको सत्र बन्द गर्न नसकोस्। कन्सोल त्यो एक मात्र मार्ग हो जुन परीक्षणाधीन घटकमा निर्भर छैन।

show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy

त्यसपछि अघिल्लो कन्फिगरेसन पुनःस्थापित गर्नुहोस् र अर्को वास्तविक लगइनमा गणक फेरि चल्छन् भनी पुष्टि गर्नुहोस्। जानाजान गरिएको अस्वीकृतिले अस्वीकृतिको सट्टा स्थानीय लगइन उत्पन्न गर्छ भने सूची वा असफलता व्यवस्थापन तपाईंले विश्वास गरेको जस्तो छैन, र त्यो खोज तपाईंले सुरु गरेको अवरोधभन्दा ठूलो हो। नतिजा परिवर्तन अभिलेखमा खाता नाम र परीक्षणको मितिको छेउमा लेख्नुहोस्।