Deon1sk4 › Блог › Установка и настройка Unifi controller + DHCP+ VLAN+ MongoDB на основе Ubuntu Server 14.04 LTS
Тематика не для этого сайта. Пост для себя, дабы не забыть.
Поставили задачу для реализации бесшовной wifi сети. К хотелкам добавили, что бы была гостевая изолированная сеть и основная корпоративная. Выбрали точки доступа ubiquiti unifi. Что имеется к условиям задачи. Нужно поднять сервак на базе ubuntu 14.04, на основной сетевой интерфейс навесить vlan, поднять DHCP сервер, поднять базу mongoDB ну и поднять сам веб сервер для администрирования точек доступа.
Стартуем)))
Устанавливаем Ubuntu 14.04
Обновляем систему:
sudo apt-get update
sudo apt-get upgrade
1. Устанавливаем MongoDB + Unifi Controller
• Для начала правим лист репозиториев
sudo nano /etc/apt/sources.list
Добавляем строки
deb downloads-distro.mongodb.org/repo/debian-sysvinit dist 10gen
deb www.ubnt.com/downloads/unifi/debian unifi5 ubiquiti
deb dl.ubnt.com/unifi/debian unifi5 ubiquiti
• Добавляем ключи:
apt-key adv —keyserver keyserver.ubuntu.com —recv C0A52C50
apt-key adv —keyserver keyserver.ubuntu.com —recv 7F0CEB10
и обновляемся
sudo apt-get update
sudo apt-get update
• Устанавливаем mongodb
sudo apt-get install -y mongodb-org
• Устанавливаем unifi
sudo apt-get install unifi
2. Настройка VLAN 802.1Q
• Включение поддержки vlan
sudo apt-get install vlan
• Допустим, нам нужно подключить сеть VLAN200. Для этого создадим логический интерфейс «eth0.200», привязанный к физическому интерфейсу «eth0», который будет обрабатывать пакеты с тегом 200.
vconfig add eth0 200
• Если выскочит ошибка «…Maybe you need to load the 8021q module…», надо будет подгрузить модуль 8021q в ядро Linux следующей командой:
sudo modprobe 8021q
• Повесим ip-адрес на новый интерфейс «eth0.200».
sudo ifconfig eth0.200 10.10.X.X netmask 255.255.0.0 up
посмотреть список интерфейсов:
Ifconfig -a
• Что бы настройки vlan не пропадали после перезагрузки сервера его нужно добавить в файл interfaces (конфиг)
sudo nano /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
#wan
auto eth0
iface eth0 inet static
address 192.168.X.X
netmask 255.255.0.0
gateway 192.168.X.X
broadcast 192.168.255.255
dns-nameservers 192.168.X.X
#vlan 200
auto eth0.200
iface eth0.200 inet static
address 10.10.X.X
netmask 255.255.255.0
broadcast 10.10.X.255
vlan_raw_device eth0
Сохраняемся и выходим.
• После нужно перезагрузить интерфейс командой
sudo service network interfaces restart
3. Устанавливаем dhcp server
• Вводим в командной строке терминала команду:
sudo apt-get install isc-dhcp-server
• Настройка конфигурационного файла DHCP сервера
sudo nano /etc/dhcp/dhcpd.conf
subnet 10.10.X.X netmask 255.255.255.0 <
range 10.10.X.10 10.10.X.200;
#option domain-name «MYDOMAIN»;
option domain-name-servers 8.8.8.8;
option routers 10.10.X.X;
option broadcast-address 10.10.X.255;
default-lease-time 604800;
max-lease-time 604800; >
Сохраняемся и выходим
• Перезагружаем службу DHCP
sudo service isc-dhcp-server restart
• Смотрим что бы статус был job/running. Если по какой-то причине не не стартует смотрим лог /var/log/syslog
4. Далее настраиваем Настройка IPTABLES и NAT
• Для начала нам нужно создать файл /etc/firewall.sh
Нужно сделать его исполняемым
sudo nano /etc/firewall.sh
• Даем права на исполнение
sudo chmod +x /etc/firewall.sh
• Далее в скрипт вносим следующие параметры
#!/bin/sh
sysctl -w net.ipv4.ip_forward=»1″
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t filter -A INPUT -i eth0 -p tcp —dport 21 -j ACCEPT
#// Открытие входящего порта 21 на eth0
#// Возможно использование без интерфейса
iptables -t nat -A PREROUTING -p tcp —dport 21 -i eth0 -j DNAT —to 10.10.X.X
#// Переброс порта 21 с интерфейса eth0 на IP в локальной сети 10.10.X.X
#Форвард для изоляции гостевой сети от основной
iptables -A FORWARD -d 192.168.0.0/24 -j DROP
Linux хотспот-контроллер
Данное решение мы предлагаем крупным клиентам и операторам связи.
Специально для вас мы можем настроить ваш сервер для работы в режиме хотспот-контроллера. Контроллер на базе сервера способен обрабатывать до 1000 посетителей и пропускать до 1 гбит/с трафика. Также на нем достаточно мощностей для осуществления шейпинга. Кроме того, сервер собирает подробную статистику по протоколу http вплоть до указания страниц на сайтах, а также всю остальную статистику с помощью протокола netflow по всем портам и протоколам. Собрать такую информацию на обычном роутере невозможно.
Хотспот-контроллер устанавливается на систему Debian (предпочтительно) или Ubuntu . Рекомендуемая конфигурация: 2-х ядерный Pentium, 4ГБ ОЗУ, HDD 100ГБ, сетевой адаптер 2×1000 мбит/с. Минимальная конфигурация: 1 ядро, 1ГБ памяти, HDD 10ГБ, сетевой адаптер 2х100 мбит/с.
В состав хотспот-контроллера входят:
- chillispot controller — настроенный для работы с WiFi System;
- netflow collector — для сбора подробной статистики;
- squid — для уменьшения количества трафика и сбора статистики по http-протоколу;
- firewall — для защиты вашего сервера.
Устройство беспроводного контроллера Cisco и получение рутового доступа к нему
Ко мне часто обращаются с запросами траблшутинга беспроводных контроллеров Cisco, часть из которых проистекает от незнания того, как те устроены и работают. Контроллер беспроводных точек доступа – это не привычный роутер или коммутатор с IOS, это специализированный компьютер (либо виртуалка) с Линуксом внутри. Сегодня мы познакомимся с аппаратными платформами разных контроллеров, узнаем о механизме их лицензирования, разберем на части одну прошивку, и получим рутовый доступ к устройству.
Зачем
Вкратце, контроллеры нужны для централизованного управления большими беспроводными сетями, построенными на базе сравнительно не настраиваемых индивидуально точек доступа. Об этой архитектуре я подробно писал на Хабре (один, два, три, четыре). Точки доступа, расставленные по помещениям предприятия (не обязательно в одном офисе) через локальную или глобальную сеть регистрируются на контроллере, получают с него настройки, управляются им, и предоставляют беспроводной доступ Wi-Fi абонентам. Практически все модели точек доступа Cisco выпускаются как в автономном варианте (независимое управление через CLI или GUI), так и в унифицированном (лимитированный CLI и управление с контроллера по протоколу CAPWAP). Контроллер представляет собой программно-аппаратную платформу взаимодействия с точками доступа, и проводной сетью.
В рамках подготовки к CCIE Wireless (два года назад) для экспериментов мне понадобилось сразу несколько контроллеров, которых под рукой не было. До этого успешно запустив в виртуальной машине ACS, Location Appliance, MSE я попробовал аналогично виртуализовать и сам контроллер. Задача (за полтора года решенная) оказалось сложной, и опыта накопилось предостаточно. Им-то я и хочу поделиться с сообществом. Для начала, давайте посмотрим, что из себя представляет аппаратная начинка контроллера.
Железо
По сути, любой контроллер – это специализированный одноплатный компьютер с процессором некоторой широко известной архитектуры, оперативной памятью, флеш-диском (CompactFlash карта в WISM, WLCM, 440x или напаянная на плату микросхема в остальных моделях), сетевыми картами. Любой сомневающийся может открыть крышку устройства и убедиться в этом самостоятельно.
Cisco 8510 и Cisco Flex 7510 основаны на обычных 1U серверах IBM c дополнительной сетевой картой на базе процессора Cavium Octeon, на который контроллер возлагает пакетные операции реального времени (вроде дешифровки DTLS CAPWAP трафика). Данные контроллеры имеют специфическую нишу — агрегацию трафика очень большого числа удаленных (в режиме FlexConnect) точек доступа, и в силу этого распространения не имеют.
Cisco 5760 и Cisco Catalyst 3850 представляют собой близкие к обычным маршрутизаторам и коммутаторам Cisco устройства. Код контроллера исполняется под управлением IOS XE, такого же, как например, в линейке ASR. Все, о чем пойдет речь ниже, к данным пока еще экзотическим устройствам мало относится.
Уходящие с поддержки модели 4402, 4404 несут на себе процессор MIPS 64, сопроцессор NPE и новыми версиями ПО (> 7.2) не поддерживаются. К ним можно отнести встроенный в коммутатор 3750G-24WS контроллер 4402, а также модуль WiSM в Catalyst 6500 (который из себя представляет два независимых 4404, получающих от шасси только консоль, электропитание, и GigE порты).
Устройства WLCM (для ISR) и SRE (ISR G2) представляют собой модули, устанавливаемые в маршрутизатор серий 28хх/38хх, 29хх/39хх и работающие от них вполне автономно. Различаются процессором (Celeron/i386 и Core/x64) и соответственно производительностью (числом поддерживаемых точек доступа).
Нам наиболее интересны более распространенные автономные контроллеры 2504, 5508, и новый модуль WiSM2 для коммутатора 6500. Последний (сюрприз) — это снова два независимых 5508. В действительности все эти три модели – одно и то же, отличаются только количеством сетевых интерфейсов и производительностью CPU (архитектура 64-бит MIPS).
Замыкает линейку виртуальный контроллер, который продается в виде образа ВМ под VMware ESXi (ovf-файл). Логично, что его архитектура соответствует стандартному оборудованию виртуальной машины: процессор x64, диск LSI SCSI, сеть Intel E1000.
Два года назад виртуального контроллера не было. Я попробовал виртуализовать наиболее близкий по архитектуре WLCM (NME-AIR-WLC), что однако потребовало разбора и исследования прошивок (примерно по методике ниже), написания драйвера эмуляции NVRAM для MontaVista 4.0, изучения Ida Pro, модификаций сетевых потрохов QEMU, разбирательств с сетью в ESXi и заняло примерно год времени в вялотекущем режиме. И такой контролер заработал! Правда, современные версии ПО контроллера (>7.2) WLCM более не поддерживают, а у нас есть vWLC, поэтому мои результаты имеют только академическую ценность.
Помимо очевидных различий в производительности (количестве одновременно поддерживающихся точек доступа и беспроводных абонентов) все контроллеры отличаются и функционалом. Главным образом различия сводятся к поддержке wired guest, guest access, mobility-anchor, мультикасту, IPV6 и т.п. редко требуемым фичам. Реально весомое различие — поддержка local mode (традиционного режима) реализована на 2504/5508/WISM2, в то время как Flex7500/vWLC довольствуются только FlexConnect.
Программное обеспечение контроллера представляет собой файл размером порядка 100 мегабайт, который вы можете скачать на сайте производителя, если у вас есть сервисный контракт либо нагуглить по известному оттуда же имени файла. Для типичного AIR-CTYYYY-K9-X-X-XX.aes расширение .aes не должно вводить вас в заблуждение: оно не имеет никакого отношения к протоколу шифрования. В имени файла прошивки (firmware) может встретиться слово LDPE (Licensed Data Payload Encryption). Это означает, что данная прошивка активирует возможность шифрования пользовательского трафика (CAPWAP туннель управления все равно шифруется через DTLS/AES) отдельной лицензией. Это Cisco специально придумала для пользователей из России, чтобы K9-устройства не попадали под законодательные ограничения ввода средств шифрования.
Внутри файла прошивки проприетарного формата вы увидите немного бинарного мусора, куски шелл-скриптов, большие блоки, похожие на tar- или gz-архивы. Это совсем не напоминает плотноупакованный, монолитный двоичный образ IOS (Internetwork Operating System, не путать с яблочным iOS) какого-нибудь традиционного Cisco-устройства. Поэтому не стоит пытаться проводить какие-либо обновления путем непосредственного удаления-заливки .aes-файла на флеш, вы только окирпичите устройство.
Возьмем последнюю на сегодня версию 7.5.102.0 для контроллера 5508, AIR-CT5500-K9-7-5-102-0.aes. Любопытный факт: помните, я говорил, что 2504, 5508 и WiSM2 – это одно и то же? Если присмотреться, для всех них файл ПО этой версии прошивки имеет одну длину (133146180 байт) и контрольную сумму (62ba852937eefaadaaba25e3b6cc18fc). Софт сам определяет, на какой платформе он работает. Ну а вы, если имеете софт под одну из трех платформ, автоматически имеете его под остальные – просто переименуйте файл.
Получение рутового доступа
Как вы знаете, подключаясь по SSH либо консолью к контроллеру, вы попадаете в интерфейс командной строки, который слегка напоминает IOS. Слегка — потому что вся линейка контроллеров основана на историческом коде, полученном Cisco в результате приобретения компании Airespace в 2005 году. Раз мы знаем, что контроллер построен на базе ОС Linux, возникает вопрос – можно ли получить shеll-доступ к самой системе, желательно рутовый. Попробуем это сделать на примере установленного по инструкции виртуального контроллера. После установки версии 7.4.100 я дополнительно обновил его до версии 7.5.102.
Просто так в его шелл попасть нельзя (это вам не Prime NCS)
Наш «виртуальный контроллер» CTVM выполняется как виртуальная машина под управлением VMware ESXi. Выключим контроллер (кнопкой Power Off) и подключим его виртуальный диск (.vmdk) к какой-нибудь другой нашей виртуальной машине на том же хосте. Я для подобных целей использую Debian/GNU Linux как наиболее близкий к оригинальной ОС вариант. Что мы видим:
Четыре партиции. Попробуем примонтировать их все:
Раздел 1 содержит бутлоадер (grub) и рекавери ядро rescue.img, раздел 2 не монтируется совсем (и не используется данной версией контроллера), раздел 3 содержит лог-файлы, а раздел 4 содержит самое интересное. Приведу урезанный вывод ls –la с комментариями.
vmstore.bin представляет собой монтируемый образ системного хранилища сертификатов и лицензий, о чем поговорим ниже.
Содержит файлы конфигурации контроллера, ключи SSH, SSL-сертификаты Webadmin и Webauth.
Вы, вероятно, знаете, что исчерпывающую конфигурацию коммутатора и маршрутизатора Cisco можно получить через sh run, чтобы заархивировать её, либо залить на другое устройство. Первоначально в беспроводных контроллерах тоже так было. Однако сейчас вывода команды sh config недостаточно, чтобы полностью понять то, что настроено на устройстве. Для этого придется применять многочисленные show. . Дело в том, что реальная конфигурация устройства теперь находится в наборе XML-файлов, расположенных в /application/xml, а каждый запуск команды sh config вызывает специальный код преобразования этого XML в текстовый CFG. Работа над таким преобразователем запаздывает по отношению к развитию устройства (а, может, и вообще заброшена), поэтому на sh config ориентироваться нельзя. Вместе с тем, полная настройка устройства через команды типа config … (т.е. без web gui) возможна. Более того для ряда задач графического эквивалента текстовой команде просто нет. Естественно, в недрах устройства есть обратные инструменты преобразования команд в XML.
Здесь мы видим primary и backup ядра операционной системы контроллера, а также два каталога с primary и backup версиями прошивок точек доступа (о них далее).
Что же представляет собой ядро ОС контроллера? Судя по размеру, оно содержит в себе initramfs, корневую файловую систему со всеми утилитами, монтируемую в память сразу после старта ядра. Кстати, в предыдущих версиях контроллера initrd поставлялся в виде отдельного файла образа ext2fs, что значительно упрощало задачу его модификации.
Для получения рутового доступа необходимо разобрать ядро на части, поменять что-то в корневой ФС, и собрать всё обратно. Для этого посмотрим, как устроено ядро. На удивление, внятного описания структуры собранного ядра вкупе с инструментами его разбора в Интернете почти нет (отдаленно помогает binwalk). Ясно, что ядро запаковано, и наверняка запаковщик – gzip. Сигнатура gzip-файлов проста – все архивы начинаются с 0x1F 0x8B 0x08. Поищем место начала архива, вырежем, распакуем, посмотрим что внутри, повторим и т.д. В результате вырисовывается следующая структура:
Константы K1, K2 и K3 подбираются экспериментально и зависят от версии firmware. 2.gz находятся в самом конце ядра, а магическая комбинация gzip там встречается много раз – например известно, что в ядре находится запакованный .config, использованный при его сборке. Для распаковки составился следующий скрипт:
На выходе имеем каталог initramfs, содержащий корневую файловую систему контроллера. Для получения root access достаточно поправить следующие файлы:
- Отредактировать ./etc/inittab так, чтобы при старте запускалась консоль, а не код беспроводной системы:
a. Меняем местами комментарии, разблокируя консоль:
con:2345:respawn:/sbin/getty console
#con:2345:respawn:/bin/gettyOrMwar
b. Раскомментируем со 2 по 6 виртуальные терминалы:
2:23:respawn:/sbin/getty 38400 vc/2 - Пользователю root в /etc/passwd прописываем нормальный шелл, /bin/bash
- Можно также сделать неисполняемым ./etc/init.d/S95mwar, чтобы контроллер без спроса не запускался
Теперь соберем всё обратно. Помним, что архивы в ядре имеют максимальную степень сжатия. При наших манипуляциях наверняка размеры результирующих кусков будут меньше оригинальных, посему для сохранения бинарной структуры добавим блоки с нулями.
Теперь надо убедиться, что модифицированное ядро имеет тот же размер, что оригинальное, и положить его на место:
Можно выключать тестовую виртуальную машину с Linux, и включать контроллер (ESXi один виртуальный диск, .vmdk файл, двум VM одновременно использовать не даст). Загружаем контроллер:
Итог: у нас есть полный, рутовый доступ к работающему виртуальному беспроводному контроллеру Cisco vWLC.
Устройство работающего контроллера
Очевидно, что контроллер построен на базе специализированной версии Linux производства MontaVista. При старте происходит монтирование указанных выше файловых систем, стандартная инициализация, загрузка модулей ядра, проверка наличия чипа Octeon и загрузка его прошивки. Сетевые карты контроллера в этот момент IP-адресов не имеют. В конце запускается сам код беспроводного контроллера скриптом-обвязкой /bin/bsnmwar. Mwar – Main Wireless Application Routine. Код контроллера содержится в монолитном, статически слинкованном файле /sbin/switchdrvr (ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, stripped), который занимает добрую половину объёма всей прошивки контроллера, и реализует полностью логику его работы. Именно при его запуске на консоли появляются знакомые строки инициализации компонентов контроллера (Starting …. ok), инициализируются сетевые интерфейсы, запускается отдельным процессом демон управления лицензиями, появляется веб-интерфейс и начинают обслуживаться точки доступа и беспроводные клиенты. Шелл-доступ к консоли пропадает, и пользователь попадает на стандартное приглашение консольного логина в контроллер (но мы помним про запущенные getty на остальных виртуальных терминалах, возникшие вследствие нашей модернизации inittab).
В процессе запуска switchdrvr происходит монтирование файла /mnt/wlc/vmstore.bin с лицензиями и сертификатами в память (losetup) и перемонтирование раздела с прошивками точек доступа. В результате точки монтирования выглядят так:
Точки доступа
Режим их работы определяется прошивкой, которую можно поменять с AP (теперь зовётся SAP, standalone access point) на LAP (lightweight access point) и наоборот. Прошивка в обоих случаях – это IOS, скомпилированный под аппаратную платформу самой точки (все точки — PowerPC различной древности). Файл прошивки для автономной точки будет иметь имя вроде c1130-k9w7-tar.124-3g.JA.tar, а «легковесной» — c1130-k9w8-mx.124-23c.JA3.tar Различие – в W7 и W8. Также существуют «восстановительные (рекавери)» версии вида c1130-rcvk9w8-mx. Здесь прошивка не содержит кода работы с радио, ее цель — запуститься, найти контроллер, и загрузить с него «рабочую» версию софта. Кстати, по последним буквам имени файла легковесной прошивки можно определить версию контроллера, которой она соответствует. Например, 152-2.JB это 7.4.100, а 124-23c.JA3 это 7.0.220.
Все контроллеры несут в себе копии прошивок поддерживаемых ими точек доступа. При подключении точки доступа к контроллеру проверяется соответствие версий, и если те отличаются, происходит автоматическая установка ПО с контроллера. При этом возможен даунгрейд версии. Контроллер будет работать только с соответствующей ему версией ПО точки. Поэтому, если у вас в сети работают два контроллера с ПО разных версий, а точки доступа могут выбрать либо один, либо второй, при «перескоке» с одного контроллера на другой точки будут менять своё ПО. Это долго, и чревато поломкой флеш-памяти точки от постоянной её перезаписи.
Несмотря на то, что что протокол CAPWAP обмена между контроллером и точкой доступа стандартизирован, нет никаких шансов, что контроллер Cisco будет в обозримом будущем работать с точками доступа сторонних производителей. В конкретной реализации очень много недокументированностей, да и не нужно (не выгодно) это никому.
Лицензирование
Для нетерпеливых: средства «поломать» механизм лицензирования контроллеров на сегодня нет.
Старые платформы контроллеров лицензировались по количеству точек доступа аппаратно. Информация по количеству максимально обслуживаемых точек содержится в NVRAM рядом с серийным номером, и не обновляется (нельзя докупить поддержку дополнительных точек).
Все новые платформы используют современный подход, основанный на выписывании лицензии на основе UDI (имя продукта/платформы + Serial Number устройства) на Cisco.com/go/licensing с указанием PAK-ключа, т.е. подтверждения приобретения вами права на устройство и ПО. Таким образом, лицензии можно докупать по мере роста числа установленных у вас точек доступа, в пределах аппаратных возможностей платформы. Можно также один раз активировать демо-лицензию на 90 дней.
Виртуальный контроллер генерирует свой серийный номер в первый раз при запуске, руководствуясь MAC-адресом устройства (предоставляемым VMware) и, вероятно, некоторыми другими параметрами вроде идентификаторов CPU.
Данный метод лицензирования платформ и компонентов применяют все устройства на IOS 15.0, IOS XR, IOS XE, NX-OS и т.д.
Сама лицензия имеет такой вид:
Она привязана к серийному номеру устройства, и содержит некоторый аналог цифровой подписи, которая несет в себе хэш указанных в начале лицензии строк. При попытке загрузки лицензии в контроллер (switchdrvr) последний проверяет ее через взаимодействие с работающим отдельным процессом менеджер лицензий (licensed). Есть и утилита командной строки, license_cli. «Ручные» вмешательства в файл лицензии приводят к ошибке обработки. Протокол обмена клиента и сервера не известен (идет через unix domain сокет). Поскольку licensed является 32-битным приложением, он легко разбирается интерактивными дизассемблерами/отладчиками вроде Ida Pro/HexRays на псевдоисходные тексты на С, анализ которых явно говорит о применении библиотек шифрования и подписей Sentinel производства SafeNet. Для дальнейшего разбирательства моих знаний не хватает, да оно мне и не нужно. Насколько известно, генератора лицензии пока еще нет, но самоцензура.