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 సర్వర్ గేట్‌వే పంపే ఖచ్చితమైన వినియోగదారు పేరు రూపాన్ని పరిష్కరిస్తుంది. ఆమోదం గేట్‌వే విధానానికి అవసరమైన లక్షణాలను తీసుకెళుతుంది. నాలుగూ నిజమైతే, ఇప్పటికీ విఫలమయ్యే లాగిన్ ప్రామాణీకరణది కాదు, గేట్‌వే విధానం సమస్య.