Standard konwencji nazewnictwa dla interfejsów Ethernet i Wi-Fi na komputerach z systemem Linux

Jaki jest standard konwencji nazewnictwa dla interfejsów Ethernet i Wi-Fi na komputerze z systemem Linux?

Opracowujemy narzędzie, które powinno pokazywać tylko interfejsy Ethernet i Wi-Fi maszyny z systemem Linux oraz jej obecny status.

Na przykład poniżej znajduje się lista interfejsów sieciowych (fizycznych i wirtualnych) na moim komputerze z systemem Linux (Ubuntu):

docker0, enp0s25, lo,wlp3s0

Po uruchomieniu narzędzia poniżej otrzymuję wynik:

enp0s25, wlp3s0

Napisaliśmy kod z logiką, że wszystkie interfejsy Ethernet zawsze zaczynają się na literę, ea interfejsy Wi-Fi zawsze zaczynają się na literę w.

Czy logika jest prawidłowa? Jeśli nie, jak możemy rozwiązać ten problem?

Interfejsy sieciowe można nazwać dowolnymi nazwami, więc bez względu na to, co robisz, natkniesz się na sytuacje, w których (1) istnieje „fizyczny” interfejs sieciowy o nazwie, która nie pasuje do twojego wzorca, lub (2) istnieje „fizyczny” interfejs sieciowy, który będzie pasował do twojego wzorca.

Co więcej, gdybym był użytkownikiem twojego narzędzia, moment, w którym twoje narzędzie nie pozwoli mi zrobić czegoś, co chcę, ponieważ mam interfejs sieciowy, który jest „wirtualny”, chociaż ze względów praktycznych należy to wziąć pod uwagę „ physical ”w mojej konfiguracji zacząłem przeklinać głośno i mocno na twoją aplikację i nigdy więcej jej nie użyję.

Fizyczne i wirtualne interfejsy sieciowe mają wspólny interfejs API. To jedna z rzeczy, która sprawia, że ​​Linux jest naprawdę elastyczny. Proszę nie próbować opiekować się użytkownikiem i zabrać mu to. Twoi użytkownicy będą Ci wdzięczni.

W przypadku systemowo przewidywalnych nazw interfejsów prefiksy można zobaczyć w 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

więc zarówno dla tradycyjnego ethXstylu nazewnictwa, jak i nowszego systemowego nazewnictwa, pierwsza litera e powinna być interfejsem ethernetowym dla wszelkich automatycznie generowanych nazw interfejsów. Wszystkie interfejsy Wi-Fi powinny zaczynać się od W w obu schematach, chociaż nie wszystkie interfejsy rozpoczynające się od W będą Wi-Fi.

Jeśli narzędzie to musi pracować w dowolnym środowisku (a nie tylko na środowiskach wewnętrznych którego Control), należy zauważyć, że użytkownicy mogą zmieniać nazwy interfejsów w systemach Linux z dowolnych nazwach, takich jak [ wan0, lan0, lan1, dmz0], które będą łamać żadnych założeń dotyczących początkowych liter .

Konwencja nazewnictwa jest to, że interfejsy LAN są nazywane eth0, eth1... i że interfejsy WLAN są nazywane wlan0, wlan1...

To, co widzisz, to tak zwane „przewidywalne nazwy”, które wprowadził system. W praktyce są one mało przewidywalne, a nawet mogą ulec zmianie po zmianie sprzętu, co jest dokładnie problemem, którego powinni unikać.

