В данной статье описана часть сравнительного тестирования двух точек доступа, которые подбирались под определенные кейсы. Всем кому интересно — велком под кат.
Модели точек: Zyxel NWA1123-AC PRO и Ubiquiti UniFi AP AC PRO
Обе точки из одного ценового диапазона и созданы для решение одних и тех же задач.
По вспомогательному оборудованию, которое использовалось при тестах:
Сервер iperf — обычный стационарный компьютер с гигабитной сетевой картой. Ничего особенного.
Клиент wi-fi — второй ноутбук hp probook 430 g4. С wi-fi модулем умеющим в 5Ггц.
Роутер — c9 arcer.
Топология тестового стенда максимально простая:
Функциональное тестирование
Всё, что попадает к нам в руки, мы прогоняем по стандартному протоколу. У нас есть определенные наработки на которые мы опираемся. Некоторые пункты меняются от одного ТЗ к другому, но основной функционал практически остается неизменным независимо от задачи. Есть критичные пункты, отсутствие которых сразу же ставит крест на использование таких устройств на сети (например, если нет ssh или snmp), а есть опциональные пункты, наличие которых будет в плюс устройству при подведении итогов тестирования. Например, наличие консольного порта. Есть — хорошо, нет — ну, не очень то и хотелось.
Это несомненно плюс. На Ubiquiti консольный порт там же, где и у большинства производителей (что абсолютно не удивительно — многие так делают, но тут даже ножек нету):
Можно отдельно устроить холивар на тему, что: «на нормальном устройстве доступ к консольному порту не должен понадобиться в принципе», но, я склоняюсь к мнению, что лучше он будет и не понадобится, чем, вдруг, он понадобится и его там нет (прям как со средствами контрацепции).
Некоторые пункт будут банальны, но, к сожалению, их реально приходится проверять. Не раз и не два встречались устройства у которых в спецификации заявлена поддержка того или иного функционала и данные галочки настроек даже присутствуют в вебке, но не работают.
Например, приоритезация трафика. Включаешь в настройках нужную галочку, начинаешь собирать пакеты анализатором трафика, а в них, собственно, ничего не поменялось в заголовках. Печально.
В данном случае обе точки отлично справились. Каких-то нареканий нет и весь основой функционал, который требовался — реализован. Даже как-то скучно. Это не low-сегмент ковырять, где можно увидеть «segmentation fault» от nslookup'a (да, есть кое-где и такое).
2. Поддержка 802.11i (безопасность, поддержка AES шифрования).
3. Поддержка 802.11q (возможность передачи тегированного трафика).
3. Поддержка влана управления.
4. Возможность изменять мощности сигнала радиопередатчика.
5. Поддержка QOS и 802.1p (возможность приоритезации трафика).
6. Возможность ограничить максимальное число клиентов, подключаемых к точке доступа.
7. Управление точкой посредством telnet/ssh/webGUI.
8.Поддержка мониторинга и управления точкой доступа по snmp.
9.Возможность работы точки в централизованном/автономном режиме.
10. Поддержка LLDP-discovery.
11. Наличие у точки внутреннего лога системных событий и возможность отправки логов на удаленный сервер.
12. Наличие на точке внутреннего анализатора трафика (опционально и не обязательно, но у обеих точках присутствует).
13.Наличие анализатора спектра и возможность обнаружения точкой доступа работающих рядом с ней иных точек.
После проверки основного функционала не плохо было бы найти что-нибудь интересное. Проверить нужно не только наличие определенного функционала, но и отсутствие «лишнего».
Пробегаемся nmap'ом по обеим точкам:
Тут на скрин не попал еще 21-й открытый порт для ftp.
На обоих точках открыт ssh, что хорошо. На Ubiquiti только ssh — ничего лишнего. Только хардкор. На Zyxel — ftp,ssh,http (стандартный набор) и что-то неизвестное на 40713/tcp.
Как потом оказалось — это централизованный сервис для управления точками доступа (не только ими, но и остальным имеющимся оборудованием) через облако Nebula. В целом, понравилось даже больше чем веб-ка самой точки. Несколько скринов, чтобы примерно понимать (масштаб на первом специально сильно уменьшен, чтобы всё влезло):
Логин и пароль по умолчанию для Zyxel нигде на самой точке не указан, поэтому просто воспользовались медузой (стандартная утилита для брута в Kali linux). Получили пару логин/пароль — 'admin/1234', а от Ubiquiti мы и так прекрасно знаем стандартные логопасы в виде 'ubnt/ubnt'.
Оказалось, что на данной точке Ubiquiti нет web-сервера. Совсем. Управление только через контроллер и специальную утилиту. Папка /www просто пуста и на 80/8080 порту ничего не крутится. Но тут хотя бы стандартный busybox (и достаточно свободный по командам), в отличие от Zyxel. Там шаг влево, шаг вправо — расстрел.
По обеим точкам прошлись сканером уязвимостей (Nessus). Он ничего сверхкритичного не показал. Ниже результаты и подробное описание того, что найдено.
192.168.0.196 — Zyxel
192.168.0.126 — Ubiquiti
Ubiquiti:
Одна и не критичная. Считайте -ничего не нашли.
Zyxel:
Тут по интереснее, если кратко: использование старых небезопасных версий SSL и стандартное public snmp комьюнити которое в настройках предлагается сразу сменить, при запуске.
- Удаленная служба принимает соединения, зашифрованные с использованием SSL 2.0 и / или SSL 3.0. На эти версии SSL влияют несколько криптографических ошибок
- Сертификату сервера X.509 нельзя доверять. Цепочка сертификатов X.509 для этой службы не подписывается признанным центром сертификации. Если удаленный хост является общедоступным хостом, это сводит на нет использование SSL, поскольку любой может установить атаку «человек в середине» против удаленного хоста.
- У удаленного хоста включена переадресация IP. Злоумышленник может использовать это для маршрутизации пакетов через хост и потенциально обходить некоторые брандмауэры / маршрутизаторы / NAC-фильтрацию.
- Дефолтное snmp community (public).
- Демон SNMP отвечает большим количеством данных на запрос «GETBULK» с более чем нормальным значением для «max-repetitions». Удаленный злоумышленник может использовать этот SNMP-сервер для проведения развернутой распределенной атаки отказа в обслуживании на произвольном удаленном хосте.
Нагрузочное тестирование
Для начала посмотрим сети вокруг. Смотреть будем только на 5 GHz диапазон. Для сканирования я использовал Acrylic, Сами точки включались по одной, дабы не мешали друг другу. Плюс, для чистоты эксперимента, выключал еще адаптер роутера.
В итоге, позже, пришлось провести еще тесты, но уже в другом, более спокойном месте, т.к. в первом случае вокруг была развернута чья-то корпоративная сеть из просто огромного количества точек, на очень широком спектре каналов (на скринах ниже видно, многие не влезли).
Трафик гонялся iperf'ом, в 5 потоков. Сначала тестировал по 60 минут, но потом понял, что это не совсем информативно и оставлял нагрузку на 4 часа.
Что из этого получилось ниже в спойлерах:
Ubiquiti
Максимальное значение: 300 Мбит/сек (упирается в этот потолок и больше не выдает)
Минимальное значение: 228 Мбит/сек
Среднее значение: 296,5 Мбит/сек
С — стабильность. Хороший ровный коннект в течение всего времени. Есть кратковременные просадки, но они незначительные.
Статистка за время работы:
(CPU желтым, синим — память + трафик)
Zyxel
Максимальное значение: 584 Мбит/сек
Минимальное значение: 324 Мбит/сек
Среднее значение: 426 Мбит/сек
А вот загрузка CPU немного удивила:
В момент начала теста загрузка подскочила до 91%. Особых проблем при использовании точки я не заметил в этот момент: точка не нагревалась, вебка не лагала, потерь пакетов не было.
Тест был на максимальную возможную производительность и, несмотря на то, что это не совсем стандартная ситуация, когда в течение большого промежутка времени прогоняется огромное количество трафика, такой кейс у нас есть. (Доступ к серверам с большим количеством данных для «мобильных» клиентов) считаю, что тест успешно пройден. В любом случае, вопрос был задан поддержке Zyxel и ведем сейчас переговоры по данной ситуации.
Статистика по CPU/Памяти:
Итоги
Подведя промежуточный итоге могу сказать, что точка Zyxel смотрится гараздо привлекательнее в плане использования под те задачи, которые нам потребовались. При сравнительно одинаковым функицонале выбор будет всегда за стабильностью на длительном отрезке времени и, конечно же, производительностью.
К сожалению, невозможно абослютно всё охватить лабораторными тестами, сэмулировать все возможные ситуации которые могу произойти в продакшене и всё предусмотреть. Поэтому далее обе точки, обязательно, ждут полевые тестирования в максимально приближенных к боевым условиям сетях.
Комментарии (13)
port443
28.11.2018 03:47Стабильность под высокой загрузкой процессора — признак хороших софтовых инженеров. Минус только один: завтра придёт новое расширение WiFi, более безопасное, но более ресурсозатратное, и эта точка или не потянет совсем, или сильно просядет по скорости.
sevmax
28.11.2018 08:55К преимуществам Ubuquity следует отнести бесшовный роуминг между точками распределёнными на большой площади.
А специализированный контроллер прекрасно справляется с задачей управления этим кластерном.DaemonGloom
28.11.2018 12:24Увы, с бесшовным роумингом у них всё плохо стало. Даже пришлось откатить контроллер, бд и софт на точках, чтобы он снова заработал. В теме последнего релиза говорят — не используйте роуминг. И не обещают починить.
sevmax
28.11.2018 19:11Интересно, однако! Когда-то это была их киллер-фича, ради которой я мигрировал несколько окружений на эти точки. Надеюсь, что они починят роуминг в скором времени!
SLYzhuk
28.11.2018 12:42ZyXel тоже давно имеет бесшовный роуминг.
Одна из точек доступа может стать контроллером кластера
WirelessMAN
28.11.2018 13:54«Бесшовный роуминг» в wi-fi — ультрарастяжимое понятие, которое из-за недопонимания превращается в полный цирк :) Вы будете смеяться, но если взять разномастные точки любых производителей (главное, чтобы они были wi-fi), создать на всех одинаковый SSID и назначить одинаковые PSK, то клиентские устройства будут переключаться в пределах широковещательного домена без всякого разрыва tcp-сессий (особенно если расставить их на одном канале!). Бесшовный ли это роуминг? Sorta-kinda, при желании можно натянуть сову на глобус, в смысле, определение на тестовый стенд. Чудеса начинаются при работе с 802.1x, кешированием ключей и переходом между точками на разных каналах.
Есть куда более важные для работы в мало-мальски нагруженных сетях функции. Например, очень важно уметь Airtime Fairness — регулировать доступность среды по-разному для клиентов с разными MCS. То есть, не разрешать медленным клиентам принимать данные долго, ограничивая их по времени, за счёт чего суммарная пропускная способность точки доступа с этой функцией ощутимо возрастает. Хорошо бы уметь Band steering, то есть, пробовать «выдавливать» клиентов, которые могут работать в 5 ГГц, туда, по возможности мешая им подключаться к тесной, шумной и вечно занятой «двойке». Совсем здорово уметь просто отсекать клиентов с недостаточным качеством сигнала от сети — да, они могут получить отказ в обслуживании, и драйвер «обидится» на такую сеть, но иногда лучше пожертвовать одним, существенно улучшив показатели всех остальных (если, конечно, это не устройство IT-директора).
Дьявол общего доступа к среде кроется в деталях. «Тупая» пропускная способность в сценарии «один клиент 3х3:3, одна точка 3х3:3, айперф» не очень интересна — сети сейчас нагружены, мобильные клиенты никогда не смогут в такие пропускные способности, CSMA/CA гадит, точки и клиенты друг другу мешают, и так далее. То, что быстро работает на одном клиенте, может прилечь отдохнуть уже при десятке — и при этом процессор ничем занят не будет, данные-то не идут :)nuearth
29.11.2018 17:33Все-таки Enterprise и SOHO сегменты весьма отличаются подходом. Проблемы возникают тогда, когда «знатоки» начинают настаивать на 80 МГц канале и хотят 300 Мбит/c от Wi-Fi, ставя свой Зюксель в офисе, соседствующем с большой сетью на Cisco, в которой инженер посчитал, что даже каналы в 40 это непозволительная роскошь… Когда этот инженер приходит объяснить что-к-чему, слушать его никто не хочет (эт я не про себя рассказываю, коллеги делятся, так сказать). Ну как тут не нажать кнопку «Contain»… А «бесшовный роуминг», это боль каждого второго сочиненного «знатоками» ТЗ.
Коллега, спасибо за душевный комментарий, приятно читать.dmitry_dvm
30.11.2018 09:47Если под "знатоком" вы намекаете на меня, то у меня просто припекло, что автор не разобравшись с настройками поставил диагноз хорошему производителю. Вообще удивило, что Ubiquiti сравнивается с зухелем. Кстати, вышеуказанные Airtime Fairness и Band steering Ubiquiti умеет даже на бюджетных Lite. Но автор и об этом умолчал, хотя претендует на экспертизу.
nuearth
30.11.2018 19:17На вас не намекал. Просто жизненный опыт такой, что 80МГц каналы не люблю, на предприятиях. Хотя в домашней сети, где спектр 5ГГц почти чист, я сам использую ширину канала 40, ибо регулярные бэкапы рабочих папок с ноута на NAS именно по Wi-Fi идут.
По поводу же Zyxel и Ubiquity, оба вендора по-своему хороши, но в определенной нише. Мне действительно интересно было бы взглянуть на данные с сети где штук 30 точек, у меня такого опыта пока нет.
RTFM77
28.11.2018 12:41ИМХО, проще пробовать в реальности, по теоретическим тестам все равно фигня будет.
AcidVenom
28.11.2018 14:48Почему именно эти 2 ТД рассматривали?
Сами-то какого вендора сетевого выбираете?
dmitry_dvm
Ubiquiti низкую скорость показала скорее всего потому что указан регион Россия и канал по ширине зарезан. Поменяйте регион и поставьте ширину 80 и начнется жизнь. Моя ac lite более 500мбит выдает легко (60+МБ/с при копировании с компа на ноут).