L2TP NO_PROPOSAL_CHOSEN: کوم پړاو واقعاً ناکام شو؟
خبرتیا وایي چې یوه وړاندیز رد شو، نه دا چې کوم یو۔ د پړاو لپاره د backend لاګ ولولئ، بیا د ګیټوې چلولوونکي سره سویټونه پرتله کړئ۔
NO_PROPOSAL_CHOSEN د دې دمخه راځي چې کوم PPP کارننوم وڅیړل شي، دا یوه ګټوره حقیقت دی او همدا لامل دی چې پیغام ګمراه کوي۔ دا راپور ورکوي چې یو لوري وړاندیز رد کړ؛ دا نه راپور ورکوي چې کوم پارامیټر سم نه و، او د دې په اړه هم هیڅ نه وایي چې ردول د IKE اړیکې د جوړولو پر مهال شوي که وروسته د ټرافیک د ساتنې پر سر خبرو پر مهال۔ د دې دوو امکانونو تر شا دوه بېل سمونونه دي، او یوازې یو یې هغه PFS چیکباکس ته اړه لري چې خلک لومړی ورته لاس اچوي۔
یو پیغام، دوه وړاندیز سیټونه
د IKEv1 L2TP/IPsec ترتیب کې دوه خبرې پرلهپسې کیږي۔ پړاو 1 د کوډکولو الګوریتم، د بشپړتیا الګوریتم او د Diffie-Hellman ګروپ څخه د IKE امنیتي اړیکه جوړوي۔ بیا پړاو 2 پر دې خبرې کوي چې ټرافیک به څنګه وساتل شي، او د PFS غوښتنه همدغه دوهمې خبرې ته اړه لري۔
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
ځکه چې پړاوونه پرلهپسې دي، د ناکامۍ ځای درته وایي چې کومه لیست پرتله کړې۔ د پیغام ټول تشخیصي ارزښت همدلته دی، او د هر تنظیم له لاس وهلو دمخه یې راویستل ښه دي۔
ولې PFS چیکباکس پړاو 1 نه شي سمولای
د PFS بندول د پړاو 2 یوه ځانګړنه بدلوي۔ که لوري هیڅکله پر پړاو 1 سره یو نه شول، د ESP خبرې هیڅکله نه کیږي، نو چیکباکس پر ردولو هیڅ اغیزه نه لري، او همدا لامل دی چې بدلول یې هماغه تېروتنه د بېل وخت ټاپې سره راوړي۔
په عکس تېروتنه هم هماغسې عامه ده۔ یوه بریالۍ IKE اړیکه نه ثابتوي چې د ESP وړاندیز منلو وړ دی، او هېڅکله نه ثابتوي چې د پړاو 2 ګروپ سره سمون لري۔ رامنځته شوې مدیریتي تونل یوازې د پړاو 1 په اړه شاهد وګڼئ۔ خلک شنه کرښه «تونل روان دی» لولي، بیا په غلط پړاو کې یوه ساعته ضایع کوي ځکه چې چا ورته نه و ویلي چې دوهمه خبرې نه وه پیل شوې۔
د الګوریتمونو له ټاکلو دمخه لاګ ولولئ
د ردولو سمدلاسه دمخه پیغامونه له هغه backend څخه راټول کړئ چې واقعاً اړیکه سمبالوي، او له هماغه هڅې سره یې وتړئ۔ پرته له دې تړاو تاسو د بلې اړیکې تاریخ لولئ او ترې پایلې اخلئ۔
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanله هغو کرښو دوه پوښتنو ته ځواب ووایاست: آیا د پړاو 1 اړیکه رامنځته شوه، او کومه تبادله ناکامه شوه۔ دا دوه ځوابونه پلټنه یوې ځانګړنې لیست ته محدودوي۔ پرېوتې خبرتیا پرته له شاوخوا شرایطو دا نه شي کولای، هرڅومره زړهړبا وي چې له فورمې تار څخه وړاندیز وآزموی۔ د بل backend لرونکي ماشین څخه د کارکوونکي سټرینګ کاپي کول معمولاً یو ردول په بل، لږ وروسته، بدلوي۔
د backend نحو سفر نه کوي
له هر څه پرتله کولو دمخه د NetworkManager-l2tp نسخه او د IPsec backend نسخه ولیکئ۔ Libreswan او strongSwan نه د وړاندیز نحو شریکوي او نه یو شان الګوریتم سیټونه، نو هغه سټرینګ چې په یوه کې کار کوي په بل کې نحوي تېروتنه ده۔ نصب شوی backend کولای شي IKEv1 هم د پالیسۍ له مخې رد کړي، او بیا به هیڅ وړاندیز هېڅکله ومنل شي۔
د پروژې README هغه backend توپیرونه مستند کوي او د پړاو 1 او پړاو 2 ساحې جلا ساتي۔ دا د جوړښت د سند په توګه ولولئ، نه د هر تاریخي سایفر او یوه کمزوري ګروپ د فعالولو بلنې په توګه، ځکه هغه اړیکه چې یوازې همداسې بریالۍ کیږي هغه اړیکه نه ده چې جوړول یې غوښتل شوي وو۔
پر سیټ سره موافقه وکړئ، بیا پړاوونه تایید کړئ
د ګیټوې آپریټر څخه وپوښتئ چې کوم IKE او ESP سیټونه ملاتړ شوي او تصویب شوي، بیا هغه ځواب د کارن د اصلي وړاندیزونو سره پرتله کړئ، نه د هغه د ترتیباتو فایل سره۔ که اختلاف په ځانګړي ډول د پړاو 2 PFS په اړه وي، پر یوه ملاتړ شوې ګروپ یا په روښانه ډول تصویب شوې پرته له PFS پالیسۍ پریکړه وکړئ۔ پالیسي د تېروتنې له نوم څخه مه اخلئ۔
کله چې یوازینی تګلار د سره کېدلو لپاره داسې کوډکول غواړي چې سازمان یې نور نه مني، پریکړه ګیټوې یا د پروتوکول لېږد ته اړه لري۔ د کارن سټرینګ پراخول تر دې چې یو څه خبرې وکړي، د پېژندل شوې کمزورۍ د څنګ کې شنه نښه لګولو لاره ده۔
له واقعي ناسمونې د سمولو وروسته، د L2TP او PPP له څیړنې دمخه د IPsec رامنځته کېدل تایید کړئ، او هر وروستی تصدیق ردول د بل پړاو ګڼئ۔ بیا په تصویب شوې ازموینې بهیر کې نوي کول وآزمویئ، ځکه د لومړنۍ اړیکې رامنځته کېدل د هغې د پاتې ژوند په اړه هیڅ نه وایي۔