L2TP/IPsec విఫలమవుతోంది: IPsec, టన్నెల్ ప్రామాణీకరణ లేదా PPP లాగిన్ను వేరు చేయండి

ఒక L2TP/IPsec కనెక్షన్ లోపల మూడు విషయాలు ప్రామాణీకరించబడతాయి, మరియు వాటిలో ఒకటి మాత్రమే డయల్ చేసే వ్యక్తిని కలిగి ఉంటుంది. IPsec టన్నెల్ చివరలను నిరూపిస్తుంది, L2TP నియంత్రణ కనెక్షన్ తన స్వంత రహస్యంతో భాగస్వాములను మళ్లీ నిరూపించగలదు, తర్వాత PPP సెషన్ లోపలి వినియోగదారు ఖాతాను నిరూపిస్తుంది. ఏ దశలోనైనా వైఫల్యం క్లయింట్ డైలాగ్లో సాధారణ లాగిన్ లోపంగా కనిపిస్తుంది మరియు సర్వర్ లాగ్లో పూర్తిగా భిన్నంగా కనిపిస్తుంది. దశలను వరుసగా పూర్తి చేసి మొదట విఫలమైన దశలో ఆగండి, ఎందుకంటే పరీక్షించని దశ క్రింద ఉన్న ప్రతి దశ కూడా పరీక్షించబడలేదు.

మూడు ప్రామాణీకరణ దశలు, మూడు వేర్వేరు గుర్తింపులు

IPsec ముందే పంచుకున్న కీ లేదా ధృవపత్రాన్ని ఉపయోగించి చివరలు ఎవరివో నిరూపిస్తుంది. ఆ గుర్తింపు యంత్రాలు లేదా గేట్వేలకు చెందుతుంది, కీబోర్డు ముందు ఉన్న మనిషికి ఎప్పటికీ కాదు. ఈ దశలో భాగస్వాములు అంగీకరించలేకపోతే, ఏ L2TP ప్యాకెట్ కూడా మార్పిడి చేయబడదు.

L2TP నియంత్రణ కనెక్షన్ రెండవ, ప్రత్యేక సవాలు-ప్రతిస్పందన మార్పిడిని జోడించగలదు, ఇది రెండు చివరలు కలిగి ఉండాల్సిన భాగస్వామ్య రహస్యం ద్వారా నడపబడుతుంది.

RFC 2661 ఆ నియంత్రణ కనెక్షన్ ప్రామాణీకరణను ఐచ్ఛికం చేస్తుంది, ఇది అదే పొరపాటు రెండు సర్వర్లలో వేర్వేరు లక్షణాలు ఎందుకు కలిగిస్తుందో వివరిస్తుంది. టన్నెల్ రహస్యాన్ని ఎప్పుడూ సెట్ చేయని అమరిక ఆ దశను పూర్తిగా దాటవేస్తుంది; ఒక వైపు మాత్రమే సెట్ చేసినది PPP అందించబడక ముందే విఫలమవుతుంది. తర్వాత PPP వినియోగదారుని PAP, CHAP లేదా MSCHAPv2తో ప్రామాణీకరించి పేరును స్థానిక, chap-secrets లేదా RADIUSలో ఉండగల ఖాతా నిల్వకు అందిస్తుంది. ఆ సమయంలో తప్పు పాస్వర్డ్ ఇప్పటికీ పని చేసే టన్నెల్ మరియు విఫలమైన సెషన్తో మిమ్మల్ని వదిలివేస్తుంది.

కాన్ఫిగరేషన్ మార్చే ముందు ఆగే స్థలాన్ని చదవండి

స్టేటస్ అవుట్పుట్ strongSwan లేదా Libreswanది అని తెలుసుకోవడానికి ipsec --version తో ప్రారంభించండి. తర్వాత క్లయింట్ డైలాగ్ కాదు, సర్వర్ లాగ్ చదవండి, ఎందుకంటే ఏ దశ నిరాకరించిందో సర్వర్ నమోదు చేస్తుంది.

సాధారణంగా ఒక లైన్ టికెట్ను పరిష్కరిస్తుంది: IKE లేదా ప్రతిపాదనల ఫిర్యాదు మొదటి దశ, నియంత్రణ కనెక్షన్ సందేశం రెండవ దశ, మరియు PPP పద్ధతి లేదా ఖాతా నిరాకరణ మూడవ దశ. ఆ లైన్ను సమయ ముద్రతో టికెట్లో కాపీ చేయండి. క్లయింట్ వైపు నుండి ఊహించడం మీకు ఇప్పటికే ఉన్న ఏకైక సాక్ష్యాన్ని వృథా చేస్తుంది.

కీ మెటీరియల్ మరియు పాస్వర్డ్లను ఆ పేస్ట్ వెలుపల ఉంచండి; దశ పేరు పనిని నిర్దేశిస్తుంది, మరియు లీక్ అయిన ముందే పంచుకున్న కీ మరింత దారుణమైన పరిణామాలతో టికెట్ను మళ్లీ తెరుస్తుంది.

మొదటి దశ: IPsecకి అనుబంధం ఉందా?

strongSwanలో ipsec statusall లేదా Libreswanలో ipsec whack --status అమలు చేసి, సున్నా కాని కౌంటర్లతో స్థాపించబడిన చైల్డ్ అనుబంధం కోసం చూడండి. ip xfrm state రెండింటిలో కెర్నల్ వీక్షణను చూపుతుంది. పెరుగుతున్న కౌంటర్లతో స్థాపించబడిన SA జోడి అంటే మొదటి దశ పూర్తయింది మరియు మీరు కొనసాగవచ్చు.

