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 є частиною визначеного потоку автентифікації, і перевірки ідентичності та довіри сервера походять із цього потоку. Мітка PEAP, позичена з розгортання 802.1X, не переноситься автоматично, бо узгодження навколо неї інше.

У клієнтської сторони теж є вимоги. Вона має бути налаштована на метод, довіряти сертифікату сервера, який пред'являє метод, і мати облікові дані, які метод може використати. Метод на основі сертифікатів без клієнтського сертифіката зазнає невдачі раніше, ніж RADIUS щось побачить, і це проблема забезпечення, а не політики сервера.

Прочитайте одну спробу, перш ніж змінювати політику

Захопіть одну схвалену спробу на шлюзі та на сервері автентифікації. Шукайте атрибути EAP-Message у запиті RADIUS. Їхня наявність каже, що використовується шлях наскрізної передачі; відсутність указує на обмін обліковими даними.

На шлюзі Linux захоплення на порту RADIUS показує, які атрибути йдуть лінією:

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

Потім порівняйте точку відмови. Збій на шлюзі до будь-якого пакета RADIUS означає, що клієнт і шлюз не дійшли згоди щодо методу. Відмова RADIUS з атрибутами EAP означає, що кінці виконали метод і один із них відхилив результат.

Плануйте міграцію як одну зміну від початку до кінця

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

Запишіть робочу комбінацію: протокол VPN, носій EAP, метод партнера, метод сервера, тип облікових даних і перевірка ідентичності сервера.

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