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 മുതൽ ഡയറക്ടറി വരെയുള്ള ഭാഗമാണ്: കാലഹരണപ്പെട്ട 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 സെർവർ ഗേറ്റ്വേ അയക്കുന്ന കൃത്യമായ ഉപയോക്തൃനാമ രൂപം പരിഹരിക്കുന്നു. സ്വീകരണം ഗേറ്റ്വേ നയത്തിന് ആവശ്യമായ ആട്രിബ്യൂട്ടുകൾ കൊണ്ടുപോകുന്നു. നാലും ശരിയാണെങ്കിൽ, ഇപ്പോഴും പരാജയപ്പെടുന്ന ലോഗിൻ പ്രാമാണീകരണത്തിന്റെയല്ല, ഗേറ്റ്വേ നയത്തിന്റെ പ്രശ്നമാണ്.