رد RADIUS در برابر نبود پاسخ: چه زمانی ورود محلی اجرا میشود
AAA رد شدن و سرور در دسترس نبودن را دو نتیجه متفاوت میداند. مسیر پشتیبان فقط حالت دوم را پوشش میدهد، بنابراین نخست فهرست روشها و کد پاسخ را بخوانید.
نگه داشتن یک حساب محلی اضطراری آن را به فرصت دومی برای هر ورود ردشده تبدیل نمیکند. در مدل AAA سیسکو IOS و IOS XE، به آن پایگاه داده تنها زمانی مراجعه میشود که روش پیشین به شکل مشخصی شکست بخورد، و سرور RADIUS که با رد پاسخ میدهد به آن شکل شکست نخورده است. حساب محلی روشی را پوشش میدهد که در دسترس نیست، نه روشی را که رد شده است. باور به خلاف این، یک تصمیم سیاستی را به جستجوی نقص سروری تبدیل میکند که وجود ندارد.
چرا فهرست روشها مانند نردبان به نظر میرسد
خطی مانند aaa authentication login default group radius local از چپ به راست خوانده میشود، و بیشتر مردم آن را اینگونه میخوانند که RADIUS را امتحان کن، سپس پایگاه داده محلی را امتحان کن. نحو به این خوانش دعوت میکند چون فهرست یک توالی است. معناشناسی تنگتر است: فهرست روشهای احراز هویت را نام میبرد، و قاعده رفتن از یکی به بعدی به نتیجه روش پیشین بستگی دارد، نه به دادن یک تلاش دیگر به کاربر.
روشی که خطا برمیگرداند و روشی که شکست برمیگرداند اینجا به نتایج متفاوتی میرسند. رد شدن یک پاسخ است، چون سرور اعتبارنامهها را پردازش کرد و نه گفت، و فهرست همانجا متوقف میشود. سرور در دسترس نبودن، درخواست منقضی یا پاسخی که قابل اعتبارسنجی نیست حالتی است که روش بعدی را اجرا میکند، و فقط جایی که مدیریت خطای سکو اینگونه پیکربندی شده باشد. به همین دلیل توصیه کلاسیک افزودن local در قطعیها کار میکند و در رمزهای اشتباه هیچ کاری نمیکند. بهجای آن فهرست را دو پرسش بخوانید: کدام روش پاسخ میدهد، و سکو چه چیزی را پاسخ میشمارد.
فهرست روشها را از گروه سرور جدا کنید
فهرست روشها یک لایه است و گروه سرور لایه دیگر. کلیدواژه group radius گروهی را نام میبرد که ترتیب داخلی، تلاشهای مجدد، مهلتها و تشخیص سرور مرده به گروه تعلق دارد، در حالی که روش محلی لایهای بالاتر از آن است. بنابراین تنظیم هر چیزی درون گروه نمیتواند رد شدن را به مسیر پشتیبان تبدیل کند. پیش از تغییر هر یک از دو لایه تأیید کنید که سرویس واقعاً به کدام فهرست ارجاع میدهد.
پیکربندی AAA را چاپ کنید و فهرستی را بخوانید که سرویس به آن اشاره میکند، نه مقدار پیشفرضی که به یاد دارید نوشتهاید. این کار را از دستگاهی انجام دهید که سرویس واقعاً روی آن پایان مییابد.
show running-config | section aaa
show radius server-group RAD-GRP
show aaa serversجدول سرورها وضعیت و شمارندههای هر ورودی را گزارش میکند، که به شما میگوید آیا دروازه در طول تلاش به سرور رسیده است یا نه. سروری که با شمارنده درخواست افزایشی بهعنوان فعال علامت خورده است پاسخ میداده، پس ورود ناموفق یک تصمیم است نه مشکل اتصال.
پاسخ را پیش از گزارش بخوانید
کد پاسخ نتیجه را نام میبرد و گام بعدی خود را ایجاب میکند. Access-Reject یعنی بخش پشتی تصمیمی گرفته است، پس شواهد مفید سیاستی است که مطابقت داشته و وضعیت حسابی که پشت آن است. Access-Challenge یعنی تبادل گام پشتیبانیشده دیگری مانند عامل دوم میخواهد، و مسیر پشتیبان محلی بیصدا چیزی را که سیاست میخواهد نادیده میگیرد.
یک تلاش را با حساب آزمایشی تعیینشده بازتولید کنید تا پاسخ و رکورد بخش پشتی در همان برچسب زمانی مقایسه شوند. از اعتبارنامهای استفاده کنید که شکست دادنش برای شما مجاز است.
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authenticationورودی مشتری RADIUS گمشده یا ناشناخته علت رایج مهلت بیصدا است، چون سرور درخواست را دریافت میکند، تعریف مشتری مطابقی پیدا نمیکند و آن را بدون پاسخ دور میاندازد. ناسازگاری رمز مشترک هم معمولاً مانند مهلت به نظر میرسد، چون پاسخ در اعتبارسنجی شکست میخورد و کنار گذاشته میشود. هیچیک از اینها مانند Access-Reject نیست، و هیچیک با افزودن حساب محلی درست نمیشود. پیش از دست زدن به فهرست روشها، تعریف مشتری و رمز را در هر دو طرف بررسی کنید.
چرا حساب محلی هرگز چیزی را اثبات نکرد
حسابی که در فهرست پس از یک گروه میآید فقط اثبات میکند که کسی برای یک قطعی برنامهریزی کرده است. درباره اینکه آیا برنامه کار میکند چیزی نمیگوید، چون حالتی که آن را میآزماید همان حالتی است که هیچکس تمرین نمیکند: سرور پاسخ دادن را متوقف کرد. یک ورود محلی که در کار عادی هرگز به آن نمیرسند میتواند ماهها رمز منقضی یا وضعیت قفلشده داشته باشد بدون اینکه کسی متوجه شود.
دسترسی اضطراری یک تصمیم طراحی است، نه عارضه جانبی پیکربندی. به آن حساب محدود خودش، مسئول خودش و رویه بازیابی نوشتهشده بدهید، و چرخش رمز مشترک را در همان رویه بگنجانید. نگه داشتن رمز محلی با نام یکسان برای هر کاربر مرکزی همان الگویی است که بیصدا دسترسیای را که فکر میکردید حذف کردهاید برمیگرداند.
آزماشی که اهمیت دارد عمدی است، و در حین اجرا ورودها را قطع میکند. دقیقاً به همین دلیل به پنجرهای زمانبندیشده تعلق دارد که گام بازگشت در آن نخست نوشته شده است.
مسیر پشتیبان را در پنجره نگهداری بررسی کنید
آزمایش را طوری ترتیب دهید که هرگز آخرین راه ورود را حذف نکنید. نخست یک مسیر مدیریت مستقل را تأیید کنید، سپس دسترسی مجاز عادی، سپس رد عمدی، سپس رفتار قطعی تأییدشده. این چهار حالت نتایج مورد انتظار متفاوتی دارند، و ادغام آنها در یک آزمایش همان روشی است که مردم خود را بیرون از دستگاهی قفل میکنند که هنوز به آن نیاز دارند.
هر بررسی را از یک نشست کنسول یا از مسیری بیرون از باند اجرا کنید، تا خطایی نتواند نشستی را که در آن کار میکنید ببندد. کنسول تنها مسیری است که به قطعه تحت آزمایش وابسته نیست.
show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacyپس از آن، پیکربندی پیشین را بازگردانید و تأیید کنید که شمارندهها در ورود واقعی بعدی دوباره حرکت میکنند. اگر رد عمدی بهجای رد شدن، ورود محلی تولید کند، آنگاه فهرست یا مدیریت خطا آن چیزی نیست که باور داشتید، و این یافته از قطعیای که با آن شروع کردید مهمتر است. نتیجه را در رکورد تغییر کنار نام حسابها و تاریخ آزمایش بنویسید.