అనుబంధం పూర్తిగా లేకపోవడం పీర్ చిరునామా, ప్రతిపాదన సముదాయం లేదా ముందే పంచుకున్న కీని సూచిస్తుంది, కొన్నిసార్లు UDP 500ని తిరిగి రాసి UDP 4500ని వదిలేసే పరికరాన్ని కూడా సూచిస్తుంది. స్థాపించబడి కొన్ని సెకన్ల తర్వాత మాయమయ్యే అనుబంధం సాధారణంగా ఆధారాల సమస్య కాదు, రెండు చివరల మధ్య జీవితకాల అసమతుల్యత. ఏదైనా తిరిగి టైప్ చేసే ముందు రెండు వైపులా ఒకే ఎన్క్రిప్షన్ మరియు హాష్ ప్రతిపాదనలను జాబితా చేస్తున్నాయా చూడండి. లేకపోతే, ఏ కీ కూడా ఎప్పటికీ పని చేయదు.

అనుబంధం లేనంత కాలం ఆగండి. ఆ సమయంలో PPP ఎంపికలను మార్చడం ఏమీ మార్చదు మరియు నిజమైన లోపాన్ని తదుపరి వ్యక్తి నుండి దాస్తుంది.

రెండవ దశ: L2TP నియంత్రణ కనెక్షన్ ప్రామాణీకరించబడిందా?

IPsec లేచిన తర్వాత, స్థాపిత స్థితిని చేరుకునే నియంత్రణ కనెక్షన్ కోసం L2TP డీమన్ను గమనించండి, ఎందుకంటే అంతకు ముందు PPP ప్రారంభం కాదు. నియంత్రణ కనెక్షన్పై నిరాకరణ అంటే చివరల మధ్య టన్నెల్ రహస్యం భిన్నంగా ఉంది, లేదా ఒక చివర మరొకటి ఎప్పుడూ పంపని రహస్యాన్ని కోరుతోంది. క్లయింట్లు తరచుగా shared secret లేబుల్ ఉన్న ఒకే ఫీల్డ్ను చూపుతాయి, అది సాధారణంగా L2TPకి కాదు, IPsecకి చెందుతుంది. దాన్ని నింపడం టన్నెల్ రహస్యాన్ని సెట్ చేయదు, ఖాళీ చేయడం దాన్ని నిలిపివేయదు.

ఏ వైపు టన్నెల్ రహస్యాన్ని సెట్ చేయకపోతే, ఈ దశను దాటవేసి నియంత్రణ కనెక్షన్ వైఫల్యాన్ని బదులుగా చేరుకోగల సమస్యగా పరిగణించండి. UDP 1701 డీమన్ను చేరుతుందని మరియు రెండు చివరలు ఒకే ఎన్క్యాప్సులేషన్పై అంగీకరిస్తున్నాయని నిర్ధారించండి. ఆ రెండు షరతులలో ఒకదాని కోసం రాసిన ఫైర్వాల్ నియమం సగం తెరుచుకునే కనెక్షన్కు సాధారణ కారణం.

PPP చర్చను ప్రారంభించే సెషన్ మాత్రమే టన్నెల్ దశను నిజంగా దాటింది.

మూడవ దశ: PPP ఖాతాను నిరాకరిస్తోందా?

PPP వైఫల్యం బయటి నుండి భిన్నంగా కనిపిస్తుంది: టన్నెల్ స్థాపించబడింది, సెషన్ ప్రారంభమవుతుంది, మరియు డీమన్ ప్రామాణీకరణ పద్ధతి వైఫల్యం లేదా ఖాతా నిరాకరణను నమోదు చేస్తుంది. ఆ సందేశంలో పేర్కొన్న పద్ధతిని చదవండి. PAP మరియు CHAP వేర్వేరు కారణాలతో విఫలమవుతాయి, మరియు ఒకదాన్ని నిరాకరించే సర్వర్ దానిని మాత్రమే అందించే క్లయింట్ను నిరాకరిస్తుంది.

Linux సర్వర్లో, డీమన్ PPPకి ఇచ్చే ఎంపిక ఫైల్ను, సాధారణంగా /etc/ppp/options.xl2tpd, పరిశీలించి ఏ పద్ధతులు అంగీకరించబడతాయో మరియు ఖాతాలు ఎక్కడ పరిష్కరించబడతాయో నిర్ధారించండి. RADIUSలో ఉన్నా స్థానిక రహస్య ఫైల్లో లేని పేరు శుభ్రంగా విఫలమై తప్పు పాస్వర్డ్లా కనిపిస్తుంది. తర్వాత క్లయింట్ సర్వర్ అంగీకరించే పద్ధతిని అందిస్తున్నదా, సర్వర్ చర్చను నిరాకరించే బలమైన పద్ధతిని కాదా అని చూడండి. ఈ దశను సరిచేయడానికి ముందే పంచుకున్న కీని మార్చడం మధ్యాహ్నాన్ని వృథా చేస్తుంది మరియు ఏమీ మార్చదు.

సెషన్ చివరకు లేచినప్పుడు, చిరునామా కేటాయింపు, DNS మరియు మార్గాలు ఇంకా తనిఖీ చేయబడలేదు, మరియు ప్రతి ఒక్కటి తన విధంగా నిశ్శబ్దంగా విఫలమవుతుంది. మీ నోట్స్లో మూడు పొరలను విడిగా ఉంచండి: సరైన కీ మరియు తప్పు ఖాతా ఎప్పుడూ విఫలమవుతుంది, మరియు ఒక పొరను సరిచేయడం మరొకదాన్ని ఎప్పటికీ సరిచేయదు.