UniFi 4.6.6 на Debian 8.1

Posted: 2015-08-05 in IT, Networks
Метки:,

Два года назад я делал перенос UniFi-контроллера с виндовс на дебиан. С тех пор довольно сильно поменялись как версии UniFi, так и Дебиана. Вот об этом и поговорим.

Текущая версия унифая — 4.6.6, тогда как два года назад была версия 2.4.6. Как и раньше, бэкап настроек делается зашифрованным бинарным файлом *.unf, при этом форматы или ключи шифрования разные. То есть просто восстановить на 4.6.6-контроллере бекап от 2.4.6 нельзя — надо перенастраивать заново. Из серьёзных изменений — сменился UniFi API (важно для внешних гостевых порталов и подобных систем), пароли теперь хэшируются, для соединения с контролером используется TLS (SSL откючен), один контроллер может обслуживать несколько сетей сразу (т.н. MultiSite) — каждая со своими правилами шейпинга, настройками беспроводных сетей, своими точками и своей статистикой по траффику.
Рассказывать про установку и обновление дебиана не буду — просто качаете минимальный NetInstall-образ, ставите из него минимальную систему, обновляете.
Можно обновить и апт-гетом со старых версий, но там есть такой ньюанс — поскольку у меня полноценная виртуальная машина, то иск в ней — эмулируемое блочнгое устройство, размер использованных блоков в котором заметно растёт. Так что если есть желание уменьшить размер образа финальной ВМ с контроллером — лучше сделать чистую сетевую установку в новую ВМ.

Дальше надо в /etc/apt/sources.list.d прописать репозитарии UniFi и MongoDB:

# cat 100-unifi.list
## Debian/Ubuntu
# stable => unifi4
# deb http://www.ubnt.com/downloads/unifi/debian unifi4 ubiquiti
deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti

# cat 200-mongo.list
## Debian
deb http://downloads-distro.mongodb.org/repo/debian-sysvinit dist 10gen

Дальше просто пишем apt-get install unifi , и получаем рабочий контроллер. Вся дальнейшая настройка делается через веб-интерфейс, порт — 8443.
В новой версии 4.6.6 интерфейс сильно поменяли:
UniFI_4.6.6__1
Что ценно — использование нестандартного порта позволяет на эту же машину, где и контроллер, повесить веб-сервер с гостевым порталом (актуально длял всяких кафешек, гостиниц, баров и прочих подобных мест). Кстати, на эту же систему легко прикручивается свой набор скриптов лдя авторизации SMS-ками. Метод конечно демонический и опасный для оператора, но вполне рабочий.

В прошлый раз я забыл рассказать, чем же там замечателен UniFi. Что понравилось мне ?

* Контроллер софтовый, бесплатный, есть на линукс и НЕ КРИТИЧЕН в половине сценариев использования. То есть если 16 ваших точек UniFi раздают на большой территории завода три беспроводных сети, каждая из которых имеет свои правила шейпинга и ведёт в свой изолированный VLAN, и при этом используется только WPA2-авторизация (без гостевого портала) — то контроллер достаточно запускать разово, только когда надо что-то поменять в конфиге беспроводной сети. В бэкапе, в принципе, можно хранить только UNF-файл.

* Контроллер должен быть постоянно включен только для сценариев с гостевым порталом — когда пользователю показываются вспомогательные страницы / дополнительная авториазция и тому подобное. У большинства вендоров контроллер беспроводной сети такого класса — отдельная аппаратная коробка, стоящая (непонятно с каких хуёв) несколько сотен тысяч вечнодеревянных рублей. Хотя у UniFi их контроллер легко разворачивается на любом корыте с линуксом.

* Схема включения контроллера — в той же L2-сети, что и точки доступа, с виртуализацией прекрасно дружит. 256 Мб оперативной памяти более чем достаточно.

* Шейпинг полосы пропускания, вланы, DHCP Guard — из коробки.

* Управление точками доступа со стороны контроллера идёт по протоколу SSH — никакого лишнего самописного фуфела не используется.

* Возможность управления WiFi-сетью через Web-API (JSON) позволяет даже такому ленивому админу, как мну, за недельку написать и довести до рабочего состояния крутилку рекламы, авторизацию по СМС-кам и прочие плюхи, причем не особо напрягаясь и потребляя чудовищные количества чая и пряников.

* Даже в случае использования системы ваучеров (встроенная фишка, позволяющая выдать доступ на время по заранее сгенерированным кодам доступа) нагрузка на контроллер ничтожна. Даже старый 433-й дохлерон прекрасно справится. И никакой ебатни с софтовым лицензированием!

* Гостевой портал есть нескольких видов: простая кнопка подтверждения, ваучерная система, встроенный-портал-с-кастомизацией, подключение полностью своих скриптов (из настроек — указать IP-адрес своего веб-сервера), и даже интеграция с какой-то хренью на пейпале (это не тестил).

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

