Тестирование точек доступа Zyxel vs Ubiquiti

Когда ты что-то выбираешь для себя — ты стараешься выбирать лучшее (желательно не очень дорогое, конечно, но что-нибудь хорошее). И стараешься выбирать это сам. Верить на слово никому нельзя — только личный опыт, проверка и тестирование. И, поистине, ты иногда можешь получить удивительные результаты, казалось бы, от совсем обыденных вещей. Удивительные как в плохую, так и в хорошую сторону.

В данной статье описана часть сравнительного тестирования двух точек доступа, которые подбирались под определенные кейсы. Всем кому интересно — велком под кат.

Модели точек: Zyxel NWA1123-AC PRO ^[1] и Ubiquiti UniFi AP AC PRO ^[2]
Обе точки из одного ценового диапазона и созданы для решение одних и тех же задач.

По вспомогательному оборудованию, которое использовалось при тестах:
Сервер iperf — обычный стационарный компьютер с гигабитной сетевой картой. Ничего особенного.
Клиент wi-fi — второй ноутбук hp probook 430 g4. С wi-fi модулем умеющим в 5Ггц.
Роутер — c9 arcer.

Топология тестового стенда максимально простая:

Функциональное тестирование

Всё, что попадает к нам в руки, мы прогоняем по стандартному протоколу. У нас есть определенные наработки на которые мы опираемся. Некоторые пункты меняются от одного ТЗ к другому, но основной функционал практически остается неизменным независимо от задачи. Есть критичные пункты, отсутствие которых сразу же ставит крест на использование таких устройств на сети (например, если нет ssh или snmp), а есть опциональные пункты, наличие которых будет в плюс устройству при подведении итогов тестирования. Например, наличие консольного порта. Есть — хорошо, нет — ну, не очень то и хотелось.

Некоторые пункт будут банальны, но, к сожалению, их реально приходится проверять. Не раз и не два встречались устройства у которых в спецификации заявлена поддержка того или иного функционала и данные галочки настроек даже присутствуют в вебке, но не работают.
Например, приоритезация трафика. Включаешь в настройках нужную галочку, начинаешь собирать пакеты анализатором трафика, а в них, собственно, ничего не поменялось в заголовках. Печально.

В данном случае обе точки отлично справились. Каких-то нареканий нет и весь основой функционал, который требовался — реализован. Даже как-то скучно. Это не low-сегмент ковырять, где можно увидеть «segmentation fault» от nslookup'a (да, есть кое-где и такое).

После проверки основного функционала не плохо было бы найти что-нибудь интересное. Проверить нужно не только наличие определенного функционала, но и отсутствие «лишнего».

Пробегаемся nmap'ом по обеим точкам:

Ubiquiti

Zyxel

Тут на скрин не попал еще 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 комьюнити которое в настройках предлагается сразу сменить, при запуске.

Нагрузочное тестирование

Для начала посмотрим сети вокруг. Смотреть будем только на 5 GHz диапазон. Для сканирования я использовал Acrylic, Сами точки включались по одной, дабы не мешали друг другу. Плюс, для чистоты эксперимента, выключал еще адаптер роутера.

В итоге, позже, пришлось провести еще тесты, но уже в другом, более спокойном месте, т.к. в первом случае вокруг была развернута чья-то корпоративная сеть из просто огромного количества точек, на очень широком спектре каналов (на скринах ниже видно, многие не влезли).

Трафик гонялся iperf'ом, в 5 потоков. Сначала тестировал по 60 минут, но потом понял, что это не совсем информативно и оставлял нагрузку на 4 часа.

Что из этого получилось ниже в спойлерах:

Ubiquiti

Максимальное значение: 300 Мбит/сек (упирается в этот потолок и больше не выдает)
Минимальное значение: 228 Мбит/сек
Среднее значение: 296,5 Мбит/сек
С — стабильность. Хороший ровный коннект в течение всего времени. Есть кратковременные просадки, но они на значительные.

Статистка за время работы:
(CPU желтым, синим — память + трафик)

Zyxel

Максимальное значение: 584 Мбит/сек
Минимальное значение: 324 Мбит/сек
Среднее значение: 426 Мбит/сек

А вот загрузка CPU немного удивила:

В момент начала теста загрузка подскочила до 91%. Особых проблем при использовании точки я не заметил в этот момент: точка не нагревалась, вебка не лагала, потерь пакетов не было.
Тест был на максимальную возможную производительность и, несмотря на то, что это не совсем стандартная ситуация, когда в течение большого промежутка времени прогоняется огромное количество трафика, такой кейс у нас есть. (Доступ к серверам с большим количеством данных для «мобильных» клиентов) считаю, что тест успешно пройден. В любом случае, вопрос был задан поддержке Zyxel и ведем сейчас переговоры по данной ситуации.

Статистика по CPU/Памяти:

Итоги

Подведя промежуточный итоге могу сказать, что точка Zyxel смотрится гараздо привлекательнее в плане использования под те задачи, которые нам потребовались. При сравнительно одинаковым функицонале выбор будет всегда за стабильностью на длительном отрезке времени и, конечно же, производительностью.

К сожалению, невозможно абослютно всё охватить лабораторными тестами, сэмулировать все возможные ситуации которые могу произойти в продакшене и всё предусмотреть. Поэтому далее обе точки, обязательно, ждут полевые тестирования в максимально приближенных к боевым условиям сетях.

Автор: SuLX

Источник ^[3]