సహాయ కేంద్ర టికెట్లు విఫలమైన VPN లాగిన్ మరియు బలమైన పద్ధతిని కోరే RADIUS విధానాన్ని ఒకే సమస్యలా వివరిస్తాయి, కానీ అలా కాదు. గేట్‌వే ఆధారాలను స్వీకరించి పంపుతుంది, లేదా క్లయింట్ మరియు ప్రామాణీకరణ సర్వర్ మధ్య EAP సంభాషణను తీసుకువెళుతుంది. వీటిలో ఏది జరుగుతుందనేది సర్వర్ వైపు మార్పు ఏదైనా సరిచేయగలదా అని నిర్ణయిస్తుంది. సర్వర్ సమూహాన్ని సవరించే ముందు మార్పిడిని చదవండి.

లాగ్‌లో ఒకేలా కనిపించే రెండు ప్రామాణీకరణ మార్గాలు

మొదటి మార్గంలో VPN గేట్‌వే వినియోగదారు పేరు మరియు పాస్‌వర్డ్ సేకరించి పాస్‌వర్డ్ లక్షణంతో RADIUS Access-Request పంపుతుంది. ప్రామాణీకరణ సర్వర్ దాన్ని తన నిల్వతో పోల్చి ఆమోదించు లేదా తిరస్కరించు అని సమాధానమిస్తుంది. క్లయింట్ ఎప్పుడూ EAP పద్ధతిని నడపదు, ఎందుకంటే ఎవరూ అడగలేదు.

రెండవ మార్గంలో క్లయింట్ మరియు ప్రామాణీకరణ సర్వర్ EAP పద్ధతిని ప్రారంభం నుండి ముగింపు వరకు నడుపుతాయి, గేట్‌వే వాటి మధ్య EAP-Message లక్షణాలను పంపుతుంది. గేట్‌వే బాహ్య RADIUS సంభాషణను ఇంకా ముగిస్తుంది, కానీ పద్ధతి యొక్క తర్కం రెండు చివరల్లో ఉంటుంది.

రెండు మార్గాలు లాగ్‌లో ప్రామాణీకరణ విఫలమైంది అని ఒక పంక్తిని సృష్టిస్తాయి. సర్వర్ ఇష్టపడే EAP పద్ధతి రెండవదానిపై మాత్రమే ప్రభావం చూపగలదు, గేట్‌వే పాస్‌వర్డ్ ఎలా చదువుతుందనేది మొదటిదానిపై మాత్రమే. వాటిని పరస్పరం మార్చుకోగలిగినవిగా భావించడమే, PEAP మాట్లాడని క్లయింట్ కోసం జట్లు రోజంతా సర్వర్ సమూహాలను మార్చడానికి కారణం.

పద్ధతి నిజంగా ఎక్కడ నడుస్తుంది

RFC 3579 పంపే ఏర్పాటును నిర్వచిస్తుంది: NAS RADIUS లక్షణాలలో EAP ప్యాకెట్లను మోసుకెళుతుంది మరియు ప్రతి EAP రకానికి పద్ధతి-నిర్దిష్ట కోడ్ అవసరం లేదు. అందుకే గేట్‌వే PEAP మరియు EAP-TLS రెండింటినీ ఏదీ అమలు చేయకుండా మద్దతు ఇవ్వగలదు.

పాస్‌వర్డ్ పంపే గేట్‌వే PEAPని మోసుకెళ్లదు, బ్యాకెండ్ మరో క్లయింట్ నుండి PEAPని ఆమోదించినా. సర్వర్ విధానంలో PEAPని ప్రారంభించడం ఎప్పుడూ అందించని క్లయింట్‌కు పద్ధతిని జోడించదు.

PPP ప్రామాణీకరణ సెట్టింగ్‌లు PPP సేవకు చెందుతాయి. అవి అదే AAA సర్వర్‌ను ఉపయోగించే ప్రతి IPsec లేదా పాత XAuth మార్గాన్ని నిశ్శబ్దంగా పునఃకాన్ఫిగర్ చేయవు, కాబట్టి ఒక యాక్సెస్ రకానికి పనిచేసే మార్పు మరొకటిని తాకకుండా వదిలివేయగలదు.

NAS ఏమి మద్దతు ఇవ్వాలి

