The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard, opennews (??), 11-Апр-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


242. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от пох. (?), 13-Апр-23, 08:49 
> Вот тоже интересно. Вполне себе стройный, понятно организованный и работающий ifconifg

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

Линуксоиды как раз умеют - у них ip отвечает за ip и самые примитивные операции на уровне линка, включая и замену ненужному route и, о б-же, netstat -r (вот это особенно стройно и понятно - таблицу меняет одна утилита а посмотреть ее можно только в другой с перпендикулярным синтаксисом) а чемоданы настроек wifi и физических деталей адаптера вынесены туда где им место - в отдельные инструменты, поскольку чаще всего оба не используешь.
И управление траффиком - снова отдельно, потому что снова отдельная большая и сложная область где удобнее и разумнее иметь специальный инструмент.

И не миллиард на ходу придумывавшихся ioctl, под каждый чих новый городить, а вполне себе вменяемый и логичный сетевой протокол для управления этими настройками.

Ну да, ну да - не очень-то unix-like получилось - но надо же ж понимать что те юниксы писали когда компьютеры были большие и сети совершенно примитивные. Пока в ifconfig был только up и айпишник - оно было как-то адекватно.

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

По-моему, если откинуть синдром утенка, получилось лучше.

Ответить | Правка | Наверх | Cообщить модератору

261. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от Аноним (261), 13-Апр-23, 12:22 
> По-моему, если откинуть синдром утенка, получилось лучше.

Да, пох, даже ты сегодня в ударе и дело говоришь. Если сравнивать пачку ioctl и нетлинк, нетлинк все же пожалуй лучше. На этот счет есть очень забавное рассуждение вот прямо в доке на wireguard (их пдфнике с сайта). Это том который про его дизайн и протокол разумеется, там расписано как это появилось и почему вот так.

Ответить | Правка | Наверх | Cообщить модератору

278. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от User (??), 13-Апр-23, 19:30 
Нене, про внутрянку я ни слова ни полслова, я именно про логику поведения.
Почему утилита конфигурирования интерфейса пытается охватить все аспекты управления _интерфейсом_ - и не пытается управлять маршрутами мне больмень понятно (route/netstat нет, тут правда фигня) - а вот почему утилита с именем ip из пакета iproute2 пытается рулить  тем, что очевидно ни к "ip" ни к "route" примерно никакого отношения не имеет - уже не очень. Или там почему ip tunnel add mode gre, но ip l2tp add tunnel не ясно.
Ответить | Правка | К родителю #242 | Наверх | Cообщить модератору

296. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от пох. (?), 14-Апр-23, 10:37 
> Или там почему ip tunnel add mode gre, но ip l2tp add tunnel не ясно.

совершенно ясно - tunnel это ip туннель, l2tp - pseudowire, там вообще может не быть ip или он не касается твоего хоста.

Но оба - поверх ip.

Ответить | Правка | Наверх | Cообщить модератору

319. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от User (??), 14-Апр-23, 15:11 
Эммм... ну ок, делаем мы границу по ip\не ip (Несколько странное желание с т.з. конфигурируемой сущности т.к. с т.з. пользователя и то и другое - туннель) - но почему один add tunnel а другой tunnel add? А если про pseudowire - тогда надо вспоминать еще и про ip link add ... type gretap\gre\ipip - и снова видим причудливую логику по которой управление одной сущностью "туннель" рассыпано по разным утилитам.  
Ответить | Правка | Наверх | Cообщить модератору

321. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от пох. (?), 14-Апр-23, 15:32 
потому что первая субкоманда - tunnel, а вторая - l2tp.
link add - это ip линки. У них общий синтаксис - в отличие от pw у которых совершенно другой набор параметров и синтаксис нужен отдельный.

Если пользователь неспособен понять разницу между ip туннелем и pw (между l3 и l2 если пользоваться ущербной терминологией osi) - ему не надо ничего настраивать, ему надо обратиться к сетевому админу.


Ответить | Правка | Наверх | Cообщить модератору

325. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от User (??), 14-Апр-23, 15:45 
Ну вот про это и говорю. "Иди отсюда мальчик - специально обученный человек лучше знает где какой костыль запихан и даже сможет объяснить, что ЭТОТ туннель можно настроить как туннель, тот - как туннель и как ЛИНК, вооот тот - только как линк, а на этот вообще отдельная утиль положена".
Ответить | Правка | Наверх | Cообщить модератору

327. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от пох. (?), 14-Апр-23, 16:26 
ну да. Мне вот не надо объяснять почему там туннель линк, а тут - l2tp. Тем кто это для себя в первую очередь придумывал - тоже не надо было.

А вот объяснить физический смысл -link2 - невозможно, нету его.

Причем если придется передавать больше параметров чем влезает в структуру в ioctl link2 - то только городить отдельный интерфейс с ядром, других вариантов нет.

Ответить | Правка | Наверх | Cообщить модератору

328. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от User (??), 14-Апр-23, 17:53 
Ну вот это и называется "неумение в cli", когда люди пишут интерфейсы "сами для себя" с понятным результатом.
Фря тут не идеальна, но в целом - и в данном конкретном случае тоже - прям СИЛЬНО лучше.
Ответить | Правка | Наверх | Cообщить модератору

298. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от Аноним (298), 14-Апр-23, 11:54 
Я тут не копенгаген, но вот вроде вопрос, в догонку:
почему утилита ip отвечает за мак-адреса на интерфейсе? Или не отвечает? IP разве не уровнем выше? Какого ip вообще за интерфейсы отвечает, а не за internet protocol?
Ответить | Правка | К родителю #278 | Наверх | Cообщить модератору

305. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от пох. (?), 14-Апр-23, 12:51 
> Я тут не копенгаген, но вот вроде вопрос, в догонку:
> почему утилита ip отвечает за мак-адреса на интерфейсе?

потому что это виртуальная характеристика интерфейса, так же как и статус. И ее удобно иметь там же где остальные виртуальные характеристики, а не отдельно в непонятном месте.

> Или не отвечает? IP разве не уровнем выше?

в ip нет никаких уровней - это сбивающая с толку высосанная из пальца выдумка комитета ISO.

> Какого ip вообще за интерфейсы отвечает, а не за internet protocol?

такого что все настройки этого протокола у нас привязаны к интерфейсу.

Ответить | Правка | Наверх | Cообщить модератору

308. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от Аноним (-), 14-Апр-23, 13:09 
"ip" в линуксе это такой grand central настроек интерфейсов и всего что с этим связано. Ему не важен тип интерфейса, он рулит чем угодно - от отсылки интерфейса в сетевой неймспейс и создания виртуальных линков для контейнера до установки мака или up/down линка.

И все это более-менее унифицировано для всех типов интерфейсов (насколко это возможно). Теоретически даже конфиг wireguard можно сделать как субкоманды "ip". Практически пока для этого отдельный wg но он может быть перенесен вот туда при желании.

Единственное исключение - это wifi пожалуй, где сильно специфичные для wifi аспекты рулит все же iw и другие утилиты (eg wpa_supplicant)

Ответить | Правка | К родителю #298 | Наверх | Cообщить модератору

323. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от пох. (?), 14-Апр-23, 15:40 
> Теоретически даже конфиг wireguard можно сделать как субкоманды "ip". Практически пока
> для этого отдельный wg но он может быть перенесен вот туда
> при желании.

это просто кого надо желание и его не проявили. Автор изначально-то именно так и хотел.

Но его-то и в ядро пустили со скрипом и заставив переписать верифицированные алгоритмы на кривую внутриядерную версию.

> Единственное исключение - это wifi пожалуй,

нет, любое место где надо работать со спецификой конкретного железа а не с виртуальным понятием link

ethtool, ib*, iw* и так далее. Они совершенно разные и их нет никакого смысла пихать в одну утилиту - обычно нужно только что-то одно (или ничего из)

Так же как и tc у нас отдельный - потому что это управление отдельной сложной подсистемой и тоже нужной не всем

Ответить | Правка | Наверх | Cообщить модератору

357. "Релиз FreeBSD 13.2 с поддержкой Netlink и WireGuard"  +/
Сообщение от Аноним (-), 15-Апр-23, 13:14 
> это просто кого надо желание и его не проявили. Автор изначально-то именно так и хотел.

На лично мой вкус это 50/50. Я ну уверен что там народ тоже определился на 100%.

С одной стороны, а где тот момнет когда пора угомониться? А то может и iw туда загнать? Он ключи шифрования интерфейсу сетапить тоже умеет, как и вайргад, а то что там еще сотня другая опций, да ладно, пусть кадавр кушает.

С другой отдельная утился "wg" имеет больше свободы и гибкости. Ну вон цветом подкрашивает, без параметров статискути своего типа ифейсов пишет. И стоит ли его в ip утрамбовать - вопрос интересный. При этом придется потерять часто удобства, кастома и фич.

> Но его-то и в ядро пустили со скрипом и заставив переписать верифицированные
> алгоритмы на кривую внутриядерную версию.

С другой стороны, кривой внутриядерной версии при этом тоже так то досталось от души, и там пошли нехилые рефакторы. Это как раз нормальная конвергенция, когда проблема решается с 2 сторон, а не так что 1 в позу встает и перепихивает всю проблему на других. А донфилду зашло и он еще и PRNG в более разумный вид привел, все такое. И вот вполне дельного в крипто субъекта припахали к core works, когда он смежные области улучшил. И для себя и для других. А не просто вывалил с лопаты и слинял.

> ethtool, ib*, iw* и так далее.

Ну хотя да, ты прав. В "ip" такое все же перебор было бы. И вот тут как раз вопрос, считать wg этим же самым или он скорее субкоманда ip? А черт бы его знает, технически всякие ключи и проч это уже специфика интерфейса wg, не хуже чем в iw каком.

> Они совершенно разные и их нет никакого смысла пихать в одну утилиту -

Чисто теоретически можно субкомандами сделать. Ну да с разными параметрами.

Т.е. ip iw ... <параметры iw>. Или ip wg <параметры wg>. Но он станет кадавром. С типа встроенными субкомандами вместо утилит. Надо ли оно - большой вопрос.

> обычно нужно только что-то одно (или ничего из)

Ну да.

> Так же как и tc у нас отдельный - потому что это
> управление отдельной сложной подсистемой и тоже нужной не всем

А так еще файрвол вон есть... :)

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру