EAP د VPN دروازې له لارې: څوک طریقه پای ته رسوي

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

په لاګ کې ورته ښکاره دوه تصدیق لارې

په لومړۍ لاره کې VPN دروازه کارن نوم او پټنوم راټولوي او د پټنوم ځانګړتیا سره RADIUS Access-Request لېږي. تصدیق سرور هغه له خپل ذخیره سره پرتله کوي او د منلو یا رد ځواب ورکوي. کلاینټ هېڅکله د EAP طریقه نه چلوي، ځکه چې چا غوښتې نه وه.

په دوهمه لاره کې کلاینټ او تصدیق سرور د EAP طریقه له پیل څخه تر پای پورې چلوي، او دروازه د دوی ترمنځ د EAP-Message ځانګړتیاوې لېږي. دروازه لا هم باندنۍ RADIUS خبرې اترې پای ته رسوي، خو د طریقي منطق په دوو سرونو کې دی.

دواړه لارې په لاګ کې یوه کرښه جوړوي چې تصدیق ناکام شو. یوازې پر دوهمه دې اغېزه کولی شي چې سرور کومه EAP طریقه غوره ګڼي، او یوازې پر لومړۍ هغه چې دروازه پټنوم څنګه لولي. دوی د بدلېدونکو په توګه ګڼل هغه سبب دی چې ټیمونه ټول ورځ د هغه کلاینټ لپاره سرور ګروپونه بدلوي چې هېڅکله نه غوښتل PEAP ووايي.

طریقه واقعاً چېرته چلېږي

RFC 3579 د تېرېدو ترتیب تعریفوي: NAS د EAP بنډلې په RADIUS ځانګړتیاوو کې وړي او د هر EAP ډول لپاره طریقي ځانګړی کوډ نه غواړي. نو ځکه دروازه کولی شي PEAP او EAP-TLS دواړه پرته له دې چې یو یې هم پلي کړي ملاتړ کړي.

هغه دروازه چې پټنوم لېږي PEAP نه وړي، حتی که شاته سیستم له بل کلاینټ څخه PEAP ومني. په سرور پالیسۍ کې PEAP فعالول هغه کلاینټ ته طریقه نه ورزیاتوي چې هېڅکله یوه هم نه وه وړاندې کړې.

د PPP تصدیق تنظیمات د PPP خدمت دي. دوی هره هغه IPsec یا زړه XAuth لاره چې ورته AAA سرور کاروي په خاموشۍ کې بیا تنظیم نه کړي، نو یو بدلون چې د یوې لاسرسي ډول لپاره کار کوي کولی شي بل لاس نه خوړلی پرېږدي.

NAS باید څه ملاتړ وکړي

تېرېدل غوښتنه د طریقي کوډ څخه د وړونکي ملاتړ ته بېځایه کوي. دروازه باید وکولی شي EAP د خپل VPN پروتوکول له لارې ووړي، او پر هغې RADIUS کلاینټ باید د اړوندو اندازو EAP-Message ځانګړتیاوې ولېږي او ترلاسه کړي.

د IKEv2 لپاره EAP د تعریف شوي تصدیق بهیر برخه ده، او د سرور هویت او باور څېړنې له همدې بهیر څخه راځي. له 802.1X ځای پرځای کولو پور اخیستل شوې PEAP نښه په اتوماتيک ډول نه تېرېږي، ځکه چې د هغې شاوخوا خبرې اترې توپیر لري.

د کلاینټ اړخ هم غوښتنې لري. باید د طریقي لپاره تنظیم شوی وي، د طریقي لخوا وړاندې شوي سرور سند باور وکړي، او داسې اعتبارنامې ولري چې طریقه یې کارولی شي. پر سند ولاړه طریقه پرته له کلاینټ سند د RADIUS له څه لیدو دمخه ناکامېږي، او دا د سرور پالیسۍ نه بلکې د برابرولو ستونزه ده.

د پالیسۍ له بدلولو مخکې یوه هڅه ولولئ

په دروازه او تصدیق سرور کې یوه منل شوې هڅه ثبت کړئ. په RADIUS غوښتنه کې د EAP-Message ځانګړتیاوې ولټوئ. د دوی شتون وایي چې د تېرېدو لاره کارېږي؛ نه شتون یې د اعتبارنامو تبادلې ته اشاره کوي.

په Linux دروازه کې د RADIUS پورټ ثبت ښیي چې په تار کې کومې ځانګړتیاوې دي:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

بیا د رد نقطې پرتله کړئ. په دروازه کې د هر RADIUS بنډل دمخه ناکامي معنا دا ده چې کلاینټ او دروازه د طریقي په اړه سره نه وو موافق. د EAP ځانګړتیاوو سره RADIUS رد معنا دا ده چې دواړو سرونو طریقه چلولې او یو یې نتیجه رد کړه.

لېږد د یوې له سره تر پای پورې بدلون په توګه پلان کړئ

د طریقي بدلول معنا دا ده چې د کلاینټ تنظیم، د دروازې د وړونکي ملاتړ، د سرور د طریقي پالیسي او د اعتبارنامو ذخیره یوځای بدل کړئ. دا په همدې ترتیب وکړئ او تر هغه چې نوی ثابت شي یوه کاري لاره وساتئ. یوازې د سرور اړخ بدلون اټکل دی او معمولاً هغه کلاینټونه ماتوي چې کارېدل. له ګروپ څخه د لاس وهلو دمخه بدلون پر یوه ازموینه هویت چمتو کړئ.

هغه ترکیب ولیکئ چې کار کوي: VPN پروتوکول، EAP وړونکی، د سیال طریقه، د سرور طریقه، د اعتبارنامې ډول او د سرور هویت څېړنه.

اداري AAA ننوتل له VPN تصدیق څخه جلا وساتئ، پرته له دې چې دنده په څرګنده دواړه شامل کړي. د لرې لاسرسي لپاره بدلون باید ستاسو د هغه وسیله اداره کولو وړتیا ونه اخلي چې هغه پای ته رسوي.