Короткий ответ
- Судя по описанному поведению — Ubuntu подключается с задержкой, Windows не проходит при автозапуске, но после выключения/включения адаптера проходит — наиболее вероятно проблема со стартап/таймаутами 802.1X на клиенте (Windows), либо с порядком аутентификации (machine vs user), либо с таймаутами RADIUS/NAS. Точно сказать нельзя без логов: нужно проверить, доходит ли Access‑Request до RADIUS (MikroTik) при неудаче, и что отвечает RADIUS.
Возможные причины (и почему проявляются по-разному на Ubuntu/Windows)
1. Порядок старта и single sign-on / machine authentication
- Windows может пытаться аутентифицировать «пользователь» до того, как служба 802.1X/ключи/профиль готовы, или наоборот — система пытается выполнить машинную аутентификацию, а логин пользователя ещё не доступен. После ручного отключения/включения адаптера supplicant работает корректно.
2. Таймауты и повторные попытки (retry)
- Клиент и NAS/RADIUS имеют разные таймауты EAP/Access‑Request. Если RADIUS отвечает медленнее, Windows может «сходить с ума» быстрее, чем Ubuntu. Ubuntu может ждать и перепробовать дольше, поэтому подключается с 20 с задержкой.
3. Особенности supplicant в Windows
- Неправильные настройки адаптера: требование сертификата, выбранный EAP‑тип (PEAP/MSCHAPv2 vs TLS), использование «Validate server certificate» и т. д. После ре‑инициализации адаптера эти параметры проходят корректно.
4. Проблемы с сертификатами / EAP методами
- Неправильно установленный/доверенный серверный сертификат или несовместимость методов EAP приведут к отказу. Но тогда обычно отказ постоянный, а не «интермиттирующий».
5. Проблемы на стороне MikroTik / RADIUS
- RADIUS отвечает медленно, неверный shared secret, ограничения User‑Manager (ограничение одновременных сессий), или баг в реализации 802.1X на MikroTik. Если NAS не пересылает Access‑Request при попытке клиента — это проблема NAS/клиента; если Access‑Request есть, но RADIUS отклоняет — проблема на RADIUS/User‑Manager.
6. Сетевая инфраструктура / VLAN / авторизация порта
- Если после аутентификации нужно присвоить VLAN, а проброс/переход в VLAN занимает время, клиент может «таймаутиться».
7. UDP/RADIUS пакетная потеря и MTU/фрагментация
- RADIUS использует UDP: потеря или фрагментация может вызвать таймауты и разные реакции клиентов.
Что нужно проверить (пошагово)
1. Собрать логи и трафик
- На MikroTik: включить логирование RADIUS/аутентификации и/или захватить пакеты RADIUS (порт 1812/1813). Примеры команд (RouterOS):
- /system logging add topics=radius action=memory
- /log print where topics~"radius"
- /tool sniffer set filter-port=1812,1813 file-name=radius.pcap streaming-enabled=no; /tool sniffer start; (потом /tool sniffer stop и скачать файл /file get radius.pcap)
- Также смотреть /log print на сообщения об отказе авторизации (Access‑Reject и причина).
- На Windows:
- Откройте Event Viewer → Applications and Services Logs → Microsoft → Windows → Wired‑AutoConfig → Operational — там появляются события 802.1X.
- Можно запустить трассировку netsh: netsh trace start capture=yes tracefile=c:\temp\trace.etl, затем воспроизвести попытку подключения и netsh trace stop. ETL можно конвертировать в pcap или открыть в Microsoft Message Analyzer/Wireshark (через преобразование).
- Для анализа EAPOL удобно снять capture в Wireshark (фильтр «eapol»), смотреть EAPOL‑Exchange и то, отправляются ли Access‑Request с NAS на RADIUS.
2. Сравнить успешный и неуспешный сценарии
- При неудаче: появился ли Access‑Request на MikroTik и/или на RADIUS? Если нет — клиент/настройки 802.1X или NAS не пересылает; если есть, но RADIUS отвечает Reject — смотреть причину Reject в логах User‑Manager.
3. Проверить настройки Windows
- В свойствах проводного подключения → Authentication: включено ли «Authenticate as computer when computer information is available» / «Single sign on» (в зависимости от желаемого поведения)?
- Попробовать включить «Authenticate as computer» или наоборот — «User authentication» и проверить.
- Отключить требование проверки сертификата сервера временно, чтобы убедиться, что это не валидация сертификата.
4. Проверить таймауты/повторные попытки
- Логи покажут, успевает ли RADIUS ответить до таймаута клиента. Если RADIUS медлит, увеличьте таймауты/повторы на NAS или оптимизируйте работу RADIUS (производительность User‑Manager, база данных).
5. Проверить версии/драйвер NIC на Windows
- Обновите драйвер сетевого адаптера — некоторые драйверы плохо работают с 802.1X при возобновлении/буте.
Типичный вывод по вашему сценарию
- Поскольку после ручной переинициализации адаптера у Windows всё проходит, вероятность большая, что проблема на клиенте (поведение supplicant при старте/пробуждении) или связана с таймаутом/порядком аутентификации. Но подтверждение требует логов: если при неудаче на MikroTik не приходит Access‑Request — виноват клиент/NIC; если приходит и RADIUS отклоняет — виноват RADIUS/User‑Manager.
Что я рекомендую сейчас
1. Соберите логи MikroTik (захват RADIUS трафика и /log). Прикрепите сюда нужные строки/файл pcap.
2. На Windows включите Wired‑AutoConfig журнал (Event Viewer) и/или сделайте netsh trace при неудачном старте и при успешном (после переподключения) и пришлите эти файлы.
3. Пока собираете логи, попробуйте на одном проблемном Windows: в настройках адаптера во вкладке Authentication выставить «Authenticate as computer» (или наоборот), и/или включить «Enable single sign on for this network» — проверить поведение при перезагрузке.
Если пришлёте логи/pcap, разберу и скажу точно, где «теряется» аутентификация и какие настройки поменять.