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 ते डिरेक्टरी हा भाग असते: कालबाह्य bind खाते, अप्राप्य डिरेक्टरी किंवा चुकीच्या बॅकएंडकडे पाठवलेली विनंती। वापरकर्तानावात डोमेन प्रत्यय असल्यास सर्व्हर त्यावरून मार्गस्थ करू शकतो, आणि 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 सर्व्हर गेटवे पाठवत असलेल्या वापरकर्तानावाचे नेमके स्वरूप सोडवतो। स्वीकृती गेटवे धोरणाला आवश्यक वैशिष्ट्ये वाहून नेते। चारही खरे असतील तर तरीही अयशस्वी होणारे लॉगिन प्रमाणीकरणाची नाही, गेटवे धोरणाची समस्या आहे।