ولې RADIUS د VPN کارن نوم پر ځای د IP پته ویني
strongSwan کولی شي د IKE هویت له هر EAP تبادلې مخکې په RADIUS User-Name کې کېږدي. پرېکړه وکړئ چې د حساب هویت څوک غواړي، بیا یوه هڅه سره ونښلئ.
د Windows IKEv2 کلاینټ نښلوي، او د RADIUS غوښتنه د پتې سره رسیږي چېرې چې باید د حساب نوم وي۔ تر اوسه هېڅ ناکام نه دی شوی، او ګډوډي برخه همدا ده: دروازه هغه هویت راپور کوي چې کلاینټ په IKE طبقه کې وړاندې کړی۔ د کارن هغه نوم چې ستاسو بیکنډ غواړي ممکن له جلا EAP تبادلې څخه راشي چې تر اوسه نه ده شوې۔ د حساب له بدلولو مخکې پرېکړه وکړئ چې څوک یې غواړي۔
په یوه اړیکه کې دوه هویتونه سفر کوي
په یوه اړیکه کې دوه نومونه ښکارېدلی شي۔ IKE هویت د تونل د جوړولو پر مهال سیال پېژني، او eap-radius پلګین لومړی هغه په RADIUS User-Name کې کاپي کوي۔ EAP هویت بېل ارزښت دی چې د کارن د تصدیق لپاره کارېږي، او که څوک یې ونه غواړي ممکن هېڅکله ونه لېږل شي۔
له همدې امله د RADIUS لاګ پته ښودلی شي پداسې حال کې چې حساب شته او پټنوم سم دی۔ له بیکنډ څخه د غلطې طبقې په اړه پوښتنه کېږي۔ د RADIUS ځانګړتیا یوازې د غوره شوي نوم لېږدونکې ده۔
له دروازې وغواړئ چې EAP هویت وغواړي
یو ملاتړ شوی ترتیب دروازه ته اجازه ورکوي چې د تصدیق له RADIUS ته سپارلو مخکې EAP هویت وغواړي۔ د اړیکې د لرې تصدیق په برخه کې، طریقه eap-radius ته وټاکئ او EAP هویت په ښکاره توګه وغواړئ۔ لاندې ټوټه په خپل فایل کې نه، بلکې د موجودې اړیکې بلاک دننه راځي۔ له بل ځایګي څخه د سینټکس له کاپي کولو مخکې اړیکه او د ترتیباتو بیکنډ تایید کړئ۔
remote {
auth = eap-radius
eap_id = %any
}په دې سره بیکنډ د IKE پتې پر ځای هغه هویت ترلاسه کوي چې کلاینټ په EAP تبادله کې ورکوي۔ په اړیکه کې نور هېڅ نه بدلېږي۔
یا پرېږدئ چې RADIUS د EAP تبادله پیل کړي
بل ترتیب لومړی ګام د RADIUS په خوا کې پرېږدي۔ پلګین کولی شي د لومړني هویت ځواب د انتظار پر ځای د EAP-Start اشاره ولېږي، چې سرور ته اجازه ورکوي تبادله پر مخ یوسي۔ دا د پلګین کچې ترتیبات دي، نو په هره اړیکه چې پلګین کاروي اغېز کوي۔
charon {
plugins {
eap-radius {
eap_start = yes
}
}
}د دواړو د فعالولو او هیله کولو پر ځای له RADIUS آپریټر سره یو ترتیب وټاکئ۔ دوی بېلابېل کاري بهیرونه بیانوي، او هغه سرور چې د پیل کولو تمه لري ممکن هغه دروازه ونه شي سمبالولی چې خبرې پیلوي۔ د پلګین اسناد دواړه بیانوي، په دې کې چې هر ګام کوم هویت لېږدوي۔
یوه هڅه په دواړو لاګونو کې تعقیب کړئ
یوه هڅه په دواړو لاګونو کې سره ونښلئ۔ IKE هویت وګورئ، بیا چې EAP-Identity تبادله کېږي که نه، بیا چې د تصدیق ګام کوم نوم ترلاسه کوي۔ هغه بیکنډ چې له EAP تبادلې مخکې پته ردوي کولی شي بهیر مخکې ودروي تر څو ستاسو پام شوی هویت هېڅکله ونه لیدل شي۔
journalctl -u strongswan -fد هویت سیستم هغه دقیق کارن نوم بڼه وساتئ چې تمه یې لري، د ډومین مختاړي سره۔ هېڅکله د پتې بڼې ارزښت څخه حساب جوړ نه کړئ، او د سیاست د قاعده د پوره کولو لپاره هېڅکله تصدیق بند نه کړئ۔ EAP هویت یو اعلان شوی نوم دی، او طریقه باید لا هم هغه ثابته کړي۔ پایله نوم په ازموینه ریکارډ کې ولیکئ تر څو بله هڅه له پېژندل شوي حالت څخه پیل شي۔
که سم شوی بهیر سم حساب ته ورسېږي او بیا هم رد شي، بل شاهد هویت نه، بلکې EAP طریقه او د بیکنډ سیاست دی۔ د پټنوم بیا تنظیم تکرارول نشي کولی په پخوانۍ پروتوکول طبقه کې غوره شوی ارزښت سم کړي۔