VPN लॉगिन RADIUS और आपके पहचान प्रदाता तक कैसे पहुँचता है
VPN साइन-इन को क्लाइंट से गेटवे के RADIUS अनुरोध, उसके पीछे के पहचान प्रदाता और स्वीकृति के बाद लागू नीति तक ट्रेस करें।
पिछले हफ़्ते एक उपयोगकर्ता VPN में साइन इन कर सका और फिर भी ऐसे नेटवर्क पर पहुँचा जहाँ कुछ भी हल नहीं हो रहा था। क्लाइंट ने कहा जुड़ा हुआ है, गेटवे लॉग ने Access-Accept कहा, और पहचान टीम ने कहा कि खाता ठीक है। लॉगिन काम कर चुका था; उसके पीछे का प्राधिकरण नहीं। जब VPN साइन-इन विफल होता है, तो मैं वह रास्ता चलता हूँ जो अनुरोध वास्तव में लेता है — क्लाइंट, गेटवे, RADIUS सर्वर, पहचान प्रदाता — और पहले ऐसे चरण पर रुकता हूँ जिसका उत्तर अगले से मेल नहीं खाता।
क्लाइंट कभी RADIUS नहीं बोलता
लैपटॉप पर ऐप जो भी दिखाए, उसका पहला चरण VPN प्रोटोकॉल है: IKEv2, OpenVPN, WireGuard या TLS-आधारित क्लाइंट। RADIUS उस आदान-प्रदान में नहीं आता। क्लाइंट गेटवे पर प्रमाणपत्र, उपयोगकर्ता नाम और पासवर्ड, या टनल सेटअप के भीतर ले जाई जाने वाली EAP विधि से प्रमाणित होता है।
लॉग पढ़ते समय यह मायने रखता है, क्योंकि उपयोगकर्ता जो सामान्य प्रमाणीकरण त्रुटि देखता है, वह गेटवे बनाता है, किसी और चीज़ से बात कर चुकने के बाद। यदि क्लाइंट कभी गेटवे तक नहीं पहुँचता, तो डिबग करने के लिए कोई RADIUS अनुरोध नहीं होता, और RADIUS सर्वर पर बिताया एक घंटा व्यर्थ जाता है। बैकएंड को छूने से पहले पुष्टि करें कि टनल बना ही था।
गेटवे ही RADIUS क्लाइंट है
जैसे ही टनल सेटअप उस बिंदु तक पहुँचता है जहाँ क्रेडेंशियल जाँचे जाने हैं, गेटवे नेटवर्क एक्सेस सर्वर बन जाता है। यह Access-Request बनाता है: User-Name, पासवर्ड या EAP पेलोड, NAS-IP-Address या NAS-Identifier, और Message-Authenticator जब विधि इसकी माँग करती है। अनुरोध डिफ़ॉल्ट रूप से UDP 1812 पर जाता है, और लेखांकन 1813 पर। पुराने परिनियोजन अब भी 1645 और 1646 का उपयोग करते हैं, इसलिए एक जोड़ी के लिए लिखा फ़ायरवॉल नियम बहुत सी खामोश विफलताएँ समझाता है।
दोनों पक्ष एक रहस्य साझा करते हैं, और वह उपयोगकर्ता क्रेडेंशियल नहीं है। यह आदान-प्रदान पर हस्ताक्षर करता है, और हर उत्तर उसके विरुद्ध सत्यापित होता है। दोनों पक्षों पर रहस्य अलग-अलग सेट करें और सर्वर गलत रहस्य कहकर उत्तर नहीं देता — वह अनुरोध गिरा देता है या उत्तर सत्यापन में विफल हो जाता है, इसलिए गेटवे समय-समाप्ति बताता है। गलत रहस्य और मृत सर्वर गेटवे से एक जैसे दिखते हैं, इसलिए डायरेक्टरी को दोष देने से पहले मैं क्लाइंट उपकरण से चरण जाँचता हूँ।
प्रोटोकॉल छोटा और पुराना है — RFC 2865 प्रमाणीकरण आदान-प्रदान को परिभाषित करता है — लेकिन यह जो विशेषताएँ ले जाता है, उन्हीं पर अधिकांश VPN नीति बनी है।
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS सर्वर केवल पहचान प्रदाता का अग्रभाग हो सकता है
लोग RADIUS और पहचान प्रदाता के बारे में ऐसे बात करते हैं जैसे वे एक ही डिब्बा हों। अक्सर नहीं होते। RADIUS सर्वर Access-Request प्राप्त करता है और फिर उत्तर देने से पहले किसी और चीज़ से पूछता है — LDAP या Kerberos के माध्यम से Active Directory, स्थानीय उपयोगकर्ता फ़ाइल, या बाहरी सेवा। LDAP या krb5 मॉड्यूल के साथ FreeRADIUS, Windows NPS और Cisco ISE सभी इसी स्थिति में बैठते हैं।
यह अंतर तय करता है कि आप कहाँ देखें। अस्वीकृत पासवर्ड RADIUS द्वारा आगे भेजा गया पहचान प्रदाता का उत्तर है। समय-समाप्ति आमतौर पर RADIUS से डायरेक्टरी तक का हिस्सा है: समाप्त बाइंड खाता, अगम्य डायरेक्टरी, या गलत बैकएंड पर भेजा गया अनुरोध। यदि उपयोगकर्ता नाम में डोमेन प्रत्यय है, तो सर्वर उसके आधार पर रूट कर सकता है, और CORP\alice तथा [email protected] के रूप में भेजा गया वही खाता अलग-अलग जगह पहुँच सकता है। Windows NPS में, Security लॉग अनुमति के लिए 6272 और अस्वीकृति के लिए 6273 दर्ज करता है, जो बताता है कि निर्णय NPS से आया था या नहीं।
विफलता उसी चरण पर पढ़ें जिसने उसे बनाया
एक ही जुड़ नहीं सकता संदेश चार अलग-अलग विफलताओं को कवर करता है। कुछ भी बदलने से पहले, लक्षण को उस चरण से मिलाएँ जिसने उसे बनाया।
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
आखिरी पंक्ति ही वह है जो लोगों को गलत टीम के पास भेजती है। Access-Accept का अर्थ है क्रेडेंशियल स्वीकार हुए; इसका अर्थ यह नहीं कि गेटवे ने उपयोगकर्ता को सही पूल में रखा या रूट धकेले। समूह विशेषताएँ तभी मायने रखती हैं जब गेटवे नीति उन्हें पढ़ती हो। मैंने सही लॉगिन को अतिथि पूल में गिरते देखा है क्योंकि RADIUS पक्ष पर समूह मैपिंग उस विशेषता के लिए सेट थी जो गेटवे जाँचता है, उससे भिन्न थी।
एक लॉगिन को शुरू से अंत तक ट्रेस करें
एक परीक्षण खाता और एक गेटवे चुनें, फिर वही प्रयास चारों बिंदुओं पर देखें। RADIUS पक्ष पर डिबग रन शुरू करें — freeradius -X अनुरोध और हर उस मॉड्यूल को छापता है जिसे वह छूता है — गेटवे का प्रमाणीकरण लॉग देखें, और UDP आदान-प्रदान के लिए tcpdump चलाएँ। एक बार जुड़ें और चारों ट्रेस क्रम से पढ़ें।
आप जो देखना चाहते हैं वह सहमति है: गेटवे ने उस उपयोगकर्ता के बारे में पूछा जिसकी आपको अपेक्षा थी, RADIUS सर्वर ने वह बैकएंड चुना जिसकी आपको अपेक्षा थी, उस बैकएंड ने निर्णय लौटाया, और उत्तर की विशेषताएँ गेटवे द्वारा लागू नीति से मेल खाती हैं। ट्रेस जहाँ पहली बार असहमत होते हैं वही आपकी गलती-रेखा है। यदि उत्तर में कोई समूह विशेषता नहीं है, तो समस्या VPN प्रोफ़ाइल में नहीं, RADIUS पक्ष पर है; यदि विशेषता है और गेटवे उसे अनदेखा करता है, तो समस्या गेटवे नीति है।
वहाँ रहते हुए एक सुरक्षा टिप्पणी। साझा रहस्य आदान-प्रदान की रक्षा करता है, लेकिन यह अधिकांश विशेषताओं को एन्क्रिप्ट नहीं करता। यदि गेटवे और RADIUS सर्वर अलग-अलग खंडों में हैं, तो उस चरण को TLS पर RADIUS या निजी पथ पर रखें। एन्क्रिप्टेड उपयोगकर्ता टनल बैकएंड लिंक के बारे में कुछ नहीं कहती।
टिकट बंद करने से पहले चार बातें पुष्टि करें। गेटवे उस पोर्ट पर RADIUS सर्वर तक पहुँच सकता है जिसके लिए वह वास्तव में कॉन्फ़िगर है। साझा रहस्य दोनों पक्षों पर मेल खाता है। RADIUS सर्वर गेटवे द्वारा भेजे गए उपयोगकर्ता नाम का ठीक-ठीक रूप हल करता है। स्वीकृति में वे विशेषताएँ हैं जिनकी गेटवे नीति को ज़रूरत है। जब चारों सही हों, तो फिर भी विफल लॉगिन प्रमाणीकरण की नहीं, गेटवे नीति की समस्या है।