Когда вы выбираете что-то для себя, вы стараетесь выбрать самое лучшее (желательно, конечно, не очень дорогое, но что-то хорошее).
А вы попробуйте выбрать его сами.
Верить на слово нельзя – только личный опыт, проверка и тестирование.
И действительно, иногда из, казалось бы, обычных вещей можно получить потрясающие результаты.
Удивительно как в хорошем, так и в плохом смысле.
В данной статье описана часть сравнительного тестирования двух точек доступа, выбранных для конкретных случаев.
Кому интересно - добро пожаловать под кат. Точечные модели: Zyxel NWA1123-AC ПРО И Ubiquiti UniFi AP AC PRO Обе очки из одного ценового диапазона и созданы для решения одних и тех же задач.
По вспомогательному оборудованию, которое использовалось при испытаниях: Сервер iperf представляет собой обычный настольный компьютер с гигабитной сетевой картой.
Ничего особенного.
Wi-Fi клиент — второй ноутбук HP probook 430 g4. С модулем Wi-Fi, поддерживающим частоту 5 ГГц.
Роутер - с9 арсер.
Топология испытательного стенда максимально проста: 
Функциональное тестирование
Прогоняем все, что попадется нам в руки, по стандартному протоколу.
У нас есть определенные разработки, на которые мы опираемся.
Некоторые моменты меняются от одной спецификации к другой, но основной функционал остаётся практически неизменным вне зависимости от поставленной задачи.
Есть критические точки, отсутствие которых сразу ставит крест на использовании таких устройств в сети (например, при отсутствии ssh или snmp), а есть необязательные точки, наличие которых будет плюсом для прибор при подведении итогов тестирования.
Например, наличие консольного порта.
Да – хорошо, нет – ну не очень-то мне этого и хотелось.
Кстати о консоли На точке Zyxel доступ к консольному порту расположен на корпусе.
Это определенно плюс.
На Ubiquiti консольный порт находится там же, где и у большинства производителей (что совершенно неудивительно — многие так делают, но даже ножек нет): 
Можно провести отдельный холивар на тему того, что: «на нормальном устройстве доступ к консольному порту не нужен в принципе», но я склоняюсь к мысли, что лучше бы он и не нужен был, чем вдруг он понадобится, а его нет (как и в случае с контрацепцией).
Некоторые моменты будут банальны, но, к сожалению, их действительно придется проверить.
Не раз и не два мы сталкивались с устройствами, в характеристиках которых указана поддержка того или иного функционала и эти галочки настроек даже присутствуют в веб-камере, но не работают. Например, приоритезация трафика.
Ставишь нужную галочку в настройках, начинаешь собирать пакеты анализатором трафика, но по факту в заголовках ничего не поменялось.
Грустно.
В данном случае обе точки отлично справились со своей задачей.
Нареканий нет, весь необходимый базовый функционал реализован.
Это даже как-то скучно.
Это не тот низкосегментный сегмент, где вы можете увидеть «ошибку сегментации» из nslookup (да, такое бывает кое-где).
Список по функциональности 1. Поддержка нескольких SSID. Возможность поднять минимум две сети с разными SSID + возможность поднять скрытую сеть.
2. Поддержка 802.11i (безопасность, поддержка шифрования AES).
3. Поддержка 802.11q (возможность передачи тегированного трафика).
3. Поддержка управления vlan. 4. Возможность изменения уровня сигнала радиопередатчика.
5. Поддержка QOS и 802.1p (возможность приоритезации трафика).
6. Возможность ограничения максимального количества клиентов, подключающихся к точке доступа.
7. Управление точками через telnet/ssh/webGUI. 8.Поддержка мониторинга и управления точкой доступа через snmp. 9. Возможность работы точки в централизованном/автономном режиме.
10. Поддержка обнаружения LLDP. 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 нет веб-сервера.
Совсем.
Управление только через контроллер и специальную утилиту.
Папка /www просто пуста, и на портах 80/8080 ничего не работает. Но тут хотя бы есть стандартный busisbox (причем достаточно бесплатный в плане команд), в отличие от Zyxel. Там шаг влево, шаг вправо — расстрел.
Оба пункта мы прошли сканером уязвимостей (Nessus).
Ничего особо критического он не показал.
Ниже приведены результаты и подробное описание того, что было обнаружено.
192.168.0.196 — Зиксель
192.168.0.126 — Убикити 
Вездесущность: 
Один и не критичный.
Считайте – вы ничего не нашли.
Зиксель: Тут интереснее, короче: использование старых небезопасных версий SSL и стандартного публичного snmp-сообщества, которое в настройках предлагается сразу менять при запуске.
тыкать
- Удаленная служба принимает соединения, зашифрованные с помощью SSL 2.0 и/или SSL 3.0. Эти версии SSL подвержены нескольким криптографическим ошибкам.
- Сертификату сервера X.509 нельзя доверять.
Цепочка сертификатов X.509 для этой службы не подписана признанным центром сертификации.
Если удаленный хост является общедоступным, это сводит на нет использование SSL, поскольку любой может организовать атаку «человек посередине» на удаленный хост.
- На удаленном хосте включена переадресация IP. Злоумышленник может использовать это для маршрутизации пакетов через хост и потенциально обойти некоторые брандмауэры/маршрутизаторы/фильтрацию NAC.
- Сообщество snmp по умолчанию (публичное).
- Демон SNMP отвечает О больше данных на запрос «GETBULK» с более чем обычным значением «max-repetitions».
Удаленный злоумышленник может использовать этот SNMP-сервер для проведения широкомасштабной распределенной атаки типа «отказ в обслуживании» на произвольном удаленном хосте.
Мы рассмотрим только диапазон 5 ГГц.
Для сканирования я использовал акрил.
Сами точки включались по одной, чтобы не мешать друг другу.
Плюс для чистоты эксперимента я еще отключил адаптер роутера.
В результате позже нам пришлось проводить еще тесты, но в другом, более тихом месте, потому что.
в первом случае вокруг них была развернута чья-то корпоративная сеть просто из огромного количества точек, на очень широком диапазоне.
каналов (на скриншотах ниже видно, что многие не влезли).
Трафик гнался по iperf, в 5 потоков.
Сначала я тестировал 60 минут, но потом понял, что это не совсем информативно и оставил нагрузку на 4 часа.
Что из этого получилось — в спойлерах ниже:
Убикити
Максимальное значение: 300 Мбит/с (достигает этого потолка и больше не выводит) Минимальное значение: 228 Мбит/с.
Средняя: 296,5 Мбит/с С – стабильность.
Хорошее плавное соединение в любое время.
Краткосрочные просадки есть, но они незначительны.
Статистика во время работы:
(ЦП желтым, синим — память + трафик) 
Зиксель
Максимальное значение: 584 Мбит/с Минимальное значение: 324 Мбит/с.
Средняя: 426 Мбит/с
А вот загрузка процессора немного удивила: 
Когда тест начался, нагрузка подскочила до 91%.
Особых проблем при использовании точки в этот момент не заметил: точка не нагревалась, веб-камера не лагала, потерь пакетов не было.
Тест был на максимально возможную производительность и, несмотря на то, что это не совсем стандартная ситуация, когда гоняется огромное количество трафика за длительный период времени, мы имеем такой случай.
(Доступ к серверам с большим объёмом данных для «мобильных» клиентов) Считаю, что тест пройден успешно.
В любом случае вопрос был задан в службу поддержки Zyxel и сейчас мы ведем переговоры по этой ситуации.
Статистика процессора/памяти: 
Полученные результаты
Подводя промежуточный итог, могу сказать, что точка Zyxel выглядит гораздо привлекательнее с точки зрения использования для тех задач, которые нам были нужны.
При относительно одинаковом функционале выбор всегда будет за стабильность в течение длительного периода времени и, конечно же, производительность.
К сожалению, невозможно абсолютно все охватить лабораторными испытаниями, смоделировать все возможные ситуации, которые могут возникнуть на производстве, и все предусмотреть.
Поэтому в дальнейшем обе точки обязательно пройдут полевые испытания в сетях, максимально приближенных к боевым условиям.
Теги: #Беспроводные технологии #сетевое оборудование #wi-fi #zyxel #ubiquiti
-
История И Эволюция Erp-Системы
19 Oct, 24 -
Миграция С Nagios На Icinga2 В Австралии
19 Oct, 24 -
Яндекс Подвергся Ddos Атаке!?
19 Oct, 24 -
Гауссов Метод В Java
19 Oct, 24
