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

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

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

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

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

  1. создавая новые эссиды
  2. назначение эссидов вланам
  3. включение / отключение вещания essid
  4. и тд и тд и тп
Источник

3 ответа

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

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

Здесь ниже мои выводы:

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

  • Sci-Fi: платформа, разработанная Бразильским университетом (насколько я понимаю... поскольку документация кажется бразильской), которая кажется интересной. Это немного стар (пару лет), но, опять же, кажется интересным. Платформа управления - 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 Controller

Вы также можете интегрировать его в существующий проект 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 как механизм аутентификации вместо обновления конфигурации каждого AP. AFAIU вам нужна гибкая настройка пользователя / пароля.

Источник
Другие вопросы по тегам