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 சேவையகம் கேட்வே அனுப்பும் சரியான பயனர் பெயர் வடிவத்தைத் தீர்க்கிறது. ஏற்பு கேட்வே கொள்கைக்குத் தேவையான பண்புகளை எடுத்துச் செல்கிறது. நான்கும் சரியாக இருந்தால், இன்னும் தோல்வியடையும் உள்நுழைவு அங்கீகாரத்தின் அல்ல, கேட்வே கொள்கையின் பிரச்சினை.