[devel] подсистема настройки сети в дистрибутивах
Alexey Shabalin
a.shabalin на gmail.com
Чт Апр 18 18:04:24 MSK 2024
чт, 18 апр. 2024 г. в 12:17, Alexey V. Vissarionov <gremlin на altlinux.org>:
>
> Good ${greeting_time}!
>
> On 2024-04-17 20:21:40 +0300, Alexey Shabalin wrote:
>
> > День добрый. Хочу поднять обсуждение о подсистеме настройки сети
> > в наших дистрибутивах. Ситуация сейчас следующая: - в рабочей
> > станции и других дистрибутивах с GUI используют NetworkManager
> > - в сервере есть попытка перехода на systemd-networkd (почему
> > поытка - ниже :). etcnet оставлен как запасной вариант.
>
> Все это - решения для рабочих станций. Ну, еще в совсем простых
> сетях можно для локальных серверов как-то что-то наколхозить.
На самом деле все сложное в сетях должно делаться на сетевом оборудовании.
А на сервера или рабочие станции сеть должна подаваться в максимально
простом виде.
Для надежности.
В "сложном" виде (bonding, тэгированные vlan) сеть подается на хосты
виртуализации или програмные маршрутизаторы.
Netplan умеет типовые простые и сложные сети. Понятно, что можно найти
особенный случай, который не поддерживается.
Его тоже можно решить pre и post хуками, запуская скрипты.
>
> > Сам проект etcnet в стагнации. Не развивается, только закрываются
> > откровенные баги. И есть серьезные причины избегать его
> > использования. Например, service network reload по факту делает
> > restart всей сети, в том числе теряет подключение всех виртуальных
> > машин к bridge, после чего виртуалки приходится переключать
> > заного к "виртуальному коммутатору". Т.е. нет возможности
> > применить только изменения в конфигах, кладется вся сеть целиком.
>
> Конфигурация сети - это не демон, для нее reload|restart хоть и
> возможны технически, но особого смысла в абсолютном большинстве
> случаев не имеют.
У нас разные клиенты :)
Кто-то настраивает сеть через web-интерфейс PVE, и не ожидает, что
нажав кнопку Apply потеряет доступ к хосту.
А теряет потому, что network reload на самом деле restart.
>
> > Предложение: Давайте рассмотрим вариант использовать в
> > дистрибутивах netplan [...]
> > умеет настраивать bond, bridge, vlan,
>
> VLAN? Вот прямо с перенумерацией и QinQ?
да, networkd умеет, в том числе и 802.1ad
>
> > openvswitch, wireguard, wifi, тунели. Вроде все что нам обычно
> > нужно.
>
> Как насчет хотя бы VRF? :-)
Да.
Смотри https://github.com/canonical/netplan/blob/main/examples/vrf.yaml
>
> А ведь есть и другие полезные (а иногда и просто необходимые)
> функции сетевой подсистемы ядра. Причем далеко не все они даже
> в LARTC описаны (увы, там с 2012 года застой).
>
> > есть dbus интерфейс (может пригодиться для нового alterator)
> > netplan apply применяет изменения настроек, без полной
> > перезагрузки сети
>
> Вот как раз это совершенно не критично.
>
> > Минусы: - админские утилиты на python
>
> А это сразу исключает использование данной приблуды там, где
> необходимо минимизировать поверхность атаки. Серверы, ага.
>
> > Если перерабатывать alterator-eth, то может сразу на использование
> > netplan, который умеет генерировать настройки для NM и networkd?
> > PS: я не призываю удалять etcnet из сизифа. Я говорю о
> > дистрибутивах, которые по факту уходят от использования etcnet.
>
> Для десктопов оно избыточно (еще больше, чем NM), для серверов
> малопригодно... что остается-то, ноутбуки?
>
А мне кажется пригодно для для всех трех случаев.
--
Alexey Shabalin
Подробная информация о списке рассылки Devel