Đặt tên chuẩn cho giao diện Ethernet và Wi-Fi trên máy Linux

Là gì ước tiêu chuẩn đặt tên cho các giao diện Ethernet và Wi-Fi trên một máy Linux?

Chúng tôi đang phát triển một công cụ chỉ hiển thị giao diện Ethernet và Wi-Fi của máy Linux và trạng thái hiện tại của nó.

Ví dụ, bên dưới là danh sách các giao diện mạng (cả vật lý và ảo) trên máy Linux (Ubuntu) của tôi:

docker0, enp0s25, lo,wlp3s0

Khi tôi chạy công cụ, dưới đây là kết quả tôi nhận được:

enp0s25, wlp3s0

Chúng tôi đã viết mã với logic rằng tất cả các giao diện Ethernet luôn bắt đầu bằng chữ cái evà giao diện Wi-Fi luôn bắt đầu bằng chữ cái w.

Là logic phải không? Nếu không, làm thế nào chúng ta có thể giải quyết điều này?

Giao diện mạng có thể được đặt tên bất cứ điều gì, vì vậy, bất kể bạn làm gì, bạn sẽ gặp phải tình huống trong đó (1) có giao diện mạng "vật lý" với tên không khớp với mẫu của bạn hoặc (2) có một Giao diện mạng "vật lý" sẽ phù hợp với mô hình của bạn.

Trên hết, nếu tôi là người sử dụng công cụ của bạn, thời điểm công cụ của bạn sẽ không cho phép tôi làm điều gì đó tôi muốn, bởi vì tôi có giao diện mạng là "ảo", mặc dù vì mục đích thực tế nên xem xét " vật lý "trong thiết lập của tôi, tôi sẽ bắt đầu chửi rủa ầm ĩ và mạnh mẽ vào ứng dụng của bạn và sẽ không bao giờ sử dụng nó nữa.

Các giao diện mạng vật lý và ảo đều có chung một API chung là một điều giúp Linux thực sự linh hoạt. Vui lòng không cố gắng giữ trẻ người dùng của bạn và tránh xa người đó. Người dùng của bạn sẽ cảm ơn bạn.

Đối với tên giao diện có thể dự đoán systemd , có thể thấy các tiền tố trong 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

như vậy cho cả các truyền thống ethXphong cách đặt tên và đặt tên systemd mới hơn, một bức thư ban đầu e phải là một giao diện Ethernet cho bất kỳ tên giao diện tự động tạo ra. Tất cả các giao diện wifi nên bắt đầu bằng một w trong cả hai sơ đồ, mặc dù không phải tất cả các giao diện bắt đầu bằng w sẽ là wifi.

Nếu công cụ này phải làm việc trong một môi trường tùy ý (chứ không phải chỉ trên môi trường nội bộ mà bạn kiểm soát), lưu ý rằng người dùng có thể đổi tên giao diện trên các hệ thống Linux với tên tùy ý, chẳng hạn như [ wan0, lan0, lan1, dmz0] mà sẽ phá vỡ bất kỳ giả định về chữ ban đầu .

Quy ước đặt tên là giao diện mạng LAN được đặt tên eth0, eth1... và các giao diện mạng WLAN được đặt tên wlan0, wlan1...

Những gì bạn thấy là cái gọi là "tên dự đoán" mà systemd đã giới thiệu. Trong thực tế, chúng là bất cứ thứ gì ngoài dự đoán và thậm chí chúng có thể thay đổi khi phần cứng bị thay đổi, đó chính xác là vấn đề mà chúng cần phải tránh.

