PPP CHAP మాత్రమే MPPE అవసరాన్ని ఎందుకు తీర్చలేదు

ఎన్‌క్రిప్షన్‌పై పట్టుబట్టే PPTP ప్రొఫైల్ సాధారణంగా అదే చోట విఫలమవుతుంది: MPPE కి అవసరమైన కీ పదార్థాన్ని ఎప్పుడూ ఉత్పత్తి చేయని ప్రామాణీకరణ మార్పిడికి PPP అంగీకరిస్తుంది. సొరంగం సగం సజీవంగా కనిపిస్తుంది, పాస్‌వర్డ్ అంగీకరించబడుతుంది, ఏ ట్రాఫిక్ దానిని దాటకముందే లింక్ తెగిపోతుంది. ఏదైనా కనెక్ట్ అయ్యే వరకు CHAP డ్రాప్‌డౌన్ వైపు చేయి చాపడం నిజమైన లోపాన్ని దాచుతుంది, ఆ లోపం ప్రామాణీకరణ పద్ధతికి, రక్షణ విధానానికి మధ్య ఒప్పందం. క్రింది తనిఖీలు ప్రతి ఒక్కటి తదుపరి దాని కంటే చవకైన కారణాన్ని తొలగించేలా అమర్చబడ్డాయి.

ఒక PPTP కనెక్షన్ లోపల రెండు చర్చలు జరుగుతాయి

PPTP GRE సొరంగం లోపల సాధారణ PPP సెషన్‌ను మోసుకెళ్తుంది, రెండూ విడివిడిగా చర్చలు చేస్తాయి. బయటి పొర ప్యాకెట్లు ఎలా క్యాప్సూల్ అవుతాయో, ఏ నియంత్రణ ఛానెల్ ఉందో నిర్ణయిస్తుంది; లోపలి PPP సెషన్ ఎవరు సహచరుడు, పైన ఏ రక్షణ నడుస్తుందో నిర్ణయిస్తుంది. కాబట్టి పాస్‌వర్డ్ అభ్యర్థన లోపలి పొర గురించి మాత్రమే ఏదో నిరూపిస్తుంది, పూర్తయిన బయటి కరచాలనం రెండింటి గురించీ ఏమీ నిరూపించదు. అసమ్మతి PPP లోపల కూర్చొని ఉండగా ప్రజలు సొరంగాన్ని డీబగ్ చేస్తారు కాబట్టి ప్రొఫైళ్లు ఇక్కడ విఫలమవుతాయి.

సాధారణ CHAP అనేది RFC 1994 లోని సవాలు-ప్రతిస్పందన మార్పిడి, భాగస్వామ్య రహస్యం మీద, మరేదీ లేకుండా నిర్మించబడింది. MS-CHAPv2 వేరే సందేశాలు, వేరే అవుట్‌పుట్ ఉన్న మరో మార్పిడి, RFC 2759 లో ప్రమాణీకరించబడింది. రెండు పేర్లలోని భాగస్వామ్య పదమే తీగపై వాటికి ఉమ్మడి అయిన ఏకైక విషయం. ఏ పేరు మార్పిడి ఏమి ఉత్పత్తి చేస్తుందో చెప్పదు, అదే ఏకైక ముఖ్యమైన భాగం.

అందుకే కేవలం CHAP అని లేబుల్ చేసిన ఎంపిక పాత ప్రొఫైల్‌లో అస్పష్టంగా ఉంటుంది. సర్వర్ MS-CHAPv2 కోరి, క్లయింట్ సాధారణ CHAP అందించినప్పుడు, లింక్ నియంత్రణ ఇంకా పూర్తి కావచ్చు, పాస్‌వర్డ్ ఇంకా అంగీకరించబడవచ్చు. విఫలత తర్వాత వస్తుంది, ఏమీ ఉత్పత్తి చేయని మార్పిడి నుండి రక్షణ కీలను పొందాలని సర్వర్ ప్రయత్నించినప్పుడు.

అవసరమైన పద్ధతిని అది ఉత్పత్తి చేయగల కీలతో సరిపోల్చండి

