Потерпите, этот пост может получиться длинноватым — хочу подробно рассказать, что я пробовал и заметил! Мы — часть большого университета и предоставляем студентам Eduroam (федеративную мировую беспроводную сеть с использованием WPA2 Enterprise и серверов RADIUS каждого учебного заведения для аутентификации). Мы используем Unifi AP, но в других отделах университета применяются другие системы. Проблема не связана конкретно с Unifi — у других подразделений с другими поставщиками она тоже есть, однако у некоторых отделов проблемы нет, и единственное, что их отличает — это поставщик Wi-Fi.
С выходом iOS9 любые существующие устройства, обновлённые до неё, а также новые студенты не могут подключиться, если пытаются сделать это вручную — сертификат показывается как «не доверенный» (сертификат выдан TERENA, которого нет в списке доверенных корневых ЦС), после чего соединение просто обрывается. Можно «доверять» сертификату, но после этого устройство бесконечно подключается и отключается и так и не остаётся в сети.
Если пользователь удаляет сеть Eduroam и проходит через конфигурационный инструмент Eduroam (cat.eduroam.org), который скачивает конфигурационный файл, сеть работает без сбоев. Этот профиль устанавливает полный цепочку сертификатов до корневого ЦС, которому iOS9 доверяет. В остальном разницы не вижу. Устройства на других версиях iOS работают нормально, как при ручной настройке с принятием сертификата, так и через конфигурационный файл.
Первоначально я думал, что дело в том, что сертификат не доверенный, но дальнейшее расследование заставляет меня усомниться и считать это ложным следом. Сейчас у нас настроен freeradius-прокси, который принимает запросы от наших AP и передаёт их на центральный сервер RADIUS университета. Сертификаты выданы именно центральным сервером RADIUS, и у меня нет доступа для их пересоздания. Я также пробовал обойти прокси, чтобы AP напрямую общались с центральным сервером (через NAT-шлюз) — без изменений.
Теперь самое странное. Некоторые пользователи жаловались, что их устройство отлично работает в некоторых частях университета, но не в моём или других. При дальнейшем выяснении выяснилось, что единственное общее — в местах, где всё работает, стоят Aerohive AP. В отделах с Unifi, Ruckus ситуация одинаковая (по Cisco не уверен, поступают разные данные). В отделах с Aerohive есть и proxys RADIUS, и прямое подключение к центральным серверам. Я проверил — сертификаты, которые получают при ручном подключении в Aerohive-сетях, абсолютно такие же, как наши, с тех же серверов, и также показываются как «не доверенные» и требуют принятия. Разница в том, что там, где у нас проблема, у них всё работает. Один из коллег из отдела с Aerohive принес своё исправно работающее устройство к нам — и оно сразу же тоже начало бесконечно подключаться и отключаться.
Значит, дело точно не в сертификате. Я исключил влияние RADIUS-прокси, обойдя его. Известна проблема с TLS1.2 против 1.0 — серверы RADIUS работают на версии, не поддерживающей 1.2, поэтому iOS не могла уйти на бракованную реализацию TLS1.2, хотя требования к TLS1.2 в релизе iOS9 вообще убрали. Если бы проблема была повсеместной, я бы списал всё на изменение в Apple, но когда оно работает только на AP одного вендора, а на других — нет, значит, обходной путь явно есть.
Мне ещё рассказали, что их iOS9-устройство не может подключиться к старому домашнему роутеру с сетью только WPA (не WPA2) — та же история с бесконечным подключением/отключением. Я пробовал заставить SSID использовать только WPA2/AES вместо WPA и WPA2 по умолчанию — безрезультатно.
Каким образом AP вообще может влиять на процесс? И почему проблема только у iOS9? Недавно, говорят, Aerohive выпустили обновление прошивки, которое исправляет проблемы подключения iOS с logjam — правда, не знаю, установили ли все отделы Aerohive этот апдейт. Но непонятно, почему AP влияет на WPA2-аутентификацию — по идее, он просто передаёт запросы клиента на сервер RADIUS, который тот же для всех вендоров.
Итак… Есть мысли, как AP может влиять на процесс аутентификации? Может, есть какая-то настройка (AP или RADIUS-прокси), которую можно поменять, чтобы обойти проблему? Или стоит менять что-то в самом AP, как это, судя по всему, сделали в Aerohive?
Для информации: у меня контроллер версии 4.7.5 с прошивкой 3.2.12 на AP (в основном обычные Unifi, несколько Pro — жду появления новых AC). На тестовом сайте настроен отдельный AP с возможностью переключения на другой RADIUS-прокси, дающий тестовый SSID, чтобы я мог экспериментировать, не влияя на рабочую сеть.
С выходом iOS9 любые существующие устройства, обновлённые до неё, а также новые студенты не могут подключиться, если пытаются сделать это вручную — сертификат показывается как «не доверенный» (сертификат выдан TERENA, которого нет в списке доверенных корневых ЦС), после чего соединение просто обрывается. Можно «доверять» сертификату, но после этого устройство бесконечно подключается и отключается и так и не остаётся в сети.
Если пользователь удаляет сеть Eduroam и проходит через конфигурационный инструмент Eduroam (cat.eduroam.org), который скачивает конфигурационный файл, сеть работает без сбоев. Этот профиль устанавливает полный цепочку сертификатов до корневого ЦС, которому iOS9 доверяет. В остальном разницы не вижу. Устройства на других версиях iOS работают нормально, как при ручной настройке с принятием сертификата, так и через конфигурационный файл.
Первоначально я думал, что дело в том, что сертификат не доверенный, но дальнейшее расследование заставляет меня усомниться и считать это ложным следом. Сейчас у нас настроен freeradius-прокси, который принимает запросы от наших AP и передаёт их на центральный сервер RADIUS университета. Сертификаты выданы именно центральным сервером RADIUS, и у меня нет доступа для их пересоздания. Я также пробовал обойти прокси, чтобы AP напрямую общались с центральным сервером (через NAT-шлюз) — без изменений.
Теперь самое странное. Некоторые пользователи жаловались, что их устройство отлично работает в некоторых частях университета, но не в моём или других. При дальнейшем выяснении выяснилось, что единственное общее — в местах, где всё работает, стоят Aerohive AP. В отделах с Unifi, Ruckus ситуация одинаковая (по Cisco не уверен, поступают разные данные). В отделах с Aerohive есть и proxys RADIUS, и прямое подключение к центральным серверам. Я проверил — сертификаты, которые получают при ручном подключении в Aerohive-сетях, абсолютно такие же, как наши, с тех же серверов, и также показываются как «не доверенные» и требуют принятия. Разница в том, что там, где у нас проблема, у них всё работает. Один из коллег из отдела с Aerohive принес своё исправно работающее устройство к нам — и оно сразу же тоже начало бесконечно подключаться и отключаться.
Значит, дело точно не в сертификате. Я исключил влияние RADIUS-прокси, обойдя его. Известна проблема с TLS1.2 против 1.0 — серверы RADIUS работают на версии, не поддерживающей 1.2, поэтому iOS не могла уйти на бракованную реализацию TLS1.2, хотя требования к TLS1.2 в релизе iOS9 вообще убрали. Если бы проблема была повсеместной, я бы списал всё на изменение в Apple, но когда оно работает только на AP одного вендора, а на других — нет, значит, обходной путь явно есть.
Мне ещё рассказали, что их iOS9-устройство не может подключиться к старому домашнему роутеру с сетью только WPA (не WPA2) — та же история с бесконечным подключением/отключением. Я пробовал заставить SSID использовать только WPA2/AES вместо WPA и WPA2 по умолчанию — безрезультатно.
Каким образом AP вообще может влиять на процесс? И почему проблема только у iOS9? Недавно, говорят, Aerohive выпустили обновление прошивки, которое исправляет проблемы подключения iOS с logjam — правда, не знаю, установили ли все отделы Aerohive этот апдейт. Но непонятно, почему AP влияет на WPA2-аутентификацию — по идее, он просто передаёт запросы клиента на сервер RADIUS, который тот же для всех вендоров.
Итак… Есть мысли, как AP может влиять на процесс аутентификации? Может, есть какая-то настройка (AP или RADIUS-прокси), которую можно поменять, чтобы обойти проблему? Или стоит менять что-то в самом AP, как это, судя по всему, сделали в Aerohive?
Для информации: у меня контроллер версии 4.7.5 с прошивкой 3.2.12 на AP (в основном обычные Unifi, несколько Pro — жду появления новых AC). На тестовом сайте настроен отдельный AP с возможностью переключения на другой RADIUS-прокси, дающий тестовый SSID, чтобы я мог экспериментировать, не влияя на рабочую сеть.