Когда ты что-то выбираешь для себя — ты стараешься выбирать лучшее (желательно не очень дорогое, конечно, но что-нибудь хорошее). И стараешься выбирать это сам. Верить на слово никому нельзя — только личный опыт, проверка и тестирование. И, поистине, ты иногда можешь получить удивительные результаты, казалось бы, от совсем обыденных вещей. Удивительные как в плохую, так и в хорошую сторону.
В данной статье описана часть сравнительного тестирования двух точек доступа, которые подбирались под определенные кейсы. Всем кому интересно — велком под кат.
Модели точек: 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 смотрится гараздо привлекательнее в плане использования под те задачи, которые нам потребовались. При сравнительно одинаковым функицонале выбор будет всегда за стабильностью на длительном отрезке времени и, конечно же, производительностью.
К сожалению, невозможно абослютно всё охватить лабораторными тестами, сэмулировать все возможные ситуации которые могу произойти в продакшене и всё предусмотреть. Поэтому далее обе точки, обязательно, ждут полевые тестирования в максимально приближенных к боевым условиям сетях.
Автор: SuLX