MPPE కీలు సాధారణంగా PPP లక్షణం కాదు. Microsoft CHAP కుటుంబానికి ఉత్పాదన RFC 3079 లో పేర్కొనబడింది, అది ఇన్‌పుట్‌గా భాగస్వామ్య రహస్యానికి బదులు MS-CHAP మార్పిడి అవుట్‌పుట్‌ను తీసుకుంటుంది. EAP పద్ధతులు వేరే మార్గంలో అదే స్థలానికి చేరుతాయి, ప్రామాణీకరణ సర్వర్ కీలను MS-MPPE-Recv-Key, MS-MPPE-Send-Key లక్షణాలుగా తిరిగి ఇస్తుంది. సాధారణ CHAP రెండు మార్గాల్లోనూ కనిపించదు, ఈ అసమతౌల్యం ఉండటానికి మొత్తం కారణం అదే.

కీలు ఇవ్వగల ప్రతి పద్ధతిని తిరస్కరిస్తూనే MPPE కోరే కాన్ఫిగరేషన్ అంతర్గతంగా వైరుధ్యంగా ఉంటుంది. pppd ఆ వైరుధ్యాన్ని కీలను కల్పించడం ద్వారా కాదు, లింక్‌ను తిరస్కరించడం ద్వారా పరిష్కరిస్తుంది, కాబట్టి కనిపించే ఫలితం ప్రామాణీకరణ జరిగి తర్వాత నెట్‌వర్క్ దశలో ముగిసే సెషన్. ఏదైనా ఉత్పాదన చేసే ఏకైక పద్ధతులను సర్వర్ తిరస్కరిస్తున్నంత కాలం క్లయింట్‌ను మళ్లీ ప్రయత్నించడం దాన్ని మార్చదు.

దీని నుండి వచ్చే నియమం చిన్నది: ప్రొఫైల్ MPPE కోరితే, పద్ధతి MS-CHAP రూపం లేదా సర్వర్ కీలను తిరిగి ఇచ్చే EAP పద్ధతి అయి ఉండాలి. MS-CHAPv2 ను మాత్రమే తిరస్కరించడం దాన్ని అమలు చేయదు, ఎందుకంటే MS-CHAPv1 కూడా కీలను ఉత్పత్తి చేస్తుంది, విడిగా తిరస్కరించకపోతే అందుబాటులో ఉంటుంది; రెండింటినీ తిరస్కరిస్తే సాధారణ CHAP, PAP మిగులుతాయి, అవి ఏమీ ఉత్పత్తి చేయక అవసరాన్ని తీర్చలేనిదిగా చేస్తాయి. మీకు నచ్చని వాటిని జాబితా చేయడం బదులు ఆమోదించిన పద్ధతిని స్పష్టంగా పేర్కొనండి. క్లయింట్ కనెక్ట్ కావడానికి ఎన్క్రిప్షన్ అవసరాన్ని వదిలేయడం మరమ్మతు కాదు, క్షీణత.

క్లయింట్‌ను సవరించే ముందు సర్వర్ ఎంపికలను చదవండి

ఈ అసమతౌల్యాల్లో చాలావరకు సర్వర్‌పై రెండు ఫైళ్లలో కనిపిస్తాయి, వాటిని చదవడం క్లయింట్‌ను తిరిగి నిర్మించడం కంటే చవక. Linux PPTP ముగింపు బిందువులో సంబంధిత సెట్టింగ్‌లు pptpd అందించే pppd ఎంపికల ఫైల్‌లో నివసిస్తాయి. దాన్ని సర్వర్‌పై నడపండి, క్లయింట్ స్థితి స్క్రీన్ నుండి కాదు. రక్షణ మోడ్‌ను కోరే, తిరస్కరించే లేదా పేర్కొనే పంక్తులతో ప్రారంభించండి:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

