Meraki AP на FreeRADIUS застрял на Access-Request.

Вопрос или проблема

В настоящее время я сталкиваюсь с проблемами при попытке настроить лабораторию между ПК с Windows 11 (с активированными Credential Guard и TLS 1.3 по умолчанию) и сервером FreeRADIUS с использованием EAP-TLS.

  • В основном, это выглядит примерно так
    enter image description here
  1. Где ПК с Windows 11 настроен на использование EAP-TLS с его машинным сертификатом для аутентификации на моем лабораторном SSID. Машинный сертификат выдается через GPO (автоматическая регистрация сертификатов машины) с помощью внутренней 3-уровневой PKI от Windows.

  2. Где сервер FreeRADIUS (версия 3.2.7-1), основанный на Debian 12, настроен для разрешения использования 10.0.0.0/8 NACs с паролем.

client test {
    ipaddr = 10.0.0.0/8
    secret = testing123
}

Также я активировал текущую конфигурацию для EAP в mods-available/eap

eap {
        default_eap_type = tls
        timer_expire = 60
        ignore_unknown_eap_types = no
        cisco_accounting_username_bug = no
        max_sessions = ${max_requests}
}
        tls-config tls-common {
                #private_key_password = whatever
                private_key_file = ${certdir}/myfreeradius_server.key
                certificate_file = ${certdir}/myfreeradius_server.pem
                ca_file = ${cadir}/my_corp_root_ca.pem
                ca_path = ${cadir}
                tls_min_version = "1.2"
                tls_max_version = "1.3"
}
  1. На данный момент, если я попробую эту конфигурацию с другого сервера Debian с eapol cli
    eapol_test -c wpa_supplicant-tls.conf -a 10.230.102.108 -s testing123
    где wpa_supplicant-tls.conf содержит :
ap_scan=0

network={
    eap=TLS
    eapol_flags=0
    key_mgmt=IEEE8021X
    identity="[email protected]"
    client_cert="my_user_cert.pem"
    private_key="my_user_privkey.key"
    # CA certificate to validate the RADIUS server's identity
    ca_cert="my_corp_root_ca.pem"
    phase1="tls_disable_tlsv1_3=0"
}

=> Работает хорошо, клиент показывает статус УСПЕХ и сервер RADIUS обрабатывает запрос.

Проблема в том,
Когда я пытаюсь подключиться к тестовому SSID, wifi соединение с ПК на Windows 11 загружается, загружается и никогда не заканчивается.
Meraki AP сообщает :
Клиент сделал запрос на аутентификацию 802.1X к серверу RADIUS, но он не ответил. auth_mode="wpa2-802.1x" vlan_id='32' radius_proto='ipv4' radius_ip='10.230.102.108' reason='radius_timeout' reassoc="1" radio='0' vap='10' channel="1" rssi='40'

FreeRadius получает такие логи:

