☰

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

tag-icon • tag-icon wifi openwrt
Конфигурация OpenWrt на удаленном сервере

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

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

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

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

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

решение1

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

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

Ниже приведены мои выводы:

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

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

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

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

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

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

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

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

решение2

Что касается 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

С уважением!

Кассио

решение3

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

Связанный контент