Перейти к содержанию

Сторона RADIUS

Alatyr выпускает клиентский сертификат и ставит профиль 802.1X на устройство. Всё, что дальше — RADIUS-сервер, точка доступа, доверие к корню на них — продукт не настраивает и настраивать не должен.

Эта страница про ту половину: что проверить на сервере RADIUS, чтобы выданный сертификат действительно пускал в сеть. Порядок — сначала то, без чего не заработает вовсе, потом то, что ломается тихо.

1. Доверие к корню

RADIUS должен доверять корню, которым подписан клиентский сертификат — Vault PKI или внешний CA, смотря что настроено в Настройки → Удостоверяющие центры.

# FreeRADIUS, mods-enabled/eap → tls-config
ca_file = /etc/freeradius/3.0/certs/alatyr_ca.pem

Результат. Проверяется не чтением конфигурации, а прогоном: radtest или eapol_test должен дойти до Access-Accept, а не до Access-Reject.

Требование действует и в обратную сторону. Профиль 802.1X, который распространяет Alatyr, закрепляет сертификат УЦ как якорь доверия и запрещает пользователю принять недоверенный сертификат вручную — поэтому серверный сертификат самого RADIUS тоже должен вести к этому якорю.

2. Размер EAP-фрагмента и MTU

Серверный flight (ServerHello, цепочка, CertificateRequest, ServerHelloDone) на типовой установке весит порядка 2 КБ и уходит несколькими EAP-фрагментами. Если framed_mtu у клиента RADIUS — точки доступа или коммутатора — меньше фрагмента, куски не доедут. Симптом при этом выглядит как проблема сертификата.

# mods-enabled/eap → tls-config tls-common
fragment_size = 1024      # умолчание; уменьшать под MTU вашей сети

Правка не того вхождения не даёт ничего и никак себя не проявляет

Параметр действует только внутри блока tls-config. В файле eap строка fragment_size встречается несколько раз, в том числе внутри закомментированных блоков других методов. Если поправить не то вхождение, конфигурация останется валидной, служба перезапустится, а поведение не изменится.

Результат. Проверяйте так:

grep -n '^\s*fragment_size' /etc/freeradius/3.0/mods-enabled/eap
freeradius -XC          # Configuration appears to be OK

Чего этот параметр не чинит

При проверке наблюдался перемежающийся отказ Windows с recv TLS 1.2 Alert, fatal illegal_parameter после получения полной цепочки. Парный замер показал, что fragment_size к нему отношения не имеет:

настройка успешных попыток
fragment_size = 900 2 из 4
умолчание 2 из 4

Это записано затем, чтобы с тем же симптомом не потратить день на подбор размера фрагмента: цифра меняется, исход — нет.

3. Проверка отзыва

Alatyr отзывает сертификат у своего УЦ, но принудить сетевой сегмент к перепроверке не может. Чтобы отзыв действительно закрывал доступ к сети, RADIUS должен проверять отзыв — по CRL или OCSP.

Без этой проверки отозванный сертификат продолжит пускать в сеть, пока не истечёт сам. Срок машинного сертификата по умолчанию — три года.

4. Правила сопоставления по Subject

Если на стороне RADIUS или NPS настроены правила сопоставления по Subject, помните про настройку «Организация в сертификате» (поле O) на вкладке Настройки → Политика выдачи. Она действует на будущие выдачи: уже выданные сертификаты не меняются, а устройства, получившие сертификат после смены значения, поедут с другим Subject. Согласуйте такое изменение с администратором RADIUS.

5. Диагностика на стороне клиента

Проверять надо фактическую аутентификацию, а не наличие профиля на хосте. Готовый порядок — в «Настройке сети», шаг 5: где смотреть журнал на Windows, почему замер сбивается подавлением попыток и как довести прогон на Linux до фактического Access-Accept.

Что продукт не делает и не будет

  • Не настраивает RADIUS, точку доступа и доверие к корню на них.
  • Не подбирает fragment_size за оператора: значение зависит от размера вашей цепочки сертификатов и от MTU вашей сети.
  • Не удаляет профили, распространяемые извне (GPO/MDM). Если у сети выключен переключатель «Распространять профиль через агента», убирать внешний профиль придётся той же консолью, которая его поставила.

Что дальше