Режим ожидания 4.7 секунды.
(5) Получено Access-Request Id 5 от 10.6.4.165:50147 до 10.230.102.108:1812 длиной 413
(5)   User-Name = "host/my_PC.my-domain.net"
(5)   NAS-IP-Address = 10.6.4.165
(5)   NAS-Identifier = "E0-CB-BC-8B-65-ED:vap10"
(5)   NAS-Port-Type = Wireless-802.11
(5)   Service-Type = Framed-User
(5)   NAS-Port = 1
(5)   Calling-Station-Id = "F4-D1-08-87-72-56"
(5)   Connect-Info = "CONNECT 54.00 Mbps / 802.11n / RSSI: 38 / Channel: 1"
(5)   Acct-Session-Id = "479273B6606E05AE"
(5)   Acct-Multi-Session-Id = "BA3341F3610DFCF9"
(5)   WLAN-Pairwise-Cipher = 1027076
(5)   WLAN-Group-Cipher = 1027076
(5)   WLAN-AKM-Suite = 1027073
(5)   Meraki-Network-Name = "APW-Wifi- - wireless"
(5)   Meraki-Ap-Name = "MyWifiAP"
(5)   Meraki-Ap-Tags = "  recently-added "
(5)   Called-Station-Id = "E0-CB-BC-8B-65-ED:00-Test-W11"
(5)   Meraki-Device-Name = "MyWifiAP"
(5)   Framed-MTU = 1400
(5)   EAP-Message = 0x021b00060d00
(5)   State = 0x943a85b2902188fe8217870d8617c1ba
(5)   Message-Authenticator = 0x63c15f58f21aa1566869606e3b3b7609
(5) Восстановление &session-state
(5)   &session-state:Framed-MTU = 994
(5)   &session-state:TLS-Session-Information = "(TLS) TLS - recv TLS 1.3 Handshake, ClientHello"     
(5)   &session-state:TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, ServerHello"     
(5)   &session-state:TLS-Session-Information = "(TLS) TLS - send TLS 1.3 ChangeCipherSpec"
(5)   &session-state:TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, EncryptedExtensions"
(5)   &session-state:TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, CertificateRequest"
(5)   &session-state:TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, Certificate"     
(5)   &session-state:TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, CertificateVerify"
(5)   &session-state:TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, Finished"        
(5) # Выполнение раздела authorize из файла /etc/freeradius/sites-enabled/default
(5)   authorize {
(5)     policy filter_username {
(5)       if (&User-Name) {
(5)       if (&User-Name)  -> TRUE
(5)       if (&User-Name)  {
(5)         if (&User-Name =~ / /) {
(5)         if (&User-Name =~ / /)  -> FALSE
(5)         if (&User-Name =~ /@[^@]*@/ ) {
(5)         if (&User-Name =~ /@[^@]*@/ )  -> FALSE
(5)         if (&User-Name =~ /\.\./ ) {
(5)         if (&User-Name =~ /\.\./ )  -> FALSE
(5)         if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/))  {
(5)         if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/))   -> FALSE
(5)         if (&User-Name =~ /\.$/)  {
(5)         if (&User-Name =~ /\.$/)   -> FALSE
(5)         if (&User-Name =~ /@\./)  {
(5)         if (&User-Name =~ /@\./)   -> FALSE
(5)       } # if (&User-Name)  = notfound
(5)     } # policy filter_username = notfound
(5)     [preprocess] = ok
(5)     [chap] = noop
(5)     [mschap] = noop
(5)     [digest] = noop
(5) suffix: Проверка для суффикса после "@"
(5) suffix: Нет '@' в User-Name = "host/my_PC.my-domain.net", поиск области NULL
(5) suffix: Такой области "NULL" не существует
(5)     [suffix] = noop
(5) eap: Сопоставление EAP Response (код 2) ID 27, длина 6
(5) eap: Нет EAP Start, предполагается продолжающийся EAP разговор
(5)     [eap] = обновлено
(5)     [files] = noop
(5)     [expiration] = noop
(5)     [logintime] = noop
(5)     [pap] = noop
(5)   } # authorизовать = обновлено
(5) Найден Auth-Type = eap
(5) # Выполнение группы из файла /etc/freeradius/sites-enabled/default
(5)   authenticate {
(5) eap: Удаление EAP сеанса с состоянием 0x943a85b2902188fe
(5) eap: Найден предыдущий запрос EAP для состояния 0x943a85b2902188fe, удален из списка
(5) eap: Пакет с методом EAP TLS (13) получен от клиента
(5) eap: Вызов подмодуля eap_tls для обработки данных
(5) eap_tls: (TLS) Клиент подтвердил наш фрагмент рукопожатия
(5) eap: Отправка EAP Request (код 1) ID 28 длиной 857
(5) eap: EAP сеанс добавляется в &ответ:State = 0x943a85b2912688fe
(5)     [eap] = обработано
(5)   } # authenticate = обработано
(5) Использование Post-Auth-Type Challenge
(5) # Выполнение группы из файла /etc/freeradius/sites-enabled/default
(5)   Challenge { ... } # пустой подраздел игнорируется
(5) session-state: Сохранение кешированных атрибутов
(5)   Framed-MTU = 994
(5)   TLS-Session-Information = "(TLS) TLS - recv TLS 1.3 Handshake, ClientHello"
(5)   TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, ServerHello"
(5)   TLS-Session-Information = "(TLS) TLS - send TLS 1.3 ChangeCipherSpec"
(5)   TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, EncryptedExtensions"
(5)   TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, CertificateRequest"
(5)   TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, Certificate"
(5)   TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, CertificateVerify"
(5)   TLS-Session-Information = "(TLS) TLS - send TLS 1.3 Handshake, Finished"
(5) Отправлено Access-Challenge Id 5 от 10.230.102.108:1812 до 10.6.4.165:50147 длиной 921
(5)   EAP-Message = 0x011c03590d80000012c7f6cbc153327171b2bc76c1934410b97b378c7eae3013184e9818477a0023577d5b678d502568f0b09628dbd76f62fecf4371422aaa1538c9da69ac89b654746eac2c9f6ed32ad40d84ee1574974b0ef24eb77fb357fc4033f32c14c4a0ba5ff1703b1bb950bcfb58cb5999a9b58ad84acea5472e349b4d7da305c7f1340da2c48c075b78837cd46a00e0c775fd4367b4c5074bed51e00ad9de13b607b679da5c5319129ce28ef91a2ac3c2ffaca88ddea2b8c6e969d1e804db5257c7a801ac6402f6480f4e554e4dc00cd52b08341bd3e9bfa69d0c74fc24e20daeb8a8fed4f2084fe4786915c317030302196928863add7ee4ea6274589fd4f86b88e9a0a3c6361300c86330893c81ac7176a8c00d601e988ff7782ef6a94021e7da2105a2168eb1939064bbe10bbf90c5dfe7e8ca4e99905b38ea8befb911fc3ea7f86b3dfb12ad311e11334edfa51564d697962deb990430f8b9c16580074080727774b679663bb376b839bd8b99ab529406
(5)   Message-Authenticator = 0x00000000000000000000000000000000
(5)   State = 0x943a85b2912688fe8217870d8617c1ba
(5) Запрос завершен
Режим ожидания 4.7 секунды.
(0) Очистка пакета запроса ID 0 с временной меткой +69 из-за достижения cleanup_delay
(1) Очистка пакета запроса ID 1 с временной меткой +69 из-за достижения cleanup_delay
(2) Очистка пакета запроса ID 2 с временной меткой +69 из-за достижения cleanup_delay
(3) Очистка пакета запроса ID 3 с временной меткой +69 из-за достижения cleanup_delay
(4) Очистка пакета запроса ID 4 с временной меткой +69 из-за достижения cleanup_delay
(5) Очистка пакета запроса ID 5 с временной меткой +69 из-за достижения cleanup_delay
Готово к обработке запросов


С точки зрения потоков Wireshark, кажется, что Meraki AP отправляет Access-Request на FreeRadius, который так и не отвечает.
enter image description here

Мои вопросы:

  1. Согласны ли мы, что такая конфигурация на FreeRADIUS должна проверять машину (или в конечном итоге пользовательский) сертификат благодаря настроенному корневому CA? и так, каждая машина или пользователь, имеющий сертификат, выданный PKI, должен быть авторизован для доступа к сети?

  2. Как я могу исследовать больше, чтобы знать, является ли это неправильной конфигурацией freeRADIUS?

В данный момент я немного застрял..

Ответ или решение

Конфигурация сети для аутентификации устройств на основе сертификатов является одной из ключевых частей в обеспечении безопасности ИТ-инфраструктуры. В вашем случае, настройка сети основана на EAP-TLS (расширенная аутентификация с использованием TLS), которая требует эффективной интеграции нескольких компонентов: клиента на Windows 11, точки доступа Meraki и сервера FreeRADIUS.

Теория

  1. EAP-TLS и FreeRADIUS: Основное назначение EAP-TLS — обеспечение безопасной аутентификации, используя сертификаты. В вашем случае, для успешной аутентификации требуется подтверждение подлинности машины или пользователя. Связь между клиентом и сервером безопасности выполняется через точку доступа Meraki, которая передает запросы к серверу FreeRADIUS. Сервер, в свою очередь, проверяет предоставленные клиентом сертификаты, используя корневой сертификат, настроенный в его конфигурации.

  2. Ошибка "Access-Request" в FreeRADIUS: Сообщение "stuck on Access-Request" указывает на проблему в доставке или обработке запросов между точкой доступа Meraki и сервером FreeRADIUS. Возможно, сервер не отвечает из-за неправильной конфигурации, либо запросы не доходят до сервера по сети.

Пример

Из ваших логов видно, что FreeRADIUS получил Access-Request от точки доступа Meraki, но не смог корректно обработать запрос и отправить ответ. Это говорит о проблеме с конфигурацией на стороне FreeRADIUS или возможных сетевых задержках/потерях пакетов. Стоит отметить, что eapol_test на Debian работает корректно, что подтверждает исправность базовой конфигурации FreeRADIUS.

Применение

  1. Проверка сетевой связи: Убедитесь, что на сетевом уровне нет проблем с маршрутизацией или блокировками между Meraki и FreeRADIUS. Это можно проверить с помощью утилит ping или traceroute от точки доступа к серверу FreeRADIUS. Возможно, потребуется проверить настройки межсетевого экрана, роутеров или прокси в сети.

  2. Анализ конфигурации FreeRADIUS: Перепроверьте настройки в файле mods-available/eap. Особое внимание уделите:

    • Конфигурации tls-config, а именно соответствию путей к файлам сертификатов и их доступности (права на чтение должны быть настроены корректно).
    • Параметру tls_min_version, который может ограничивать поддержку только одной версии TLS.
    • Актуальности и корректности CA-файлов.
  3. Логи и отладка FreeRADIUS: Запустите FreeRADIUS с уровнем отладки (radiusd -X) для детального анализа и захвата событий. Логи помогут идентифицировать, на каком этапе происходит сбой. Особое внимание следует уделить утверждениям, связанным с обработкой EAP-трафика.

  4. Проверка доверия сертификатов: Убедитесь, что сертификаты, используемые каждым устройством, полностью доверены корневым CA-набором, используемым сервером. Это особенно важно в случае использования клиентских сертификатов от разных уровнями (например, от разных tiers PKI).

  5. Обновление компонентов: Проверьте, использует ли FreeRADIUS последнюю версию. Иногда обновления могут исправлять известные проблемы безопасности и совместимости.

  6. Настройка точки доступа Meraki: Убедитесь, что производится актуальная конфигурация точки доступа Meraki, включая настройки RADIUS. Возможны изменения в версиях прошивки, которые могут исправить проблемы с задержками запросов.

Заключение

Проблема, связанная с "stuck on Access-Request", требует комплексного анализа сети, конфигурации и сертификатов. Постепенное устранение причин и внимательное изучение отладочных логов FreeRADIUS может значительно помочь в нахождении и устранении проблемы. Также полезно ознакомиться с форумами или сообществами по Meraki и FreeRADIUS, на которых можно найти обсуждения схожих вопросов и возможных решений.

И, безусловно, при любых изменениях в конфигурации, прежде чем применять их в продуктивной среде, проведите тестирование в тестовой среде для минимизации рисков простаивания сетевых услуг.

Оцените материал
Добавить комментарий

Капча загружается...