IKEv2 NO_PROPOSAL_CHOSEN: کوم پړاو ټولګه رد کړه؟

په لاګ کې NO_PROPOSAL_CHOSEN خلک مخکې شریک شوي کیلي ته لیږي، او تېروتنه له بدلون وروسته هم پاتې کیږي. دا هیڅکله د اعتبارنامې ستونزه نه وه: همکار د هغې تبادلې لپاره وړاندیز شوی هر وړاندیز رد کړ، چې دا د هویت نه، بلکې د الګوریتمونو په اړه خبره ده. لومړی ګټور پوښتنه دا نه ده چې کوم الګوریتم سمول شي، بلکې دا ده چې کومه تبادله رد شوه. له هرې پرتلې مخکې دې پوښتنې ته ځواب ورکړئ. بیا بشپړه وړاندیز شوې ټولګه د همکار له خوا اجازه ورکړل شوې بشپړې ټولګې سره پرتله کړئ.

لومړی: کومه تبادله رد شوه

IKEv2 د دوو ډولونو اتحادیې باندې خبرې اترې کوي. IKE SA پخپله خبرې اترې ساتي، او CHILD SA ترافیک ساتي. هر یو خپله وړاندیز ټولګه لري، او هر یو کولای شي په ورته خبرتیا سره ناکام شي. د لومړنیو IKE خبرو اترو پر مهال ردول او د CHILD خبرو اترو پر مهال ردول بېلابېل سمونونه غواړي، او لاګ معمولاً د خبرتیا له یوې یا دوو کرښو پورته د تبادلې نوم اخلي. هغه دوه کرښې یوځای ولولئ، که نه نو غلطه وړاندیز لیست به سم کړئ.

یوازې خبرتیا تبادله نه پېژني. د هغې پورته کرښه د خبرو اترو شوې SA نوم اخلي، او هغه نوم د کتلو وړ وړاندیز لیست ته اشاره کوي.

بشپړې ټولګې پرتله کړئ، نه جلا کیلیدونه

وړاندیز یو ترکیب دی: د انکرپشن الګوریتم، بشپړتیا یا AEAD، د کیلي تبادلې ګروپ، او هر ډول سیوډو-تصادفي فنکشن. یوازې د انکرپشن نوم پرتله کول معمولي تېروتنه ده، ځکه دوه همکاران کولای شي په AES-256 سره موافق شي او بیا هم په SHA-1 او SHA-256 کې اختلاف ولري. په ناکام پړاو کې وړاندیز شوې او اجازه ورکړل شوې ټولګې څنګ په څنګ ولیکئ، بیا خالي تقاطع وپلټئ.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

همدا راز وګورئ چې دواړه تطبیقونه هغه څه ملاتړ کوي چې تاسو تنظیم کړي دي. له بل پلیټفارم څخه کاپي شوی نوم ممکن په نحوي توګه آشنا ښکاره شي په داسې حال کې چې پلګین یا تطبیق په بشپړ ډول نشته.

IKE ټولګه او ESP ټولګه بېلابېل شیان دي

د IKE وړاندیز سمول به رد شوې CHILD وړاندیز سم نه کړي، او برعکس یې هم سم دي. په strongSwan کې دا جلا تنظیمات دي، نږدې د IKE SA لپاره proposals = aes256-sha256-modp2048 او د CHILD SA لپاره جلا ESP لیست. هغه لیست بدل کړئ چې له ناکامې تبادلې سره سمون لري، بیا لاګ بیا ولولئ پرته له دې چې فرض کړئ سمون یې کړی دی.

د CHILD SA لپاره اړوند تنظیم د ESP وړاندیز لیست دی، نه د IKE لیست. د IKE کرښه پکې کاپي کول داسې ترتیب جوړوي چې پارس کیږي خو غلط شی باندې خبرې اترې کوي.

کار کوونکی تونل چې د کیلي نوي کولو پر مهال ناکام شي

که تونل یوه ساعت کار وکړ او بیا ناکام شو، لومړنۍ خبرې اترې ستونزه نه ده. د کیلي نوي کول کولای شي نور شرایط وآزمويي: د لومړي تبادلې وروسته بېل د کیلي تبادلې ګروپ، د همکارانو ترمنځ د عمر ناسمونې، یا بدل شوې د ځواب ورکوونکي پالیسي. له دواړو خواوو د نوي کولو وخت ټاک او د اتحادیې پېژندونکي وساتئ. داسې بڼه د نوي کولو پر مهال د وړاندیزونو پرتله غواړي، نه اوږد مهال حد. د مهال حد بدلول نښه پټوي او ناسمونه په خپل ځای پرېږدي.

ipsec statusall هر اتحادیه او هغه الګوریتمونه ښیي چې واقعاً پرې موافقه شوې ده. هغه پایله د دې تصدیق کولو ترټولو ګړندۍ لاره ده چې کوم لیست کارول شوی، او د ترتیب تېروتنه له هغه زوړ تونل څخه بېلوي چې هیڅکله بیا خبرې اترې پرې نه دي شوې.

ipsec statusall | grep -E "IKE:|ESP:"

یوه تقاطع وټاکئ، بیا دواړه پړاوونه تصدیق کړئ

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

منل شوی ترکیب د فرم ویئر نسخو سره یوځای وساتئ. که بله تېروتنه د ترافیک ټاکونکو په اړه وي، جلا یې وګورئ، ځکه چې د کریپټوګرافي په اړه موافقه د دې په اړه هیڅ نه وایي چې تونل کومې فرعي شبکې ساتي. strongSwan د وړاندیزونو اسناد د دواړو لیستونو نحو پوښي.