Відмова RADIUS проти відсутності відповіді: коли працює локальний вхід

Наявність локального аварійного облікового запису не робить його другою спробою для кожного відхиленого входу. У моделі AAA Cisco 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

Потім відновіть попередню конфігурацію й підтвердьте, що лічильники знову рухаються під час наступного реального входу. Якщо навмисна відмова дає локальний вхід замість відмови, то список або обробка збоїв не такі, як ви вважали, і ця знахідка важливіша за збій, з якого ви почали. Запишіть результат у журнал змін поруч з іменами облікових записів і датою тесту.