web-dev-qa-db-ja.com

LinuxマシンのイーサネットおよびWi-Fiインターフェースの命名規則標準

LinuxマシンのEthernetおよびWi-Fiインターフェイスの命名規則標準とは何ですか？

LinuxマシンのイーサネットおよびWi-Fiインターフェイスとその現在のステータスのみを表示するツールを開発しています。

たとえば、以下は、Linux（Ubuntu）マシンのネットワークインターフェイス（物理および仮想の両方）のリストです。

docker0、enp0s25、lo、wlp3s0

ツールを実行すると、次のような結果になります。

enp0s25、wlp3s0

すべてのイーサネットインターフェイスは常にeで始まり、Wi-Fiインターフェイスは常にwで始まるというロジックでコードを記述しました。

論理は正しいですか？そうでない場合、どうすればこれに対処できますか？

networkingwifinetwork-interfaceethernet
12
Mohan Raj

ネットワークインターフェースには任意の名前を付けることができるため、何をしても、（1）パターンと一致しない名前の「物理」ネットワークインターフェースが存在する、または（2）パターンに一致する「物理」ネットワークインターフェイス。

その上、私があなたのツールのユーザーであった場合、私が「仮想」であるネットワークインターフェースを持っているため、あなたのツールが私にやりたいことを許可しない瞬間です。私の設定では、私はあなたのアプリで大声でそして力強く呪い始めます、そしてそれを二度と使用しません。

物理および仮想ネットワークインターフェイスはすべて共通のAPIを共有しているため、Linuxは非常に柔軟になっています。ユーザーのベビーシッターを行わないでください。ユーザーから離れてください。あなたのユーザーはあなたに感謝します。

40
dirkt

Systemd 予測可能なインターフェース名 の場合、プレフィックスは 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は、自動的に生成されるインターフェース名のイーサネットインターフェースにする必要があります。 wで始まるすべてのインターフェースがwifiになるわけではありませんが、すべてのwifiインターフェースは両方のスキームでwで始まる必要があります。

このツールが（制御する内部環境だけでなく）任意の環境で動作する必要がある場合、ユーザーはLinuxシステムのインターフェイスの名前を[wan0、lan0、 lan1、dmz0]は、最初の文字に関するすべての仮定を破ります。

27
user4556274

命名規則では、LANインターフェイスの名前はeth0、eth1、...、およびそのWLANインターフェイスの名前はwlan0、wlan1、...

あなたが見るものは、systemdが導入したいわゆる「予測可能な名前」です。実際には、これらは予測可能ではなく、ハードウェアが変更されたときにも変更される可能性があり、これはまさに回避すべき問題です。

推測では、開始文字で十分な場合があります。一部のインターフェイス、特にWLANでは、/sys/class/net/*/uevent：

DEVTYPE=wlan

残念ながら、LANインターフェースにはそのようなDEVTYPEはありません。

8
RalfFriedl

私の答えの1つの警告（他のほとんどにも当てはまります）：アプリケーションの目的がわかりません。特定の問題のトラブルシューティングやネットワークの理解を深めるための使い捨てのアプリケーションである場合は、二度と使用しないでください。インターフェイスの最初の文字を信頼するのは、素早い、汚いオプションかもしれません。次のライバルをWiresharkまたはtcpdumpに書き込むことを計画している場合は、あらゆる種類のEdgeケースに正しく対応できるようにする必要があります。

そして、あなたが書いているアプリケーションがこれらの両極端の間のどこかにある場合、あなた（そしてあなたの顧客）だけがあなたがあなたのロジックを実装する必要があるか注意深く知ることができます。

他の人はすでに、名前が信頼できるものではないことを、さまざまな理由で指摘しています。究極の問題はソフトウェアで非常に一般的な問題です。既知の/文書化された事実に依存するのではなく、ハードコーディングの前提です。

言及されていない2番目の問題も、要件に関する仮定に基づいています。リストするインターフェースのリストは常に正確に「ハードウェアイーサネットインターフェース」と「wifiインターフェース」であるということです。

3番目の問題は、さらに別の仮定です。すべてのインターフェイスが、今考えられるカテゴリに分類されるということです。 @ user4556274が述べたInfinibandはどうですか？ VPNのトンネルインターフェイスはどうですか？ブリッジされたインターフェースはどうですか？物理インターフェイスと論理インターフェイスを組み合わせるブリッジインターフェイスはどうでしょうか。

しかし、あなたが探しているものを達成するためのオプションがあるかもしれません。まず、リストしたいインターフェースとそうでないインターフェースの特徴を正確に定義します。

ほとんどの場合、信頼できる特性の1つはルーティングテーブルです（ただし、これはインターフェイスが起動している間のみ機能するため、実際に探しているものとは異なる場合があります）。

デフォルトルート（つまり、0.0.0.0へのルート）を持つインターフェイスは、おそらく探しているものです。

これはまだ前提に基づいていますが、より信頼性の高いものです。システムが仮想マシンまたはDockerコンテナーを介してすべての送信トラフィックをルーティングするように構成されていると考えられます（たとえば、ファイアウォールを実行しているコンテナーがある場合） ）。また、その逆も当てはまります。システム管理者は、デフォルトルートを削除することにより、外部トラフィックをロックする可能性があります。

別のオプションは、実際のハードウェアを調べて、それが使用するドライバーを確認することです。次に、特定の有名なドライバーを除外できます

5
Kevin Keane

結合またはチーム化されたインターフェースを明示的に除外していますか？ここでのデフォルトは、サーバーのプライマリインターフェイスにbond0またはteam0を使用することです。

ロジックを再考する必要があると思います。特定のシステムで定義されているすべてのネットワークインターフェイスを反復処理し、それらをイーサネット、wifi、infiband、シリアルなどに分割して、魔法をかけてみてください。

4
doneal24

ハードコードやハードウェア名のパターンマッチングは行わないでください。これはすべてのデバイスに適用されます。 udevが提供するツールを使用して、デバイスのリストを決定し、適切なアクションを実行します。 16.7 Persistent Device Naming を参照してから、その ドキュメント全体 、特に16.2と16.3を参照してください。 udevはLinuxでのデバイス管理に推奨される方法であるため、udevはディストリビューションに依存せず、initシステムにも依存しないことに注意してください。

@ 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ルールを追加した場合、これらも優先されます。また、ディストリビューション固有の命名スキームは一般に優先されます。

3
eyoung100

他の人が言っているように、名前に完全に依存することはできません。

私の場合、それはseemsワイヤレスの場合/sys/class/net/<ifacename>/がワイヤレスインターフェースの場合、その中に「wireless」というディレクトリがあります。

# 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
2
Kyle Brandt