د VPN ننوتل د RADIUS Access-Challenge وروسته ودروي

ستاسو پټ نوم سم دی، VPN ننوتل بیا هم ناکامېږي، او کېدای شي RADIUS سرور هغه څه کړي وي چې ورته ویل شوي وو. ګیټ وے ښايي Access-Challenge ترلاسه کړی، څه ګټور یې نه دی ښودلی، او بیا یا وخت پای ته رسېدلی یا هغه ځواب یې د رد په توګه منلی. د کلاینټ له اړخه دا د غلطو اعتبارنامو یا مات شوي تونل په څېر ښکاري. لامل معمولاً د هغې خبرې په منځ کې وي چې چا نه ده ثبت کړې.

یو ننوتل، دوه RADIUS تبادلې

کله چې شاتنی نظام دوهم فکتور غواړي، هغه لومړي غوښتنې ته د منلو یا رد په ځواب نه ورکوي. هغه د 11 کوډ سره ځواب ورکوي او د کاروونکي بل ځواب ته انتظار کوي، کوم چې ګیټ وے باید په یوه تعقیبي غوښتنه کې بېرته ولېږي. هغه تعقیبي غوښتنه د همدې تصدیق خبرې اړه لري، نه د نوي ننوتلو هڅې.

په سمه سمون کې کاروونکی دوهمه پوښتنه ویني: لومړی پټ نوم، بیا یو ځل کارېدونکی کوډ، یا یوه یوځای شوې پوښتنه که آپریټر یې مستند کړې وي. په ماتې سمون کې دوهمه پوښتنه هېڅکله نه ښکاري او ننوتل یوازې ناکامېږي.

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

ننګونه په رښتیا کې څه وړي

د RADIUS مشخصات په 4.4 برخه کې د 11 کوډ تشریح کوي او دوه هغه ځانګړنې اجازه ورکوي چې دلته مهمې دي. Reply-Message د کاروونکي لپاره متن لري، او State یو ناڅرګند ارزښت لري چې سرور یې بېرته غواړي. NAS باید State تفسیر نه کړي، یوازې باید بې بدله یې بېرته ورکړي.

تعقیبي غوښتنه نوی Identifier او نوی Request Authenticator کاروي، او باید هماغه State ارزښت او د کاروونکي ځواب ولېږدوي. سرور هغه د هماغه State له لارې له انتظار کې ننګونې سره سمون ورکوي، ځکه همدا لامل دی چې هغه ګیټ وے چې ځانګړنه بیا جوړوي یا غورځوي دغه مراسم بشپړولی نه شي. په هر ځواب کې response authenticator هم باید تایید شي، که نه NAS باید پاکټ وغورځوي.

4.4 برخه هغه تفصیل زیاتوي چې ډېری غلي ناکامۍ تشریح کوي: هغه NAS چې د ننګونو ملاتړ نشي کولی Access-Challenge د رد په توګه ګڼي. که ستاسو د ګیټ وے VPN خدمت له دې ملاتړ څخه زوړ وي یا یې پرېږدي، شاتنی نظام غوښتنه د دوهم فکتور لپاره پرته له کومې ننګونې سملاسي «تصدیق ناکام شو» ګرځي.

زنجیره یي غوښتنه چېرې ورکېږي

لومړی شکمن د اعتبارنامو نه، د ننګونې لاره ده. هغه پورټل چې د ویب ننوتلو لپاره د OTP ساحه ښيي، دا د VPN خدمت لپاره په اتوماتيک ډول نه کوي، او ځینې ګیټ وے ننګونه یوازې هغو کلاینټونو ته رسوي چې دې وړتیا اعلانوي. هماغه حساب په دواړو ننوتلو نقطو کې وآزمویئ؛ که پورټل کار وکړ او VPN ونه کړ، تاسو سپارل ګورئ، نه ټوکن.

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

د خپرېدو ځانګړي عیبونه شته، خو د کلونو دمخه سم شوو نسخو لړلیک د نن ورځې د ځای پرځای کولو تشخیص نه دی. د هغه سافټویر د خپرېدو یادښتونه ولولئ چې تاسو یې واقعاً چلوئ، او مشاهده شوې تبادلې پړاو د خپل شاهد په توګه وساتئ.

یوه هڅه له سره تر پای پورې تعقیب کړئ

له سرور اړخ څخه ډیبګینګ چالان کړئ او یو ځل بیا تولید یې کړئ، او هر بل سیشن د نیولو کړکۍ څخه بهر وساتئ:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

په پایله کې د یوې کرښې پرځای د خبرې بڼه ولټوئ. لومړی Access-Request د Identifier 3 سره، یوه Access-Challenge چې State وړي، بیا دوهمه Access-Request د Identifier 4 سره چې هماغه State تکراروي او د کاروونکي ځواب پکې دی. که دوهمه غوښتنه نه وي، ګیټ وے هېڅکله تعقیب نه دی کړی. که پرته له State راشي، سرور نشي کولی هغه له انتظار کې ننګونې سره سم کړي او معمولاً رد یې کوي.

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

د هغه وروستي حالت چې غواړئ عبارت دی له بشپړې، مجازې خبرې او بیا له هغې وروسته د خدمت هغه لاسرسی چې موخه وه. د RADIUS سرور څخه راغلی ځواب له دې څخه ډېر لږ ثبوت کوي.