SwitchOS CLI

Это уже не просто «хорошо бы иметь». Это необходимость в мире, где мы движемся к полностью автоматизированным сетям. Нужен способ, чтобы скрипты и системы автоматизации автоматически настраивали и обслуживали коммутаторы на базе SwOS. Хотелось бы увидеть реализацию этого, пусть даже базовую.

Это не помогает с устройствами только для коммутаторов (см. мой список ниже). А для управления коммутаторами SwitchOS работает очень хорошо. При этом было бы здорово иметь хотя бы https…

Коммутаторы только с SwOS — это довольно простые устройства. Продвинутые модели существуют и в вариантах с SwOS, и с ROS (а некоторые вообще могут загружаться в обеих системах). В посте, который я цитировал, говорилось о «высокой автоматизации сетей». Я не вижу, как базовые устройства (только с SwOS) подходят для такого продвинутого использования. Согласен, что полноценный ROS может быть избыточен для конфигурации только с коммутаторами. Но с другой стороны, он даёт все нужные продвинутые настройки для построения «высокоавтоматизированных сетей».

Я вообще не понимаю всей этой шумихи вокруг «https в SwOS». Если уж на то пошло: если человеку всё равно на разделение управления от остального трафика, тогда и http вполне достаточно. Если же важна безопасность управления, то можно просто перенести управление в отдельный VLAN и использовать станцию управления внутри этого VLAN. Опять же, https для этого не нужен. Управлять свитчами через интернет без какого-либо защищённого VPN — мягко говоря, неразумно. Если уж кто-то действительно хочет все навороты, то можно всё это получить, используя ROS. И, кстати, вполне реально (и не так уж сложно) настроить конфигурацию только свитчей через ROS. Я никого не призываю полностью отказываться от SwOS, просто хочу сказать, что для продвинутых настроек (да и вообще по части безопасности) SwOS может оказаться слишком облегчённым. Судя по редким комментариям от команды MT, устройства только с SwOS скорее всего даже не имеют аппаратных ресурсов для чего-то большего, чем простой http.

Аргумент против поддержки https, я поддерживаю: просто держите доступ к конфигурации в защищённой VLAN, тогда http вполне подходит. Аргумент в пользу обновления до ROS я не поддерживаю: не все устройства на это способны. Что касается автоматизированного продвинутого управления без CLI, тут может быть два варианта:
a. Через записи SNMP; SwOS это поддерживает?
b. Через загрузку сгенерированных конфигурационных файлов.

Не думаю, что так. Но могу ошибаться. б. Загрузка сгенерированных конфигурационных файлов. Я этим занимаюсь на этой неделе. Планирую серьезно переставить сетевое оборудование в своем домашнем шкафу. В рамках этого добавляю второй коммутатор CSS326. Я настроил новый коммутатор так же, как и существующий, который станет таким в субботу, и сохранил этот конфиг. Потом перенастроил новый коммутатор так, как он будет работать, и тоже сохранил конфигурацию. В субботу, когда буду делать изменения, подключу свой ноутбук к существующему коммутатору, загружу сохраненный конфиг — и всё должно заработать.

Отсутствие базовых понятий безопасности в этом заявлении просто поражает… VLAN не обеспечивает никакой защиты от перехвата и подделки данных (например, пароль передается открытым текстом по проводам). VLAN хорошо подходит для защиты пути доступа к устройству, но не должен использоваться для защиты данных во время их передачи по проводам или по воздуху. SSL отлично защищает данные в пути, но никак не обеспечивает безопасность доступа.

Если более дешёвые и небольшие производители (типа TP-Link) умеют делать коммутаторы с поддержкой HTTPS, то MikroTik уж точно может. Честно говоря, TP-Link часто даже имеет какую-то базовую командную строку (CLI), хотя жаль, что там нет пассивного PoE.

Очень удивительно, что на этих устройствах отсутствует HTTPS — это может реально помешать нам использовать эти коммутаторы в наших проектах из-за требований соответствия (CSS610 — идеальный выбор для небольших солнечных ретрансляторов).

Это, честно говоря, худшее отношение к безопасности: повторное использование паролей — это далеко не единственная возможная уязвимость, ведь можно легко выполнить, например, внедрение кода и так далее. Уверен, ты бы сильно поменял своё мнение, если бы кто-то сделал сброс настроек на твоём коммутаторе на удалённой базе, которая в восьми часах езды, но да, кому какое дело об активировании самой базовой функции...

Серьёзный вопрос: что именно мешает MikroTik её реализовать? SSL-библиотеки доступны практически для любой архитектуры (и большинство из них — бесплатно).

И вдобавок к твоему явно слабому пониманию безопасности — каковы твои причины, чтобы MikroTik не внедрял это? Чем для тебя может обернуться для тебя реализация этой функции?

Что ты имеешь в виду, внутри SwOS или в HTTP-соединении, когда управляешь коммутатором? Если кто-то уже дошёл до такого уровня, то поздно… Был бы я дураком, если бы надеялся только на правильную работу одного устройства в таком удалённом месте… (да и вообще, я бы не стал использовать что-то только с SwOS). Если HTTP на удалённой сети, управляемой через VPN, вызывает проблемы, что это значит? SwOS настроен так, чтобы отвечать напрямую через публичный IP??? В этом случае проблема не в HTTP, а в том, кто управляет сетью…