Để đoán chữ cái bắt đầu có thể là đủ tốt. Một số giao diện, đặc biệt là mạng WLAN, có gợi ý về /sys/class/net/*/uevent:

DEVTYPE=wlan

Thật không may, không có như vậy DEVTYPEcho các giao diện LAN.

Một lời cảnh báo với câu trả lời của tôi (cũng áp dụng cho hầu hết những người khác): Tôi không biết mục đích của ứng dụng của bạn. Nếu đó là một ứng dụng vứt đi để khắc phục một sự cố cụ thể hoặc để hiểu rõ hơn về mạng, không bao giờ được sử dụng lại, thì việc dựa vào chữ cái đầu tiên của giao diện có thể là một lựa chọn nhanh chóng và bẩn thỉu. Nếu bạn đang dự định viết đối thủ cạnh tranh tiếp theo cho Wireshark hoặc tcpdump, bạn cần chắc chắn rằng bạn đã làm đúng cho tất cả các loại trường hợp cạnh.

Và nếu ứng dụng bạn đang viết nằm ở đâu đó giữa những thái cực đó, chỉ có bạn (và khách hàng của bạn) có thể biết bạn cần cẩn thận đến mức nào để thực hiện logic của mình.

Những người khác đã chỉ ra rằng những cái tên không bao giờ đáng tin cậy, vì bất kỳ lý do nào. Vấn đề cuối cùng là một vấn đề rất phổ biến trong phần mềm: các giả định mã hóa cứng thay vì dựa vào các sự kiện đã biết / được ghi lại.

Vấn đề thứ hai chưa được đề cập cũng dựa trên giả định về yêu cầu của bạn: danh sách các giao diện bạn muốn liệt kê luôn chính xác là "giao diện ethernet phần cứng" và "giao diện wifi".

Vấn đề thứ ba là một giả định khác: tất cả giao diện sẽ rơi vào danh mục bạn có thể nghĩ ra ngay bây giờ. Còn Infiniband, như được đề cập bởi @ user4556274 thì sao? Làm thế nào về giao diện đường hầm cho VPN? Làm thế nào về giao diện cầu nối? Làm thế nào về giao diện cầu nối kết hợp giao diện vật lý và logic?

Nhưng có thể có các lựa chọn để thực hiện những gì bạn đang tìm kiếm. Đầu tiên, xác định chính xác những gì đặc trưng cho một giao diện bạn muốn liệt kê, so với giao diện mà bạn không liệt kê.

Trong hầu hết các trường hợp, một đặc điểm bạn có thể dựa vào là bảng định tuyến (tuy nhiên, điều này sẽ chỉ hoạt động miễn là giao diện được bật lên, vì vậy nó có thể không phải là thứ bạn đang thực sự tìm kiếm).

Bất kỳ giao diện nào có tuyến mặc định (nghĩa là tuyến đến 0.0.0.0) có thể là giao diện bạn đang tìm kiếm.

Lưu ý rằng ngay cả điều này vẫn dựa trên một giả định, chỉ là một điều đáng tin cậy hơn: có thể hiểu rằng một hệ thống được cấu hình để định tuyến tất cả lưu lượng truy cập đi qua một máy ảo hoặc thùng chứa docker (ví dụ: nếu có một container chạy tường lửa ). Và điều ngược lại cũng đúng: một sysadmin có khả năng khóa lưu lượng bên ngoài bằng cách xóa tuyến đường mặc định.

Một lựa chọn khác là đi bằng phần cứng thực tế và xem nó sử dụng trình điều khiển nào. Sau đó, bạn có thể loại trừ một số trình điều khiển nổi tiếng nhất định

Bạn rõ ràng không bao gồm các giao diện ngoại quan hoặc nhóm? Mặc định của chúng tôi ở đây là sử dụng bond0hoặc team0cho giao diện chính cho các máy chủ của chúng tôi.

Tôi nghĩ bạn cần phải suy nghĩ lại logic của bạn. Có thể thử lặp lại mặc dù tất cả các giao diện mạng được xác định trên một hệ thống nhất định, phân chia chúng giữa ethernet, wifi, infiband, serial, v.v., và sau đó thực hiện phép thuật của bạn.

Không mã hóa cứng, hoặc mẫu khớp với tên phần cứng. Điều này áp dụng cho tất cả các thiết bị. Dựa vào các công cụ được cung cấp bởi udev để xác định danh sách các thiết bị và thực hiện hành động thích hợp. Xem 16.7 Đặt tên thiết bị liên tục , sau đó đọc toàn bộ tài liệu đó , cụ thể là 16.2 và 16.3. Lưu ý rằng udev là bất khả tri phân phối, và cũng là bất khả tri của hệ thống, vì udev hiện là phương pháp ưa thích để quản lý thiết bị trong linux.

Lưu ý rằng @ user4556274, đã ám chỉ điều này trong câu trả lời của anh ấy khi đề cập đến udev-builtin-net-id.c, điều này có nghĩa ngắn gọn là mẫu phù hợp với bạn đang cố gắng thực hiện là một phần dựng sẵn udev.

Trích dẫn Dự đoánNetworkInterfaceNames :

Với systemd 197, chúng tôi đã thêm hỗ trợ riêng cho một số chính sách đặt tên khác nhau vào systemd / udevd phù hợp và thực hiện một sơ đồ tương tự như biosdevname (nhưng nói chung mạnh hơn và gần hơn với các lược đồ nhận dạng thiết bị bên trong kernel). Các lược đồ đặt tên khác nhau sau đây cho giao diện mạng hiện được hỗ trợ bởi udev:

1. Tên kết hợp Firmware / BIOS cung cấp số chỉ mục cho các thiết bị trên máy bay (ví dụ: eno1)
2. Các tên kết hợp Firmware / BIOS được cung cấp số chỉ mục khe cắm cắm nóng PCI Express (ví dụ: ske1)
3. Tên kết hợp vị trí vật lý / địa lý của đầu nối của phần cứng (ví dụ: enp2s0)
4. Các tên kết hợp địa chỉ MAC của giao diện (ví dụ: enx78e7d1ea46da) Đặt tên ethX gốc nhân, không thể đoán trước (ví dụ: eth0)

Theo mặc định, systemd v197 hiện sẽ đặt tên cho các giao diện theo chính sách 1) nếu thông tin từ phần sụn được áp dụng và có sẵn, giảm xuống 2) nếu thông tin đó từ phần sụn có thể áp dụng và có sẵn, giảm xuống 3) nếu có thể, quay lại đến 5) trong tất cả các trường hợp khác. Chính sách 4) không được sử dụng theo mặc định, nhưng có sẵn nếu người dùng chọn như vậy.

Chính sách kết hợp này chỉ được áp dụng như là phương sách cuối cùng. Điều đó có nghĩa là, nếu hệ thống đã cài đặt tên miền sinh học, nó sẽ được ưu tiên. Nếu người dùng đã thêm các quy tắc udev thay đổi tên của các thiết bị kernel thì chúng cũng sẽ được ưu tiên. Ngoài ra, bất kỳ kế hoạch đặt tên cụ thể phân phối thường được ưu tiên.

Như những người khác đã nói bạn không thể hoàn toàn phụ thuộc vào tên.

Trong trường hợp của tôi, dường như đối với không dây /sys/class/net/<ifacename>/sẽ có một thư mục gọi là "không dây" trong đó nếu đó là giao diện không dây:

# 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