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