Назад | Перейти на главную страницу

Конфигурация OpenWrt на удаленном сервере

У меня в здании 11 точек доступа на базе openwrt. Иногда мне нужно добавить виртуальную сеть с индивидуальным паролем. Я не люблю перебирать точки доступа для изменения параметров. Это сложно и порождает ошибки.

Я бы хотел иметь выделенный сервер (виртуальную машину), который бы сохранял и обновлял всю конфигурацию. Есть ли решение для этого?

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

Обновление: это не только проблема паролей - это может быть решено с помощью сервера Radius, но Radius не может решить некоторые другие вещи, такие как:

  1. создание новых эссидов
  2. присвоение эссидов vlans
  3. включение / отключение трансляции essid
  4. и т. д. и т. д.

Ты спрашивал: "Конфигурация OpenWrt на удаленном сервере: есть ли решение для этого?"

Я ежедневно имею дело с более чем 80 ящиками OpenWRT (три аппаратные платформы, на которых работает смесь Backfire (некоторые), Attitude Adjustment (большинство из них) и Barrier Braker (некоторые)) и ... в прошлом году я начал поиск глубоко о платформе «управления конфигурацией», подходящей для OpenWRT.

Вот мои выводы:

  • OpenWISP: на мой взгляд, очень перспективно. Они создали «кастомную» прошивку (не что иное, как «стандартную» с добавленным скриптом bash и кастомным списком уже установленных пакетов), которая после прошивки просто «подключается» (через клиент OpenVPN) к центральной сервер и загрузите конфигурацию для локального применения. Также имеется приятный веб-интерфейс, с помощью которого можно легко «развернуть» новые точки доступа. К сожалению, это не идеально: например, "шаблоны" (конфигураций) могут быть определены и применены, но ... после этого изменения в шаблоне будут НЕ передаваться дочерним точкам доступа. Кроме того, весь стек программного обеспечения для управления написан на Ruby (и Rails) и ... это может быть проблемой, если вы не "освоите" эти языки / платформы. Когда мы его тестировали, он был основан на Backfire. Теперь, если я прав, он доступен и для обновленной версии (Attitude или Barrier, я не помню). Кроме того, веб-сайт, безусловно, не сильно обновляется, поэтому ... обратитесь к репозиторию GitHub для получения подробной информации. Короче: на него определенно стоит посмотреть.

  • Научная фантастика: платформа, разработанная Бразилианским университетом (насколько я понимаю ... как документация кажется бразильским) это кажется интересным. Немного старовато (пару лет), но опять же интересно. Платформа управления - JavaEE (JBoss) с PostgreSQL в качестве бэкэнда. Он должен быть в состоянии - если я прав - быть принят поверх стоковой прошивки

  • AirKey: они заявляют о себе: "AirKey - это центральная платформа управления точками доступа на основе OpenWRT.". Я мало исследовал, так как он не сильно обновляется (последнее обновление, 4 года назад!)

  • CarrierWRT, также, даже если он не связан строго с центральным управлением, может представлять определенный интерес. Здесь, насколько я помню, одним из препятствий является ограниченное количество поддерживаемого оборудования (но, пожалуйста, проверьте себя).

Как вы сказали: "Я не планирую изобретать велосипед (если только колесо на самом деле не изобретено)", у вас может возникнуть соблазн построить что-то самостоятельно. В таком случае примите во внимание следующее:

  • OpenWRT поддерживает JSON-RPC API с помощью которого вы можете легко взаимодействовать с UCI, используя ... JSON и REST. Если вы освоите такие технологии, это может быть интересно. Позвольте мне добавить, что я пытался (слегка) что-то сделать, но ... похоже, что-то изменилось после BackFire и - если я прав - то, что сработало с BackFire, не будет работать с AA и BB (снова проверьте себя ).

После всего этого я решил, что ... пришло время переключиться на "официальную" платформу управления конфигурацией, и что касается типичного ограничения платформы OpenWRT, мой выбор Ansible поскольку он может работать поверх SSH и не имеет других серьезных зависимостей. Для таких сценариев уже есть что-то построенное (проверьте Вот и Вот), но мне еще нужно это проверить.

Итак, я согласен с комментарием @Michael Hampton "Ansible довольно близок к идеалу для этого"и, на мой взгляд, это должно быть первое, что нужно оценить, поскольку, в конце концов, вы действительно можете рассматривать свой единственный блок OpenWRT как обычную систему Linux, которой нужно управлять с помощью" общего "механизма управления конфигурацией.

Что касается OpenWISP, теперь есть новое программное обеспечение менеджера, не зависящее от Ruby, установка довольно проста: Контроллер OpenWISP 2

Вы также можете интегрировать его в свой существующий проект django путем расширения его основного модуля: django-netjsonconfig.

Также вам не нужно компилировать новую прошивку openwisp для ваших маршрутизаторов, вы можете просто установить компонент конфигурации, который позволяет вашей текущей установке openwrt быть подготовленной менеджером: openwisp-config.

Вы можете установить этот компонент, например, введя следующую команду:

opkg install http://downloads.openwisp.org/openwisp-config/latest/ar71xx/openwisp-config-nossl_0.4.1a-1_ar71xx.ipk

С уважением!

Кассио

Это не совсем ответ на ваш вопрос, но вы можете рассмотреть RADIUS в качестве механизма аутентификации вместо обновления конфигурации каждой точки доступа. AFAIU вам нужна гибкая конфигурация пользователя / пароля.