Як вхід у 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–каталог: прострочений обліковий запис прив'язки, недоступний каталог або запит, скерований на неправильний бекенд. Якщо ім'я користувача має суфікс домену, сервер може маршрутизувати за ним, і той самий обліковий запис, надісланий як CORP\alice і [email protected], може опинитися в різних місцях. У Windows NPS журнал Security записує 6272 при дозволі та 6273 при відмові, що говорить, чи рішення взагалі прийшло від NPS.

Читайте збій на тому кроці, який його створив

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

Саме останній рядок відправляє людей не до тієї команди. Access-Accept означає, що облікові дані прийнято; це не означає, що шлюз розмістив користувача в потрібному пулі чи проштовхнув маршрути. Атрибути групи важливі лише тоді, коли політика шлюзу їх читає. Я бачив, як правильний вхід потрапляв у гостьовий пул, бо зіставлення груп на боці RADIUS було налаштоване для іншого атрибута, ніж той, який перевіряє шлюз.

Прослідкуйте один вхід від початку до кінця

Виберіть один тестовий обліковий запис і один шлюз, а потім спостерігайте за тією самою спробою в усіх чотирьох точках. Запустіть налагодження на боці RADIUS — freeradius -X друкує запит і кожен модуль, якого він торкається — стежте за журналом автентифікації шлюзу і запустіть tcpdump для обміну UDP. Підключіться один раз і прочитайте чотири траси по черзі.

Ви хочете побачити згоду: шлюз запитав про користувача, якого ви очікували, сервер RADIUS вибрав бекенд, який ви очікували, цей бекенд повернув рішення, а атрибути у відповіді відповідають політиці, яку застосовує шлюз. Перше місце, де траси розходяться, — це ваша лінія збою. Якщо відповідь не несе атрибута групи, проблема на боці RADIUS, а не в профілі VPN; якщо атрибут є, а шлюз його ігнорує, проблема в політиці шлюзу.

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

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