Стандарт соглашения об именах для интерфейсов Ethernet и Wi-Fi на компьютерах с Linux

Каков стандарт соглашения об именах для интерфейсов Ethernet и Wi-Fi на компьютере с Linux?

Мы разрабатываем инструмент, который должен отображать только интерфейсы Ethernet и Wi-Fi компьютера с Linux и его текущее состояние.

Например, ниже приведен список сетевых интерфейсов (физических и виртуальных) на моем компьютере с Linux (Ubuntu):

docker0, enp0s25, lo,wlp3s0

Когда я запускаю инструмент, ниже приводится результат, который я получаю:

enp0s25, wlp3s0

Мы написали код с логикой, что все интерфейсы Ethernet всегда начинаются с буквы, eа интерфейсы Wi-Fi всегда начинаются с буквы w.

Правильна ли логика? Если нет, как мы можем решить эту проблему?

Сетевые интерфейсы могут быть названы как угодно, поэтому независимо от того, что вы делаете, вы столкнетесь с ситуациями, когда (1) существует «физический» сетевой интерфейс с именем, которое не соответствует вашему шаблону, или (2) существует «Физический» сетевой интерфейс, который будет соответствовать вашему шаблону.

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

Физические и виртуальные сетевые интерфейсы имеют общий API - вот что делает Linux по-настоящему гибким. Пожалуйста, не пытайтесь нянчить своего пользователя и отнимать это у него или нее. Ваши пользователи будут вам благодарны.

Для предсказуемых системных имен интерфейсов префиксы можно увидеть в udev-builtin-net_id.c:

* Two character prefixes based on the type of interface:
*   en — Ethernet
*   ib — InfiniBand
*   sl — serial line IP (slip)
*   wl — wlan
*   ww — wwan

поэтому как для традиционного ethXстиля именования, так и для более нового именования systemd, начальная буква e должна быть интерфейсом Ethernet для любых автоматически генерируемых имен интерфейсов. Все интерфейсы wifi должны начинаться с w в обеих схемах, хотя не все интерфейсы, начинающиеся с w, будут wifi.

Если этот инструмент должен работать в произвольной среде (а не только на внутренние среды , которые вы контролируете), отмечают , что пользователи могут переименовывать интерфейсы систем Linux с произвольными именами, такими как [ wan0, lan0, lan1, dmz0] , которые будут нарушать любые предположения о начальных буквах ,

Соглашение об именах таково, что интерфейсы LAN называются eth0,eth1 ... и что интерфейсы WLAN названы wlan0, wlan1...

То, что вы видите, это так называемые «предсказуемые имена», которые представил systemd. На практике они совсем не предсказуемы и даже могут меняться при смене аппаратного обеспечения, что и является той проблемой, которой они должны избегать.

