Linux makinelerde Ethernet ve Wi-Fi arayüzleri için adlandırma kuralı standardı

12

Bir Linux makinesinde Ethernet ve Wi-Fi arayüzleri için adlandırma kuralı standardı nedir ?

Linux makinesinin yalnızca Ethernet ve Wi-Fi arayüzlerini ve mevcut durumunu göstermesi gereken bir araç geliştiriyoruz .

Örneğin, Linux (Ubuntu) makinemdeki ağ arabirimlerinin (hem fiziksel hem de sanal) listesi aşağıdadır:

docker0, enp0s25, lo,wlp3s0

Aracı çalıştırdığımda, elde ettiğim sonuç aşağıdadır:

enp0s25, wlp3s0

Kodu, tüm Ethernet arabirimlerinin her zaman harfle başladığını eve Wi-Fi arabirimlerinin her zaman harfle başladığını mantıkla yazdık w.

Mantık doğru mu? Değilse, bunu nasıl ele alabiliriz?

— Mohan Raj
kaynak

ilgili: unix.stackexchange.com/a/179931/117549

— Jeff Schaller

iwconfigWiFi arayüzlerini diğerlerinden nasıl filtrelediğine bakarım .

— Patrick Mevzek

1

Lshw gibi bir şeye bakmamanızın bir nedeni var mı? Özellikle içeriğini incelemek lshw -class networkbelki? Olan her şeyi capabilities: ethernet physicalmi arıyorsunuz? Muhtemelen diğer bazı yetenekleri mi arıyorsunuz?

— Zoredache

@Dirkt tarafından ortaya çıkarılan çerçeve sorunuyla başa çıkmak için daha iyi bir soru şöyle olacaktır: "Linux'ta (veya macOS veya diğer ...) bir ağ arabirimi türünü nasıl edinebilirim?"

— Roger Lipscombe

40

Ağ arabirimleri herhangi bir şey olarak adlandırılabilir, bu nedenle ne yaparsanız yapın, (1) kalıbınızla eşleşmeyen bir adla "fiziksel" bir ağ arabiriminin olduğu veya (2) Kalıbınıza uyan "fiziksel" ağ arayüzü.

Bunun da ötesinde, aracınızın bir kullanıcısı olsaydım, aracınızın istediğim bir şeyi yapmama izin vermediği an, çünkü "sanal" bir ağ arayüzüne sahibim, ancak pratik amaçlar için " fiziksel "olarak ayarladım.

Fiziksel ve sanal ağ arayüzlerinin hepsi ortak bir API'yı paylaşıyor, Linux'u gerçekten esnek kılan bir şey. Lütfen kullanıcısına bakmaya çalışmayın ve onu ondan uzaklaştırın. Kullanıcılarınız size teşekkür edecek.

— dirkt
kaynak

11

Soruyu aslında cevaplamadınız; sorunun arka plan içeriğine meydan okuyan 3 paragraf geçirdiniz. Çerçeve meydan cevaplarının bir şey olduğunun farkında olduğum halde , bu durumlardan biri gibi hissetmiyorum ... özellikle user4556274 , sorulduğu gibi soruya özlü bir cevap verdiğinden.

— Mike Ounsworth

18

@MikeOunsworth: Sorun şu ki, user4556274'ün yanıtı genel durumda çalışmaz, yalnızca arabirim adları gerçekten öngörülebilir arabirim adlarıysa çalışır. Hangi basit ip link set ... name ...değişebilir. Ve evet, tahmin edilebilir arayüz adlarını kendim listeleyebilirdim. Orijinal sorunun cevabı "lütfen bu şekilde yapma". Çünkü nasıl giderseniz gidin, işe yaramaz.

— dirkt

@ fpmurphy1 Hayır, sanırım tahmin edilebilir arabirim adları anlamına geliyor. Sistemd, geleneksel (ethN), şirketinizin özel sözleşmeleri veya adları öngörülebilir yapan diğer standartlar önemli değil

— Slebetman

12

