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, फिर Identifier 4 वाला दूसरा Access-Request जो उस State को दोहराता है और उपयोगकर्ता का उत्तर शामिल करता है। यदि दूसरा अनुरोध अनुपस्थित है, तो गेटवे ने कभी अनुसरण नहीं किया। यदि वह State के बिना आता है, तो सर्वर उसे प्रतीक्षारत चुनौती से नहीं मिला सकता और सामान्यतः अस्वीकार कर देगा।

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

आप जो अंतिम स्थिति चाहते हैं वह पूरी, अधिकृत बातचीत है और उसके बाद इच्छित सेवा पहुँच। RADIUS सर्वर से आने वाला उत्तर उससे बहुत कम सिद्ध करता है।