RADIUS Access-Challenge पछि VPN लगइन अड्किन्छ

तपाईंको पासवर्ड सही छ, तैपनि VPN लगइन असफल हुन्छ, र RADIUS सर्भरले भनिएको कुरा ठ्याक्कै गरेको हुन सक्छ। गेटवेले सम्भवतः Access-Challenge प्राप्त गर्यो, केही उपयोगी देखाएन, र त्यसपछि समय सकियो वा त्यो उत्तरलाई अस्वीकृति मान्यो। क्लाइन्टको तर्फबाट यो गलत प्रमाणहरू वा बिग्रिएको सुरुङ जस्तो देखिन्छ। कारण सामान्यतया कसैले कैद नगरेको कुराकानीको बीचमा हुन्छ।

एक लगइन, दुई RADIUS आदानप्रदान

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

काम गर्ने सेटअपमा प्रयोगकर्ताले दोस्रो सङ्केत देख्छ: पहिले पासवर्ड, त्यसपछि एक-पटकको कोड, वा अपरेटरले कागजात गरेको भए एउटै संयुक्त सङ्केत। बिग्रिएको सेटअपमा दोस्रो सङ्केत कहिल्यै आउँदैन र लगइन बस असफल हुन्छ।

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

चुनौतीले वास्तवमा के बोक्छ

RADIUS विशिष्टता ले धारा 4.4 मा कोड 11 वर्णन गर्छ र यहाँ महत्त्वपूर्ण दुई विशेषताहरूलाई अनुमति दिन्छ। Reply-Message ले प्रयोगकर्ताका लागि राखिएको पाठ राख्छ, र State ले सर्भरले फिर्ता चाहने अपारदर्शी मान राख्छ। NAS ले State को व्याख्या गर्नु हुँदैन, केवल अपरिवर्तित फर्काउनुपर्छ।

पछिल्लो अनुरोधले नयाँ Identifier र नयाँ Request Authenticator प्रयोग गर्छ, र त्यसले त्यही State मान तथा प्रयोगकर्ताको प्रतिक्रिया बोक्नुपर्छ। सर्भरले त्यसलाई त्यही State मार्फत प्रतीक्षारत चुनौतीसँग मिलाउँछ, त्यसैले विशेषता पुनः बनाउने वा छोड्ने गेटवेले यो विधि पूरा गर्न सक्दैन। प्रत्येक उत्तरको response authenticator पनि प्रमाणित हुनुपर्छ, नत्र NAS ले प्याकेट फाल्नुपर्छ।

धारा 4.4 ले त्यो विवरण थप्छ जसले अधिकांश मौन असफलता बुझाउँछ: चुनौती समर्थन गर्न नसक्ने NAS ले Access-Challenge लाई अस्वीकृति मान्छ। यदि तपाईंको गेटवेको VPN सेवा त्यो समर्थनभन्दा पुरानो छ वा त्यसलाई छोड्छ भने, ब्याकएन्डको दोस्रो कारक अनुरोध कुनै सङ्केत बिना तुरुन्तै «प्रमाणीकरण असफल» बन्छ।

शृंखलाबद्ध अनुरोध कहाँ हराउँछ

पहिलो शंकास्पद कुरा प्रमाण होइन, सङ्केतको बाटो हो। वेब लगइनका लागि OTP क्षेत्र देखाउने पोर्टलले VPN सेवाका लागि स्वतः त्यसो गर्दैन, र केही गेटवेले क्षमता घोषणा गर्ने क्लाइन्टलाई मात्र चुनौती पठाउँछन्। त्यही खाता दुवै प्रवेश बिन्दुमा परीक्षण गर्नुहोस्; यदि पोर्टल चल्छ र VPN चल्दैन भने, तपाईं हस्तान्तरण हेर्दै हुनुहुन्छ, टोकन होइन।

इनपुट ढाँचा दोस्रो शंकास्पद हो। विक्रेताले कागजात गरेको विभाजक बिना पासवर्ड र कोड जोड्नु, वा सङ्ग्रहित प्रमाणहरूलाई पुरानो कोड फेरि चलाउन दिनु, गलत पासवर्डजस्तै देखिने तरिकाले असफल हुन्छ। अपरेटरले कागजात गरेको छुट्टै सङ्केत वा संयुक्त ढाँचा प्रयोग गर्नुहोस्, र कहिल्यै आफैं विभाजक नबनाउनुहोस्।

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

एउटा प्रयासलाई सुरुदेखि अन्त्यसम्म ट्रेस गर्नुहोस्

सर्भर-साइड डिबगिङ खुला राखेर एक पटक पुनरुत्पादन गर्नुहोस्, र अरू हरेक सत्रलाई क्याप्चर विन्डोबाहिर राख्नुहोस्:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

आउटपुटमा एउटा लाइनको सट्टा कुराकानीको आकार खोज्नुहोस्। Identifier 3 सहितको पहिलो Access-Request, State बोक्ने Access-Challenge, त्यसपछि त्यो State दोहोर्याउने र प्रयोगकर्ताको प्रतिक्रिया समावेश गर्ने Identifier 4 सहितको दोस्रो Access-Request। दोस्रो अनुरोध छैन भने गेटवेले कहिल्यै पछ्याएन। यदि त्यो State बिना आउँछ भने, सर्भरले त्यसलाई प्रतीक्षारत चुनौतीसँग मिलाउन सक्दैन र सामान्यतया अस्वीकार गर्छ।

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

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