ولې یوازې PPP CHAP د MPPE غوښتنه نه شي پوره کولی

هغه PPTP پروفایل چې پر کوډ کولو ټینګار کوي، معمولاً په هماغه ځای کې ناکامېږي: PPP پر داسې تصدیق کولو تبادله موافقه کوي چې هېڅکله د MPPE لپاره اړین کیلي توکي نه تولیدوي۔ تونل نیم ژوندی ښکاري، پټنوم منل کېږي، او اړیکه مخکې له دې چې کومه ترافیکه ترې تېره شي پرې کېږي۔ تر هغه چې یو څه ونښلي 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 پای ټکي کې اړوند تنظیمات په pppd د اختیارونو فایل کې دي چې pptpd یې لېږدوي۔ دا په سرور باندې چل کړئ، نه د کلاینټ د حالت له سکرین۔ له هغو کرښو پیل وکړئ چې د ساتنې حالت غواړي، ردوي یا نوموي:

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 او هغه سرچینې پلان کړئ چې هر کاروونکی پرې اجازه لري۔ پام شوی کلاینټ له کار کوونکې اړیکې سره نه، بلکې د مالک له غوښتنو سره سم وګورئ۔

په قصد شوې ردول باید ردول پاتې شي، ځکه چې د ازموینې د تېرولو لپاره بې ساتنې حالت ته پر شا تګ د پالیسۍ ناکامي په افشا بدلوي۔ بشپړ حالت یو ملاتړ شوی، مستند تړون دی، نه د بدلونونو هغه لږترلږه ټولګه چې یوه زوړه اړیکه بریالۍ کوي۔ زوړ پروفایل په خپل ځای، نااستعمال شوی او مستند پرېږدئ، تر هغه چې بدیل هماغه څېړنې پاس کړي۔