అవుట్‌పుట్‌ను జెండాల జాబితాగా కాదు, ఒప్పందంగా చదవండి. MPPE కోరుతూ MS-CHAP రెండు రూపాలను తిరస్కరించే పంక్తిని ఏ క్లయింట్ తీర్చలేదు, MS-CHAP పద్ధతికి అవసరం లేకపోవడం కీ ఇవ్వని మార్పిడులకు తలుపు తెరిచి ఉంచుతుంది. తర్వాత ఎవరికి ప్రామాణీకరణ అనుమతి ఉందో తనిఖీ చేయండి, దాన్ని రహస్య ఫైల్ నిర్ణయిస్తుంది:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

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

PPP దశ ప్రకారం వైఫల్యాన్ని కనుగొనండి

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

జర్నల్ దశ పంక్తులను ఉంచుతుంది, అవి అధిక డీబగ్ స్థాయి కంటే ఉపయోగకరం. PPP ప్రక్రియలు, రక్షణ సందేశాలను అడగండి, తర్వాత అన్నింటికి ముందు ప్రామాణీకరణ ఫలితాన్ని చదవండి. చివరి పంక్తులు సాధారణంగా తిరస్కరించిన నిబంధనను పేర్కొంటాయి:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

ఆ అవుట్‌పుట్‌లో మొదట ప్రామాణీకరణ ఫలితాన్ని, తర్వాత రక్షణ కోరబడింది కానీ చర్చించబడలేదు అనే ఫిర్యాదును వెతకండి. రెండవ సందేశం పై వైరుధ్యం సంతకం, సర్వర్ కీలను ఉత్పత్తి చేయగల ఏకైక పద్ధతిని తిరస్కరిస్తున్నంత కాలం ఎన్నిసార్లు మళ్లీ ప్రయత్నించినా అది తుడిచిపోదు. రెండు ఉచ్చులను పేర్కొనదగింది: దశ పంక్తులు చదవకుండా డీబగ్ స్థాయిని పెంచడం శబ్దాన్ని కలిగిస్తుంది, సవాలు పదార్థాన్ని లేదా పాస్‌వర్డ్‌లను పట్టుకోవడం కాన్ఫిగరేషన్ పనిని ఆధారాల లీక్‌గా మారుస్తుంది. ఏదైనా ఎంపికను మార్చే ముందు ఆ దశను నమోదు చేయండి.

పాత ముగింపు బిందువు ఆఫ్ కాకముందే నిష్క్రమణను ప్రణాళిక చేయండి

MPPE అనేది లింక్ రక్షణ చారిత్రక యంత్రాంగం, దాని ఉనికి PPTP ను కొత్త అమరికకు తెలివైన ఎంపికగా చేయదు. Microsoft ప్రస్తుత మార్గదర్శకం కొత్త రిమోట్ యాక్సెస్ అమరికలకు PPTP కు, ముందే పంచుకున్న కీ ఉన్న L2TP/IPsec కు వ్యతిరేకంగా ఇప్పటికే సలహా ఇస్తుంది. పాత ముగింపు బిందువును సజీవంగా ఉంచడం ఉన్న సేవ గురించి నిర్ణయం, తదుపరి దానికి నమూనా కాదు.

ముగింపు బిందువు ఉండాల్సి వస్తే, ఒప్పందాన్ని రాయండి: బయటి ప్రోటోకాల్, అవసరమైన ప్రామాణీకరణ పద్ధతి, తప్పనిసరి రక్షణ, దాన్ని చర్చించే క్లయింట్ వెర్షన్. అది వెళ్లగలిగితే, పాత ప్రొఫైల్‌ను తాకే ముందు ప్రత్యామ్నాయం గేట్‌వే గుర్తింపు, దాని క్లయింట్ ప్రామాణీకరణ, ఆధారాలు నివసించే స్థలాన్ని ఎంచుకోండి. తర్వాత మార్గాలు, DNS, ప్రతి వినియోగదారుకు ప్రవేశ అధికారం ఉన్న వనరులను ప్రణాళిక చేయండి. ఉద్దేశించిన క్లయింట్‌ను పని చేస్తున్న కనెక్షన్‌తో కాదు, యజమాని అవసరాలతో ధృవీకరించండి.

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