د VPN ننوتل RADIUS او ستاسو د هویت وړاندې کوونکي ته څنګه رسېږي
د VPN ننوتل له کليانټ څخه د ګېټوې RADIUS غوښتنې، تر شا د هویت وړاندې کوونکي او له منلو وروسته تطبیق شوې پالیسۍ پورې تعقیب کړئ.
تېره اونۍ یوه کارن وکولای شو چې VPN ته ننوځي او بیا هم داسې شبکې ته ورسېد چې هلته هیڅ نه حل کېده۔ کليانټ وویل چې نښلول شوی، د ګېټوې لاګ وویل Access-Accept، او د هویت ټیم وویل چې حساب سم دی۔ ننوتل کار کړی و؛ تر شا اجازه نه وه۔ کله چې د VPN ننوتل ناکام شي، زه هغه لاره ځم چې غوښتنه واقعاً پرې ځي — کليانټ، ګېټوې، RADIUS سرور، د هویت وړاندې کوونکی — او په لومړي هغه ګام ودريږم چې ځواب یې له بل سره نه ځي۔
کليانټ هېڅکله RADIUS نه بولي
لپ ټاپ کې اپ هر څه وښيي، د هغې لومړی ګام د VPN پروتوکول دی: IKEv2، OpenVPN، WireGuard یا د TLS پر بنسټ کليانټ۔ RADIUS په هغه تبادله کې نه ښکاري۔ کليانټ ګېټوې ته د سند، کارن نوم او پټنوم، یا د تونل په ترتیب کې د لېږدول شوې EAP طریقي له مخې تصدیق کوي۔
لاګونه لوستل کله دا مهم دي، ځکه هغه عمومي تصدیق تېروتنه چې کارن یې ویني، ګېټوې جوړوي وروسته له دې چې لا له بل شي سره خبرې کړې وي۔ که کليانټ هېڅکله ګېټوې ته ونه رسېږي، د ډیبګ لپاره هیڅ RADIUS غوښتنه نشته، او په RADIUS سرور کې تېره یوه ساعت ضایع کېږي۔ له بیکنډ څخه مخکې تایید کړئ چې تونل خو جوړ شو۔
ګېټوې پخپله RADIUS کليانټ دی
کله چې د تونل ترتیب هغه نقطې ته ورسېږي چېرې چې اعتبارنامې باید وګړل شي، ګېټوې د شبکې د لاسرسي سرور ګرځي۔ دا Access-Request جوړوي: User-Name، پټنوم یا EAP پیلوډ، NAS-IP-Address یا NAS-Identifier، او کله چې طریقه وغواړي Message-Authenticator۔ غوښتنه په ډیفالټ ډول UDP 1812 ته ځي، او حساب 1813 ته۔ زاړه ځای پرځای کول لا هم 1645 او 1646 کاروي، نو د یوې جوړې لپاره لیکل شوی فایرول قاعده ډېرې غلې ناکامۍ تشریح کوي۔
دواړه خواوې یو راز شریکوي، او هغه د کارن اعتبارنامه نه ده۔ دا تبادله لاسلیک کوي، او هر ځواب د هغې پر وړاندې ګړل کېږي۔ راز په دواړو خواوو کې جلا تنظیم کړئ او سرور د بد راز ځواب نه ورکوي — غوښتنه غورځوي یا ځواب په ګړنه کې ناکامېږي، نو ګېټوې د وخت پای ته رسېدل راپور کوي۔ غلط راز او مړ سرور له ګېټوې څخه یو شان ښکاري, نو له دایرېکټرۍ څخه مخکې زه ګام د کليانټ وسیلې سره ازمویم۔
پروتوکول کوچنی او زوړ دی — RFC 2865 د تصدیق تبادله تعریفوي — خو هغه ځانګړتیاوې چې دا یې لېږدوي، د ډېرو VPN پالیسیو بنسټ دي۔
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS سرور کېدای شي یوازې د هویت وړاندې کوونکي مخ وي
خلک د RADIUS او د هویت وړاندې کوونکي په اړه داسې خبرې کوي لکه یو صندوق دي۔ ډېری وخت نه دي۔ RADIUS سرور Access-Request ترلاسه کوي او بیا د ځواب ورکولو دمخه له بل شي پوښتنه کوي — Active Directory د LDAP یا Kerberos له لارې، محلي کارن فایل یا بهرنی خدمت۔ FreeRADIUS د LDAP یا krb5 ماډل سره، Windows NPS او Cisco ISE ټول په دې ځای ولاړ دي۔
دا توپیر ټاکي چې چېرې وګورئ۔ رد شوی پټنوم د هویت وړاندې کوونکي ځواب دی چې RADIUS یې لېږدوي۔ د وخت پای ته رسېدل معمولاً د RADIUS څخه تر دایرېکټرۍ پورې برخه ده: پای ته رسېدلی bind حساب، نه رسېدونکې دایرېکټري، یا غوښتنه چې غلط بیکنډ ته لېږل شوې۔ که کارن نوم کې د ډومېن ضمیمه وي، سرور کېدای شي پر هغې روټ وکړي، او هماغه حساب چې د CORP\alice او [email protected] په توګه لېږل شوی، بېلو ځایونو ته رسېدای شي۔ په Windows NPS کې، Security لاګ د اجازې لپاره 6272 او د رد لپاره 6273 ثبتوي، چې وایي آیا پرېکړه له NPS څخه راغلې وه۔
ناکامي په هماغه ګام کې ولولئ چې هغه یې جوړه کړې
یو د نښلولو نه شو پیغام څلور بېلې ناکامۍ پوښي۔ له هر څه بدلولو مخکې نښه له هغه ګام سره سمه کړئ چې هغه یې جوړه کړې۔
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
وروستی کرښه هغه ده چې خلک غلط ټیم ته لېږي۔ Access-Accept معنا دا چې اعتبارنامې ومنل شوې؛ دا نه معنا چې ګېټوې کارن سم پول کې کېښود یا لارې ټېله کړې۔ د ګروپ ځانګړتیاوې یوازې هغه وخت مهمې دي چې د ګېټوې پالیسي یې لولي۔ ما لیدلي چې سم ننوتل مېلمه پول کې لوېږي، ځکه د RADIUS خوا کې د ګروپ نقشه هغه ځانګړتیا لپاره تنظیم شوې وه چې له هغې بېله ده چې ګېټوې ګوري۔
یو ننوتل له پیل څخه تر پای پورې تعقیب کړئ
یو ازموینه حساب او یوه ګېټوې وټاکئ، بیا هماغه هڅه په څلورو نقطو کې وګورئ۔ د RADIUS خوا کې ډیبګ پیل کړئ — freeradius -X غوښتنه او هر هغه ماډل چې لمسوي چاپوي — د ګېټوې تصدیق لاګ تعقیب کړئ، او د UDP تبادلې لپاره tcpdump وچلوئ۔ یو ځل ونښلئ او څلور traces په ترتیب ولولئ۔
هغه څه چې غواړئ ووینئ توافق دی: ګېټوې د هغه کارن په اړه وپوښتل چې تاسو یې تمه درلوده، RADIUS سرور هغه بیکنډ وټاکه چې تاسو یې تمه درلوده، هغه بیکنډ پرېکړه بېرته راوګرځوله، او ځواب کې ځانګړتیاوې له هغې پالیسۍ سره سمې دي چې ګېټوې تطبیقوي۔ لومړی ځای چې traces سره نه ځي ستاسو د خرابۍ کرښه ده۔ که ځواب کې د ګروپ ځانګړتیا نه وي، ستونزه په VPN پروفایل کې نه، د RADIUS خوا کې ده؛ که ځانګړتیا وي او ګېټوې له پامه غورځوي، ستونزه د ګېټوې پالیسي ده۔
هلته یاست چې یوه امنیتي یادښت۔ شریک راز تبادله ساتي، خو ډېری ځانګړتیاوې نه کوډ کوي۔ که ګېټوې او RADIUS سرور بېلو برخو کې وي، هغه ګام د TLS پر سر RADIUS یا شخصي لارې ته کېږدئ۔ کوډ شوی کارن تونل د بیکنډ تړاو په اړه هیڅ نه وایي۔
د ټکټ بندولو دمخه څلور شیان تایید کړئ۔ ګېټوې RADIUS سرور ته په هغه پورټ رسېدای شي چې واقعاً ورته تنظیم شوی۔ شریک راز په دواړو خواوو سم دی۔ RADIUS سرور د ګېټوې لېږل شوي کارن نوم دقیق شکل حلوي۔ مننه هغه ځانګړتیاوې لېږدوي چې د ګېټوې پالیسي ورته اړتیا لري۔ کله چې څلور واړه وي، هغه ننوتل چې بیا هم ناکامېږي د تصدیق نه، د ګېټوې پالیسي ستونزه ده۔