* Мультисайтинг — несколько вайвай сетей на одном контроллере. Особый зачет — можно несколько совершенно разных гостевых порталов повесть на один веб-сервер (а можно раскидать по разным). Для сложных конфигураций — прекрасное решение.

Если не считать небольшой гемор с переносом со старых версий — то система прекрасна. Рекомендую крайне.

Теперь немного о возможных проблемах и граблях, которые могут встретиться.

* UniFi-API. Есть свои тонкости — для работы необходимо активно уметь JSON и авторизационные куки в токенах.
Например, в UniFi-2.4.6 для авторизации и получения токена отправляется обычная веб-форма с полями username и password. В 4.6.6 отправляется JSON-блок прямо в теле POST-запроса! PHP_CURL и консольный клиент curl всё это умеют, но всё же не забыть.

* Криптография. API доступен только по HTTPS. 2.4.6 использовал SSLv3, да ещё и со слабыми значениями для DH, что требовало в CURLOPT указывать принудительное использование SSLv3 и какой-нибудь связки хэшей/шифров, не использующих DH — иначе curl страшно ругался и совсем не хотел дышать. В 4.6.6 это исправили — теперь там TLS, CURLOPT можно малость сократить.

* Немного поменялись пути. Документация на UniFi API — в скрипте-примере. Важно, что в путях указывается имя сайта — по умолчанию «default», для других — некий набор символов.

* При обработке пользовательского ввода из гостевого портала не доверяйте слепо переданному MAC-адресу! При осуществлении редиректа в гостевой портал MAC-адреса клиента и точки доступа передаются тупо в GET-параметрах, и никакого контрольного хэша там не предусмотрено! Если это критично (например, вы для каждого клиента делаете SMS-валидацию) — проверяем MAC-адрес клиента в базе контроллера UniFi по его API. Номера телефонов тоже проверять регэкспами надо обязательно.
Иначе один школо-хакир — и весь баланс SMS-сервиса сажается в ноль легко и непринуждённо. Если разрешить отправку смс на номера Мальдив или Сомали с Гвинеями — буквально 20-30 таких СМС-ок враз посадят баланс на жопу. Не забывайте об этом!

Реклама
- комментарии
  1. Кирилл:

    Доброго времени суток. О, уважаемый всемогущий системный администратор, е будете ли вы так любезны снизойти до презренных людишек, бегающих по земле под вашим чутким логом и не поделитесь ли скриптами контроллера для sms, рекламы и прочими плюшками? Или хотя бы кратко описать алгоритмы их работы и общее назначение.

  2. Нет, код этих скриптов напрямую я пока что не предоставляю. Во-первых, это писалось на заказ, во вторых, качество этого кода далеко от совершенства.

    Но ключевые идеи расскажу.
    Когда включаете опции «Enable Guest Portal» и режим портала «Custom Server», вы можете указать IP, куда редиректить каждого вновь прибывшего клиента или клиента с истекшей сессией. В GET-паратерах будут MAC-адреса клиента и точки доступа. Вот их надо проверить, при необходимости — сохранить в базе, и дальше написать свою логику работы, в зависимости от требований заказчика.

    Может, показать рекламу (учтите, что неавторизованный клиент не может загрузить что-либо из внешний сетей, все картинки и баннеры должны лежать на мини-сайте кастомного портала!), запросить что-либо, проверить по базе. Для того, чтобы изменить статус клиента в UniFi (активировать сессию, закрыть сессию, проверить валидность клиентского MAC, что-то еще сделать), веб-скрипт кастомного портала должен дать команду UniFi-контроллеру и обработать полученный ответ. Команда дается по HTTP — но с использованием JSON, посланного через шифрованное соединение на порт 8443 с авторизационными кукисами.

    Чтобы не мутить адов ад со своей реализацией HTTP-клиента, сетевыми сокетами, mod_openssl (частично сломанный в PHP 5.6+) и прочими ужасами, проще всего использовать php_curl — там есть всё, что требуется, кода минимум. Но придется повозиться с SSLv3 и CURL_OPT на старых контроллерах и с ректальной реализацией JSON внутри POST — на новых.

    Для отправки SMS есть два годных сервиса — smsc.ru и smstraffic.ru
    Регаетесь, получаете логин/пароль, пополняете баланс. Отправка смс делается простым HTTP-GET по инструкции с сервиса. Естественно, надо продумать, чтобы клиент не мог отправить 100500 раз гребаную смс-ку. Это не почта, тут такая дырка — попадос на баблос.

    Но поскольку вы номер тоже получаете от клиента, то проверять его надо регулярными выражениями, чтобы это был либо короткий прямой федеральный номер (7 цифр), либо мобильник доверенной зоны. Премиум номера, спутники, всякий межгород — не должен проходить в принципе. Иначе может случиться пиздец.

    Ну вот ключевые идеи примерно такие.

    P.S. Идея светить свой номер мобилки всяким левым сетям мне не нравится. Заказ я конечно выполнил, но поскольку я не считаю такую идею изначально правильной, то и готовых исходников скорее всего не будет.