Domyślam się, że litera początkowa może być wystarczająca. Niektóre interfejsy, w szczególności WLAN, mają podpowiedzi w /sys/class/net/*/uevent:

DEVTYPE=wlan

Niestety nie ma takich DEVTYPEinterfejsów LAN.

Jedno zastrzeżenie z moją odpowiedzią (dotyczy również większości pozostałych): nie znam celu twojej aplikacji. Jeśli jest to aplikacja jednorazowa, która rozwiązuje jeden konkretny problem lub lepiej rozumie sieć, nigdy więcej nie będzie używana, to poleganie na pierwszej literze interfejsu może być świetną szybką i brudną opcją. Jeśli planujesz napisać kolejnego konkurenta do Wireshark lub tcpdump, musisz upewnić się, że masz rację.

A jeśli pisana przez Ciebie aplikacja znajduje się gdzieś pomiędzy tymi skrajnościami, tylko Ty (i Twoi klienci) możesz wiedzieć, jak ostrożnie musisz wdrożyć swoją logikę.

Inni wskazywali już, że nazwy te nigdy nie są wiarygodne z wielu powodów. Ostateczny problem jest bardzo powszechny w oprogramowaniu: założenia zakodowane na stałe zamiast polegać na znanych / udokumentowanych faktach.

Drugi problem, o którym nie wspomniano, opiera się również na założeniu o twoich wymaganiach: lista interfejsów, które chcesz wymienić, to zawsze dokładnie „sprzętowe interfejsy Ethernet” i „interfejsy Wi-Fi”.

Trzecia kwestia to kolejne założenie: że cały interfejs będzie należał do kategorii, o których możesz teraz pomyśleć. Co powiesz na Infiniband, o którym wspomniał @ user4556274? Co powiesz na interfejsy tunelowe dla VPN? Co powiesz na zmostkowane interfejsy? Co powiesz na pomostowe interfejsy łączące interfejsy fizyczne i logiczne?

Ale mogą istnieć opcje, aby osiągnąć to, czego szukasz. Najpierw zdefiniuj dokładnie, co charakteryzuje interfejs, który chcesz wyświetlić, a nie interfejs, którego nie chcesz.

W większości przypadków jedną z cech, na których można polegać, jest tablica routingu (będzie to jednak działać tylko wtedy, gdy interfejs jest włączony, więc może nie być tym, czego tak naprawdę szukasz).

Każdy interfejs, który ma domyślną trasę (tj. Trasę do 0.0.0.0), prawdopodobnie będzie tym, którego szukasz.

Zauważ, że nawet to wciąż opiera się na założeniu, po prostu bardziej niezawodnym: można sobie wyobrazić, że system jest skonfigurowany do kierowania całego ruchu wychodzącego przez maszynę wirtualną lub kontener dokujący (na przykład, jeśli istnieje kontener z zaporą ogniową ). Jest też odwrotnie: administrator systemu może potencjalnie zablokować ruch zewnętrzny, usuwając domyślną trasę.

Inną opcją jest obejście rzeczywistego sprzętu i sprawdzenie, którego sterownika używa. Następnie możesz wykluczyć niektóre dobrze znane sterowniki

Czy wyraźnie wykluczasz interfejsy powiązane lub zespolone? Naszym domyślnym tutaj jest użycie bond0lub team0jako podstawowy interfejs dla naszych serwerów.

Myślę, że musisz przemyśleć swoją logikę. Może spróbuj wykonać iterację przez wszystkie zdefiniowane interfejsy sieciowe w danym systemie, podziel je między ethernet, wifi, infiband, serial itp., A następnie wykonaj swoją magię.

Nie koduj na stałe ani nie dopasowuj wzorca do nazw sprzętowych. Dotyczy to wszystkich urządzeń. Polegaj na narzędziach dostarczonych przez udev, aby określić listę urządzeń i podjąć odpowiednie działania. Zobacz 16.7 Trwałe nazewnictwo urządzeń , a następnie przeczytaj cały ten dokument , w szczególności 16.2 i 16.3. Zauważ, że udev jest agnostyczny dla dystrybucji, a także dla systemu inicjującego, ponieważ udev jest obecnie preferowaną metodą zarządzania urządzeniami w systemie Linux.

Zauważ, że @ user4556274, nawiązał do tego w swojej odpowiedzi, odnosząc się do tego udev-builtin-net-id.c, co w skrócie oznacza, że ​​wzorzec dopasowania, który próbujesz osiągnąć, jest wbudowaną częścią udev.

Cytując PredictableNetworkInterfaceNames :

W systemd 197 dodaliśmy natywną obsługę wielu różnych zasad nazewnictwa do właściwego systemd / udevd i nadaliśmy domyślny schemat podobny do biosdevname (ale ogólnie bardziej wydajny i bliższy wewnętrznym schematom identyfikacji urządzeń jądra). Udev natywnie obsługuje następujące różne schematy nazewnictwa interfejsów sieciowych:

1. Nazwy zawierające numery indeksowe dostarczone przez Firmware / BIOS dla urządzeń pokładowych (przykład: eno1)
2. Nazwy zawierające numery indeksów gniazd hotplug PCI Express podanych w oprogramowaniu układowym / systemie BIOS (przykład: ens1)
3. Nazwy zawierające fizyczne / geograficzne położenie złącza sprzętu (przykład: enp2s0)
4. Nazwy zawierające adres MAC interfejsów (przykład: enx78e7d1ea46da) Klasyczne, nieprzewidywalne nazewnictwo ethX dla jądra (przykład: eth0)

Domyślnie systemd v197 będzie teraz nazywał interfejsy zgodnie z polityką 1), jeśli informacje z oprogramowania wewnętrznego są dostępne i dostępne, cofając się do 2), jeśli te informacje z oprogramowania wewnętrznego są dostępne i dostępne, cofając się do 3), jeśli dotyczy, cofając się do 5) we wszystkich innych przypadkach. Zasada 4) nie jest domyślnie używana, ale jest dostępna, jeśli użytkownik tak wybierze.

Te połączone zasady są stosowane tylko w ostateczności. Oznacza to, że jeśli system ma zainstalowaną nazwę biologiczną, będzie mieć pierwszeństwo. Jeśli użytkownik doda reguły udev, które zmieniają nazwy urządzeń jądra, również one będą miały pierwszeństwo. Ponadto wszelkie schematy nazewnictwa specyficzne dla dystrybucji zwykle mają pierwszeństwo.

Jak powiedzieli inni, nie możesz w pełni polegać na nazwie.

W moim przypadku wydaje się, że dla sieci bezprzewodowej /sys/class/net/<ifacename>/będzie miał katalog o nazwie „bezprzewodowy”, jeśli jest to interfejs bezprzewodowy:

# 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