Іменування стандарту конвенції для інтерфейсів 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стилю іменування, так і для новішого системного іменування початкова літера e повинна бути інтерфейсом Ethernet для будь-яких автоматично створених імен інтерфейсу. Усі інтерфейси Wi-Fi повинні починатися з w в обох схемах, хоча не всі інтерфейси, що починаються з w, будуть wifi.

Якщо цей інструмент повинен працювати в довільному середовищі (а не тільки на внутрішні середовища , які ви контролюєте), відзначають , що користувачі можуть перейменовувати інтерфейси систем Linux з довільними іменами, такими як [ wan0, lan0, lan1, dmz0] , які будуть порушувати будь-які припущення про початкових буквах .

Угода про іменуванні є те , що інтерфейси LAN названі eth0, eth1... і що інтерфейси WLAN названі wlan0, wlan1...

Що ви бачите, - це так звані "передбачувані імена", які запроваджували системи. На практиці вони є не що інше, але передбачуваним, і вони можуть навіть змінюватися при зміні апаратури, саме такої проблеми вони повинні уникати.

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

DEVTYPE=wlan

На жаль, DEVTYPEдля інтерфейсів LAN такого немає .

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

І якщо програма, яку ви пишете, потрапляє десь між цими крайнощами, тільки ви (і ваші клієнти) можете знати, як ретельно вам потрібно реалізувати свою логіку.

Інші вже вказували, що імена ніколи не є достовірними з будь-якої кількості причин. Кінцева проблема є дуже поширеною у програмному забезпеченні: жорстке кодування припущень замість того, щоб покладатися на відомі / задокументовані факти.

Друге питання, про яке не згадувалося, також ґрунтується на припущенні щодо ваших вимог: що список інтерфейсів, який ви хочете перелічити, завжди є саме "апаратними інтерфейсами Ethernet" та "wifi інтерфейсами".

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

Але можуть бути варіанти зробити те, що ви шукаєте. По-перше, визначте, що саме характеризує інтерфейс, який ви хочете перелічити, порівняно з тим, який ви не маєте.

У більшості випадків однією характеристикою, на яку можна покластися, є таблиця маршрутизації (однак, це працюватиме лише до тих пір, поки інтерфейс не працює, тому він може бути не тим, що ви насправді шукаєте).

Будь-який інтерфейс, який має маршрут за замовчуванням (тобто маршрут до 0,0.0.0), швидше за все, буде таким, який ви шукаєте.

Зауважте, що навіть це все ще базується на припущенні, просто більш надійному: можливо, система налаштована для маршрутизації всього вихідного трафіку через віртуальну машину або контейнер докер (наприклад, якщо контейнер працює з брандмауером) ). І зворотне також вірно: sysadmin може потенційно заблокувати зовнішній трафік, видаливши маршрут за замовчуванням.

Ще один варіант - пройти власне обладнання та подивитися, який драйвер він використовує. Потім можна виключити певні відомі драйвери

Ви явно виключаєте зв’язані чи об'єднані інтерфейси? Нашим замовчуванням тут є використання bond0або team0основний інтерфейс для наших серверів.

Я думаю, вам потрібно переосмислити свою логіку. Можливо, спробуйте ітерацію, хоча всі визначені мережеві інтерфейси в даній системі, розділіть їх між мережею Ethernet, Wi-Fi, Infiband, Serial тощо, а потім зробіть свою магію.

Не вживайте жорсткий код або шаблони, що не відповідають назвам апаратних засобів. Це стосується всіх пристроїв. Покладітьсь на інструменти, надані udev, щоб визначити список пристроїв та вжити відповідних заходів. Див. 16.7 Постійне іменування пристрою , а потім прочитайте весь цей документ , зокрема 16.2 та 16.3. Зауважте, що udev є агностиком розподілу, а також init системою agnostic, оскільки 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) Класичне, непередбачуване іменоване etX-іменування (наприклад: 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