@MikeOunsworth: Cevap ilk paragrafın ilk cümlesinin ilk alt maddesinde: "Ağ arayüzlerine herhangi bir ad verilebilir […]" Bu nedenle OP'nin sorduğu şey imkansızdır ve muhtemelen yapılamaz . Bir adlandırma kuralı standardına göre bir ağ arabirimi türünü algılayamazsınız, çünkü bir adlandırma kuralı standardı yoktur ve herkes arabirimlerini istediği her şeyi adlandırabilir. Örneğin, benim eski Linux yönlendirici, ben arkasında renkli çıkartmalar baş ve fiziksel Ethernet arayüzleri seçildiler red, blueve green.

— Jörg W Mittag

1

@ JörgWMittag, eğer standardın kullanıldığını biliyorsanız (ve ilk etapta bu bilgileri veren bir bilgi bekliyorsanız) , bunları bir standarda göre tespit edebilirsiniz . Systemd'in ağ arabirimi adlandırma için bir standardı olduğunu biliyoruz , bu yüzden birinin olmadığını söylemek işe yaramaz.

— ilkkachu

27

Sistem öngörülebilir arabirim adları için önekler şu adreste görülebilir 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

bu nedenle hem geleneksel ethXadlandırma stili hem de daha yeni systemd adlandırma için, ilk e harfi otomatik olarak oluşturulan arabirim adları için bir ethernet arayüzü olmalıdır. Tüm wifi arayüzleri bir başlamalıdır w tüm arabirimler ile başlayan rağmen, her iki şemalarında w wifi olacaktır.

Bu araç, kullanıcıların [olarak keyfi isimlerle birlikte Linux sistemlerinde arayüzleri adlandırmak olabileceğini not (yalnızca iç kontrol ortamlarında yerine) keyfi bir ortamda çalışmalarına varsa wan0, lan0, lan1, dmz0] başlangıç harfleri hakkında herhangi bir varsayım kıracak olan .

— user4556274
kaynak

7

Ve bazılarımız sadık sistemd refuseniks.

— chrylis -on strike-

1

Bu çözümün, biosdevnameEthernet arabirimi gibi adlandırılabilecek arabirim adlandırma için kullanılan sistemlerde çalışmadığını unutmayın p3p7. Bu yöntem, yeni systemd öngörülebilir adlarının öncüsüdür ve şimdi yaygın dağıtımlarda kullanımdan kaldırılmasına rağmen, birkaç yıl önce varsayılan olduğunda onu alan birçok sistem hala olacaktır.

— TooTea

systemd, ethernet arayüzlerimden birini 'rename3' olarak çağırıyor. Hangisi değişebilir, iç

— çeker

1

@ user1908704: Bu genellikle udev'in aynı adı birden çok arabirime vermesi söylendi. Yani, yeniden adlandırma işlemi giderilmiştir söyledi (Belki? /Etc/udev/rules.d eski bir otomatik oluşturulmuş "kalıcı isimler" dosyasına sahip) v187 içinde (ya başarılı ya da geri alma) tamamen atomik olmak ve rename%u'biçim değişmedi t 2012 yılından bu yana kaynak kodunda mevcuttu. Yazılımınızın altı yıl eski olduğunu görmek istiyorum.

— user1686

1

@grawity Bu Ubuntu 18.04. Belirli anakartların aynı ACPI girişine sahip iki NIC'si olduğu ve her ikisinin de eno1 olduğu ortaya çıkıyor. Bu yapılamayacağı için bunlardan birine 'rename3' denir. Yarışı kimin kazandığının mantığını tam olarak anlamadım, ancak herhangi bir değişiklik yarışmayı bozabilir ve diğerinin yeniden adlandırılmasına neden olabilir3.

— user1908704

8

Adlandırma kuralı LAN arayüzleri isimlerinden oluşması eth0, eth1WLAN arayüzleri adlandırılır ... ve bu wlan0, wlan1...

Gördüğünüz şey, sistemd'in tanıttığı "öngörülebilir isimler" dir. Uygulamada, öngörülebilir olmaktan başka bir şeydir ve donanım değiştirildiğinde bile değişebilirler, bu da kaçınmaları gereken problemdir.

