VPN લોગિન RADIUS અને તમારા ઓળખ પ્રદાતા સુધી કેવી રીતે પહોંચે છે
ક્લાયન્ટથી ગેટવેની RADIUS વિનંતી, તેની પાછળનો ઓળખ પ્રદાતા અને સ્વીકૃતિ પછી લાગુ થતી નીતિ સુધી VPN સાઇન-ઇનને અનુસરો.
ગયા અઠવાડિયે એક વપરાશકર્તા 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 સર્વર ગેટવે મોકલે છે તે વપરાશકર્તાનામનું ચોક્કસ સ્વરૂપ ઉકેલે છે. સ્વીકૃતિ ગેટવે નીતિને જરૂરી લક્ષણો વહન કરે છે. જ્યારે ચારેય ખરા હોય, ત્યારે હજી નિષ્ફળ જતું લોગિન પ્રમાણીકરણની નહીં, ગેટવે નીતિની સમસ્યા છે.