పంపడం అవసరాన్ని పద్ధతి కోడ్ నుండి వాహక మద్దతుకు మారుస్తుంది. గేట్‌వే తన VPN ప్రోటోకాల్‌పై EAPని మోయగలగాలి, దానిపై ఉన్న RADIUS క్లయింట్ సంబంధిత పరిమాణాల EAP-Message లక్షణాలను పంపి స్వీకరించగలగాలి.

IKEv2కి EAP నిర్వచిత ప్రామాణీకరణ ప్రవాహంలో భాగం, సర్వర్ గుర్తింపు మరియు విశ్వాస తనిఖీలు ఆ ప్రవాహం నుండే వస్తాయి. 802.1X అమలు నుండి అప్పు తీసుకున్న PEAP లేబుల్ స్వయంచాలకంగా దాటదు, ఎందుకంటే దాని చుట్టూ జరిగే చర్చ భిన్నంగా ఉంటుంది.

క్లయింట్ వైపు కూడా అవసరాలున్నాయి. అది పద్ధతి కోసం కాన్ఫిగర్ చేయబడాలి, పద్ధతి అందించే సర్వర్ సర్టిఫికేట్‌ను నమ్మాలి, పద్ధతి ఉపయోగించగల ఆధారాలు ఉండాలి. క్లయింట్ సర్టిఫికేట్ లేని సర్టిఫికేట్ ఆధారిత పద్ధతి RADIUS ఏదైనా చూసే ముందే విఫలమవుతుంది, ఇది సర్వర్ విధానం కాదు, సదుపాయ సమస్య.

విధానాన్ని మార్చే ముందు ఒక ప్రయత్నాన్ని చదవండి

గేట్‌వేలో మరియు ప్రామాణీకరణ సర్వర్‌లో ఒక ఆమోదిత ప్రయత్నాన్ని క్యాప్చర్ చేయండి. RADIUS అభ్యర్థనలో EAP-Message లక్షణాలను వెతకండి. వాటి ఉనికి పంపే మార్గం వాడుకలో ఉందని చెబుతుంది; లేకపోవడం ఆధార మార్పిడిని సూచిస్తుంది.

Linux గేట్‌వేలో RADIUS పోర్ట్‌పై క్యాప్చర్ తీగపై ఏ లక్షణాలున్నాయో చూపిస్తుంది:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

తర్వాత తిరస్కార బిందువును పోల్చండి. ఏదైనా RADIUS ప్యాకెట్‌కు ముందు గేట్‌వేలో వైఫల్యం అంటే క్లయింట్ మరియు గేట్‌వే పద్ధతిపై ఏకీభవించలేదు. EAP లక్షణాలతో కూడిన RADIUS తిరస్కారం అంటే రెండు చివరలు పద్ధతిని నడిపాయి, వాటిలో ఒకటి ఫలితాన్ని తిరస్కరించింది.

మార్పిడిని ప్రారంభం నుండి ముగింపు వరకు ఒకే మార్పుగా ప్రణాళిక చేయండి

పద్ధతిని మార్చడం అంటే క్లయింట్ కాన్ఫిగరేషన్, గేట్‌వే వాహక మద్దతు, సర్వర్ పద్ధతి విధానం మరియు ఆధార నిల్వను కలిసి మార్చడం. ఆ క్రమంలో చేయండి మరియు కొత్తది నిరూపించబడే వరకు పనిచేసే మార్గాన్ని ఉంచండి. సర్వర్ వైపు మాత్రమే మార్పు ఊహ, అది సాధారణంగా పనిచేసిన క్లయింట్లను విరగ్గొడుతుంది. సమూహాన్ని తాకే ముందు ఒక పరీక్ష గుర్తింపుపై మార్పును సిద్ధం చేయండి.

పనిచేసే కలయికను నమోదు చేయండి: VPN ప్రోటోకాల్, EAP వాహకం, సహచర పద్ధతి, సర్వర్ పద్ధతి, ఆధార రకం మరియు సర్వర్ గుర్తింపు తనిఖీ.

నిర్వాహక లాగిన్ AAAని VPN ప్రామాణీకరణ నుండి వేరుగా ఉంచండి, పని స్పష్టంగా రెండింటినీ చేర్చనంత వరకు. దూర ప్రాప్యత కోసం ఉద్దేశించిన మార్పు దాన్ని ముగించే పరికరాన్ని నిర్వహించే సామర్థ్యాన్ని మీ నుండి తీసుకోకూడదు.

సంబంధిత వ్యాసాలు