Bir tahmin için başlangıç mektubu yeterince iyi olabilir. Bazı arayüzler, özellikle WLAN, aşağıdakilerle ilgili ipuçları içerir /sys/class/net/*/uevent:

DEVTYPE=wlan

Ne yazık ki, DEVTYPELAN arabirimleri için böyle bir şey yoktur .

— RalfFriedl
kaynak

2

Donanım değişikliği sorun olmadığında aygıt adı değişebilir tahmin edilebilir arabirim adları kaçınmaya çalışıyor. Öngörülebilir arabirim adları, donanım değiştirilmediğinde ad değişikliklerini önler . Donanım aygıtları rasgele bir sırayla algılandığında bu bir sorundur.

— Johan Myréen

@ JohanMyréen Bu yanlış: "... donanım eklenmiş veya kaldırılmış olsa bile (arabirim adı) sabit

— kalıyor

Öngörülebilir arabirim adlarını tanıtmak için motivasyon, araştırmanın deterministik olmaması ve "isimler" eth0 "," eth1 "ve benzeri isimlerin artık atanmaması ve bir önyüklemedeki" eth0 "ın "eth1" bir sonraki. " Öngörülebilir isimlerin donanım değişikliklerinde hayatta kalabilmesi bir bonus, ancak bu onların birincil nedeni değildi.

— Johan Myréen

1

Bazılarını biraz kazanın - bazı senaryolarda, değiştirilen donanımın aynı "adlandırma yuvasına" güvenilir bir şekilde tıklanması çok arzu edilir :)

— rackandboneman

@ JohanMyréen MAC veya diğer bazı özelliklere dayalı arabirim adları atamanın eski şeması, arayüz eklerken yeni adların zahmetine girmeden daha güvenilir çalıştı.

— RalfFriedl

5

Cevabımla birlikte bir uyarı (diğerlerinin çoğu için de geçerlidir): Başvurunuzun amacını bilmiyorum. Belirli bir sorunu gidermek ya da ağları daha iyi anlamak, asla tekrar kullanılmayacak bir uygulama ise, arabirimin ilk harfine güvenmek hızlı ve kirli bir seçenek olabilir. Bir sonraki rakibi Wireshark veya tcpdump'a yazmayı planlıyorsanız, her türlü kenar durumu için doğru aldığınızdan emin olmanız gerekir.

Ve yazdığınız uygulama bu uç noktalar arasında bir yere düşerse, sadece siz (ve müşterileriniz) mantığınızı ne kadar dikkatli uygulamanız gerektiğini bilebilirsiniz.

Diğerleri, isimlerin hiçbir nedenle güvenilir olmadığını zaten belirtti. Nihai sorun yazılımda çok yaygın bir sorundur: bilinen / belgelenen gerçeklere dayanmak yerine kodlama varsayımları.

Daha önce değinilmeyen ikinci konu da gereksinimlerinizle ilgili bir varsayımdır: listelemek istediğiniz arabirimler listesinin her zaman tam olarak "donanım ethernet arabirimleri" ve "wifi arabirimleri" olmasıdır.

Üçüncü konu yine bir başka varsayımdır: tüm arayüzün şu anda aklınıza gelebilecek kategorilere gireceği. @ User4556274 tarafından belirtildiği gibi Infiniband'a ne dersiniz? Bir VPN için tünel arayüzlerine ne dersiniz? Köprülü arayüzlere ne dersiniz? Fiziksel ve mantıksal arayüzleri birleştiren köprülü arayüzlere ne dersiniz?

Ancak aradığınızı gerçekleştirmek için seçenekler olabilir. İlk olarak, listelemek istediğiniz bir arabirimi tam olarak neyi karakterize edeceğinizi tanımlayın.

Çoğu durumda, güvenebileceğiniz bir özellik yönlendirme tablosudur (ancak, bu yalnızca arabirim açık olduğu sürece çalışır, bu yüzden gerçekten aradığınız şey olmayabilir).

Varsayılan bir rotayı (yani 0.0.0.0'a giden bir yolu) olan herhangi bir arabirimin aradığınız bir arayüz olması muhtemeldir.

Bunun hala bir varsayımı temel aldığını, sadece daha güvenilir bir varsayımı temel aldığını unutmayın: bir sistemin tüm giden trafiği sanal bir makine veya bir yükleme istasyonu konteyneri üzerinden yönlendirecek şekilde yapılandırılması düşünülebilir (örneğin, bir güvenlik duvarı çalıştıran bir kap varsa) ). Ve bunun tersi de doğrudur: bir sysadmin, varsayılan rotayı silerek potansiyel olarak dış trafiği kilitleyebilir.

Başka bir seçenek, gerçek donanımdan geçip hangi sürücüyü kullandığını görmektir. Daha sonra, bazı tanınmış sürücüleri hariç tutabilirsiniz

— Kevin Keane
kaynak

4

Bağlı veya takımlanmış arayüzleri açıkça hariç tutuyor musunuz? Burada varsayılanımız sunucularımız için bond0veya team0birincil arayüz kullanmaktır .

Bence mantığını yeniden düşünmen gerekiyor. Belli bir sistemdeki tüm tanımlı ağ arayüzleri üzerinden yinelemeyi deneyin, bunları ethernet, wifi, infiband, seri vb. Arasında bölün ve ardından sihrinizi yapın.

— doneal24
kaynak

3

Donanım kodlarıyla sabit kod kullanmayın veya desen eşleşmeyin. Bu, tüm cihazlar için geçerlidir. Aygıtların listesini belirlemek ve uygun işlemi yapmak için udev tarafından sağlanan araçlara güvenin. Bkz. 16.7 Kalıcı Cihaz Adlandırma ve ardından tüm belgeyi okuyun , özellikle 16.2 ve 16.3. Udev, dağıtım agnostik ve ayrıca sistem agnostik init olduğunu unutmayın, çünkü udev artık linux'da cihaz yönetimi için tercih edilen yöntemdir.

@ User4556274, atıfta bulunurken cevabında buna işaret ettiğine dikkat edin udev-builtin-net-id.c, bu da kısaca gerçekleştirmeye çalıştığınız desen eşleşmesinin yerleşik bir parçası olduğu anlamına gelir udev.

Son teklif PredictableNetworkInterfaceNames :

Systemd 197 ile systemd / udevd'e uygun bir dizi farklı adlandırma ilkesi için yerel destek ekledik ve biosdevname'lerinkine (ama genellikle daha güçlü ve çekirdek-dahili aygıt tanımlama şemalarına daha yakın) benzer bir şema oluşturduk. Ağ arabirimleri için aşağıdaki farklı adlandırma şemaları artık yerel olarak udev tarafından desteklenmektedir:

Bellenim / BIOS içeren adlar, yerleşik aygıtlar için dizin numaraları sağladı (örnek: eno1)

Bellenim / BIOS içeren adlar PCI Express hotplug yuvası dizin numaralarını sağlamıştır (örnek: ens1)

Donanımın bağlayıcısının fiziksel / coğrafi konumunu içeren adlar (örnek: enp2s0)

Arayüzlerin MAC adresini içeren isimler (örnek: enx78e7d1ea46da) Klasik, öngörülemeyen çekirdek-yerel ethX adlandırma (örnek: eth0)

Varsayılan olarak, systemd v197 artık politika 1) 'e göre arayüzleri isimlendirecektir) eğer bellenimden gelen bilgiler uygulanabilir ve mevcutsa, 2'ye geri dönüyorsa) bellenimdeki bilgiler uygulanabilir ve mevcutsa, 3'e düşüyorsa) 5) diğer tüm durumlarda. Politika 4) varsayılan olarak kullanılmaz, ancak kullanıcı bunu seçerse kullanılabilir.

Bu birleşik politika yalnızca son çare olarak uygulanır. Bu, sistemde biosdevname kurulu ise, öncelikli olacağı anlamına gelir. Kullanıcı, çekirdek aygıtlarının adını değiştiren udev kuralları eklediyse bunlar da öncelik kazanacaktır. Ayrıca, dağıtıma özgü adlandırma şemaları genellikle önceliklidir.

— eyoung100
kaynak

2

Diğerlerinin söylediği gibi, isme tam olarak güvenemezsiniz.

Benim durumumda görünüyor kablosuz için bu /sys/class/net/<ifacename>/bir kablosuz arayüz ise bir dizin içinde "kablosuz" olarak adlandırılan olacaktır:

# 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

— Kyle Brandt
kaynak