Для угадывания начальная буква может быть достаточно хорошей. Некоторые интерфейсы, в частности WLAN, имеют подсказки в /sys/class/net/*/uevent:

DEVTYPE=wlan

К сожалению, DEVTYPEдля интерфейсов ЛВС такого нет .

Одно предостережение с моим ответом (относится и к большинству других): я не знаю цели вашего заявления. Если это одноразовое приложение для устранения одной конкретной проблемы или для лучшего понимания работы сети, которое никогда не будет использоваться снова, то использование первой буквы интерфейса может быть отличным вариантом для быстрого и грязного использования. Если вы планируете записать следующего конкурента в Wireshark или tcpdump, вы должны быть уверены, что получите его правильно для всех видов крайних случаев.

И если приложение, которое вы пишете, находится где-то между этими крайностями, только вы (и ваши клиенты) могут знать, насколько тщательно вам нужно реализовать свою логику.

Другие уже указывали, что имена никогда не бывают достоверными по ряду причин. Конечная проблема очень распространена в программном обеспечении: жесткие предположения вместо того, чтобы полагаться на известные / документированные факты.

Вторая проблема, которая не была упомянута, также основана на предположении о ваших требованиях: список интерфейсов, которые вы хотите перечислить, это всегда именно «аппаратные интерфейсы Ethernet» и «интерфейсы wifi».

Третья проблема - это еще одно предположение: все интерфейсы попадут в категории, о которых вы можете подумать прямо сейчас. Как насчет Infiniband, как упомянуто @ user4556274? Как насчет туннельных интерфейсов для VPN? Как насчет мостовых интерфейсов? Как насчет мостовых интерфейсов, которые объединяют физические и логические интерфейсы?

Но могут быть варианты, чтобы выполнить то, что вы ищете. Во-первых, определите, что именно характеризует интерфейс, который вы хотите перечислить, а не тот, который вы не хотите.

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

Любой интерфейс, который имеет маршрут по умолчанию (т. Е. Маршрут к 0.0.0.0), вероятно, будет тем, который вы ищете.

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

Другой вариант - перейти к реальному оборудованию и посмотреть, какой драйвер он использует. Вы можете исключить некоторых известных водителей

Вы явно исключаете связанные или объединенные интерфейсы? Нашим по умолчанию здесь является использование bond0илиteam0 для основного интерфейса для наших серверов.

Я думаю, вам нужно переосмыслить свою логику. Может быть, попробуйте перебрать все определенные сетевые интерфейсы в данной системе, разделить их между Ethernet, Wi-Fi, Infiband, последовательный порт и т. Д., А затем сделать свое дело.

Не используйте жесткий код или шаблон, соответствующий названиям оборудования. Это относится ко всем устройствам. Положитесь на инструменты, предоставляемые udev, чтобы определить список устройств и предпринять соответствующие действия. См. 16.7 «Постоянное именование устройств» , а затем прочитайте весь этот документ. , в частности 16.2 и 16.3. Обратите внимание, что udev не зависит от распространения, а также от системы init, так как теперь udev является предпочтительным методом управления устройствами в linux.

Обратите внимание, что @ user4556274, ссылаясь на это в своем ответе, ссылается на него udev-builtin-net-id.c, что вкратце означает, что сопоставление с образцом, которое вы пытаетесь выполнить, является встроенной частью udev.

Цитирование PredictableNetworkInterfaceNames :

В systemd 197 мы добавили встроенную поддержку ряда различных политик именования в собственно systemd / udevd и сделали схему, похожую на biosdevname (но в целом более мощную и более близкую к схемам идентификации устройств внутри ядра), по умолчанию. Следующие различные схемы именования сетевых интерфейсов теперь поддерживаются udev:

1. Имена, включающие в себя номера встроенного ПО / BIOS для бортовых устройств (пример: eno1)
2. Имена, включающие встроенное ПО / BIOS, снабженные индексными номерами слотов горячего подключения PCI Express (пример: ens1)
3. Имена, включающие физическое / географическое расположение разъема оборудования (пример: enp2s0)
4. Имена, включающие MAC-адрес интерфейсов (пример: enx78e7d1ea46da) Классическое, непредсказуемое именование ядра ethX для ядра (пример: eth0)

По умолчанию systemd v197 теперь будет называть интерфейсы в соответствии с политикой 1), если эта информация из микропрограммы применима и доступна, возвращаясь к 2), если эта информация из микропрограммы применима и доступна, обратно к 3), если применимо, отступая до 5) во всех остальных случаях. Политика 4) не используется по умолчанию, но доступна, если пользователь выбирает это.

Эта комбинированная политика применяется только в качестве крайней меры. Это означает, что если в системе установлено имя biosdevname, оно будет иметь приоритет. Если пользователь добавил правила udev, которые изменяют имя устройств ядра, они также будут иметь приоритет. Кроме того, любые конкретные схемы распределения именования имеют приоритет.

Как уже говорили другие, вы не можете полностью зависеть от имени.

В моем случае кажется, что для беспроводной сети /sys/class/net/<ifacename>/будет каталог под названием «беспроводной», если это беспроводной интерфейс:

# kbrandt @ kbrandtlx in /sys/class/net [9:47:43] C:130
$ ls
br-b293588ecdae  enp11s0  lo    veth6061cd8  virbr0-nic
docker0          enp12s0  ppp0  virbr0       wlp13s0

# kbrandt @ kbrandtlx in /sys/class/net [9:47:44] 
$ echo  /sys/class/net/*/wireless
/sys/class/net/wlp13s0/wireless