Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Неустойчивость 802.1x, UniFi Network
 
У меня постоянно возникают проблемы с нестабильностью Wi-Fi 802.1x: клиенты просто перестают передавать трафик на некоторое время, а потом могут заново подключиться. Мне удалось зафиксировать трафик точки доступа в момент, когда мой компьютер не мог подключиться к Wi-Fi (в приложенном pcap-файле). Похоже, что точка доступа запрашивает идентификацию, но не получает ответа от клиента. Есть идеи, что тут происходит? Вот команда, которую я использовал для захвата трафика: "c:\Program Files\PuTTY\plink.exe" -ssh admin@wap-pa23 -pw "xxxxxxxxxxxxxxx" "tcpdump -i ath0 src not 10.40.0.241 and dst not 10.40.0.241 -w -" | "C:\Program Files\Wireshark\Wireshark.exe" -k -i - Это UAP-AC-HD с версией 4.0.21.9965.
 
Благодарю за ответы. Я создам новую тему.
 
^^^Действительно
 
@hoffhouse тебе будет гораздо удобнее создать новую тему и указать как можно больше подробностей о твоей настройке, конфигурации и возникших проблемах. За последние 4 года прошивка и софт сильно изменились. К тому же ты сможешь приватно прикреплять файлы, чтобы помочь членам команды Unifi помочь тебе.
 
Привет, @RobbieH! Все мои точки доступа относятся к следующей модели и версии устройства: Модель — UAP-AC-Pro Версия устройства — 6.5.62.14788
 
@hoffhouse У тебя установлена прошивка версии 4.0.21?
 
Возрождаю эту старую тему, чтобы узнать, удалось ли тебе что-то решить, @kaden. Моя среда очень похожа на твою: 802.1x с динамическими VLAN, Network Policy Server. У меня периодически возникают проблемы со стабильностью клиентов, и я сейчас это выясняю. Любая информация с твоей стороны будет очень полезна.
 
Похоже, я застрял на месте с техподдержкой. Они зациклились, задавая одни и те же вопросы снова и снова. Есть ли кто-то из поддержки, кто готов помочь мне с проблемой Dynamic VLAN? Очевидно, что что-то тут не работает.
 
Я сделал еще одно открытие. Когда я отключаю DVLAN, точка доступа становится стабильной. Если у меня две SSID на одной точке доступа и я отключаю DVLAN на SSID1, но оставляю включенным DVLAN на SSID2, тогда SSID2 перестает работать, а SSID1 продолжает работать. Проблема касается только тех SSID, которые используют динамические VLAN (как для 802.1x, так и для RADIUS MAC-аутентификации)!
 
Да, вы правы, ещё одни PCAP с синхронизированным NTP не решат проблему. Симптомы указывают на неполадки с точкой доступа. Если у вас уже есть тикет в поддержку со всеми доказательствами, то я больше не смогу помочь по этому вопросу. Сообщите, пожалуйста, чем всё закончилось!
 
Спасибо, Майки, это вообще выше моего понимания! Могу проверить синхронизацию NTP и сделать повторный захват, если нужно, но мне кажется, что проблема связана с точкой доступа или прошивкой, так что это вряд ли даст лучший результат. Мой лучший предположительный вариант — клиент отправляет пакеты идентификации, но в это время аутентификация на точке доступа занята, и пакет теряется, пока ресурсы не освободятся. У меня есть заявка в техподдержку, которая, надеюсь, разберётся с этим.
 
Привет, NTP не был синхронизирован на всех устройствах, где ты снимал трафик, в PCAP-файлах разное время. Я не смог найти ничего полезного в PCAPах с клиента, коммутатора и в мониторах. Там нет EAP или RADIUS-пакетов, соответствующих времени инцидента. Ниже фрагмент из лога AP и его PCAP:  

Request, Identity от AP к клиенту зацикливаются какое-то время. В то же время AP показывал, что клиент пытался подключиться (EVENT_STA_JOIN ath0: 9c:b6:d0:ff:5d:ed) и сразу же уходил (EVENT_STA_LEAVE ath0: 9c:b6:d0:ff:5d:ed). Уходил, возможно, из-за незавершённой EAP-аутентификации. Странно, но в PCAP из мониторного режима не видно повторных Request, Identity — только полный успешный EAP-аутентификационный процесс:  

Я не уверен, насколько эта информация будет тебе полезна, но это то, что у нас есть.
 
Вот более подробные данные (внимание, большие размеры файлов).

Детали инцидента:  
Время: около 13:49 05.04.2019  
Устройство: 9c:b6:d0:ff:5d:ed  
Пользователь: k.napper  
Прочее: трафик перестал поступать на затронутое устройство (и другие) примерно в 13:49  
Настройка RADIUS — прокси с двумя серверами аутентификации

Примечания:  
https://assets.sheldoncollege.com/unifi/802.1x%20Instability/Notes.txt (<1Mb)

Захваты пакетов:  
https://assets.sheldoncollege.com/unifi/802.1x%20Instability/affected-computer.pcapng (55Mb)  
https://assets.sheldoncollege.com/unifi/802.1x%20Instability/air-monitor.pcapng (588Mb)  
https://assets.sheldoncollege.com/unifi/802.1x%20Instability/ap-ath1.pcapng (104Mb)  
https://assets.sheldoncollege.com/unifi/802.1x%20Instability/switch-port.pcapng (263Mb)

Логи:  
https://assets.sheldoncollege.com/unifi/802.1x%20Instability/radius-logs.zip (22Mb)  
https://assets.sheldoncollege.com/unifi/802.1x%20Instability/syslog.log (<1Mb)
 
Спасибо за логи, но всегда полезно предоставить следующие данные: время, когда возникала проблема, и MAC-адрес клиента (нужен только один). Снимок в режиме мониторинга (PCAP) можно сделать с помощью MacBook или Linux: https://help.ubnt.com/hc/en-us/articles/221029967-UniFi-Troubleshooting-Connectivity-Issues#wireshark
 
Я приложил вывод syslog на момент события (он в режиме отладки), у меня нет /var/log/messages. Я не вижу такой же проблемы с PSK — решил проверить то же самое. Как сделать PCAP в режиме мониторинга?
 
Все клиенты одновременно пострадали? Логи AP за это время (cat /var/log/messages) есть? Вы видите такое же поведение при аутентификации через PSK? Удалось получить PCAP в режиме мониторинга?
 
Хорошо, готов снова это рассмотреть. Я сделал захват пакетов на клиенте, ath1 и на Wi-Fi порту коммутатора. Постоянно пингуя шлюз, ICMP-пакеты уходят с клиента, но до коммутатора не доходят. Захват пакетов с ath1 остановился. К сожалению, файлы захвата весят несколько гигабайт, так что загрузить их не могу. Что делать дальше?  
P.S. Пинги работали до того момента, когда произошёл сбой или зависание Wi-Fi, о котором я писал в первом посте, и в это время страдают все клиенты, подключённые к точке доступа.
Страницы: 1
Читают тему (гостей: 1)