Linuxカーネルネットワーク機能タイムライン

Linuxのネットワーキングは、個別のサブシステムリリースではなく、メインラインの段階的なリリースによって進化します。以下のマイルストーンは、各機能を含む最初の安定版カーネルを示します。後続のカーネルでは、プロトコルの対応範囲、ドライバー、オフロード、またはユーザー空間インターフェースが追加されている場合があります。

ネットワーク機能のクイックファクト #

リリース日はLinuxカーネルGit履歴のメインラインタグに従っています。機能のバージョンは、KernelNewbiesのリリース概要とカーネルネットワーキング文書で相互参照しています。

カーネルとユーザー空間の境界 #

Linuxにはadd_route()やcreate_veth()のようなシステムコールはありません。代わりに、ユーザー空間はカーネル制御インターフェースを選択し、汎用システムコールを介してアクセスします。特にNetlinkは、システムコールではなく、ソケットプロトコルのファミリーです。

ほとんどの管理操作では、対象ネットワーク名前空間を管理するユーザー名前空間内のCAP_NET_ADMINが必要です。eBPF操作では、プログラムの種類、アタッチポイント、カーネルバージョンに応じて、CAP_BPF、CAP_PERFMON、またはその他のケーパビリティも必要になる場合があります。

推奨インターフェースの変化 #

1. 初期のLinuxではioctl、ソケットオプション、仮想ファイルが使用されていました。 ifconfig、route、arpなどのプログラムは、ネットワークデバイスおよびルーティングioctlを発行していました。/proc/sys/netはグローバルなチューナブルを提供し、旧来のiptablesによるファイアウォール世代ではプロトコル固有のソケットオプションが使用されていました。
2. Rtnetlinkが拡張可能なネットワーク制御プレーンになりました。 Linux 2.2は、NETLINK_ROUTEを介してリンク、複数のアドレス、ルート、近隣、トラフィック制御オブジェクトを公開しました。そのため、iproute2ツール（ip、bridge、tc）は、新しい設定においてioctl指向のnet-toolsコマンドを置き換えました。
3. サブシステム固有のNetlinkファミリーが固定プライベートABIを置き換えました。 Generic Netlinkおよび関連プロトコルによって、システムコールを変更せずにコマンドとtype-length-value属性を進化させられるようになりました。nl80211はWireless Extensionsを、nftablesは旧来のiptablesルールABIを置き換え、新しいethtool操作ではデバイスioctlではなくNetlinkが使用されます。
4. eBPFがプログラム可能なデータプレーン境界を追加しました。 bpf()システムコールはプログラムとマップを管理しますが、設定はアタッチポイントごとに分かれています。rtnetlinkはトラフィック制御と既存のXDPアタッチメントを設定し、ソケットオプションは従来のソケットフィルターをアタッチし、BPFリンクは対応するフックに対してファイルディスクリプターによる有効期間管理を提供します。
5. 新しい制御プレーンは記述されたNetlink APIを優先します。 現在のカーネルネットワーキング開発では、機械可読な仕様によってNetlinkファミリーを文書化しています。アプリケーションはこれらのAPIを使用し、確認応答と拡張確認応答を要求し、対応する構造化された代替がないインターフェースに限ってioctlまたはテキストファイル解析を使用すべきです。

対応するUAPIの詳細については、カーネルのNetlink入門、rtnetlink(7)、netdevice(7)、bpf(2)ドキュメントを参照してください。

Rtnetlink #

rtnetlinkのrtはroutingを意味しますが、このインターフェースはカーネルの汎用ネットワーク制御プロトコルへと拡張されています。プロセスはsocket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE)を開き、RTM_*メッセージを送信します。各メッセージには、struct nlmsghdr、オブジェクト固有の固定ヘッダー、アラインメントされたtype-length-value属性が含まれます。

Rtnetlinkは、次の3種類のやり取りをサポートします。

• Do request: 1つのオブジェクトを作成、置換、変更、削除し、確認応答を受信します。
• Dump request: すべてのリンクやすべてのルートなど、オブジェクトクラスを列挙します。カーネルはNLMSG_DONEで終了するマルチパート応答を返します。
• Multicast notification: リンク、アドレス、ルート、近隣、ルール、トラフィック制御などの変更についてグループを購読します。通知では返信と同じオブジェクトメッセージを使用するため、プログラムはローカルキャッシュを維持できます。

管理対象オブジェクト #

RTM_NEW*は常に「新規作成のみ」を意味するわけではありません。フラグが変更の意味を決定します。

アプリケーションはNETLINK_EXT_ACKも有効にすべきです。拡張確認応答は、拒否された属性を特定し、人間が読めるカーネルメッセージを含め、ポリシー制約を報告できます。成功した確認応答は、カーネルがそのメッセージを処理したことを意味しますが、個別のrtnetlink要求のシーケンスがトランザクショナルになることは意味しません。

名前空間と一貫性モデル #

rtnetlinkソケットは、それが関連付けられているネットワーク名前空間で動作します。そのため、ほとんどの要求は、その名前空間のリンク、ルート、ルール、近隣、トラフィック制御オブジェクトだけを参照および変更します。リンク属性によってデバイスを別の名前空間に移動でき、名前空間IDメッセージによってピア名前空間への参照を作成できます。

変更要求では通常、対象ネットワーク名前空間を所有するユーザー名前空間内のCAP_NET_ADMINが必要です。機密性のあるデバイスまたはプロトコル情報を公開する読み取り要求も制限される場合があります。

ダンプはアトミックなスナップショットではありません。マルチパートダンプの進行中にオブジェクトが変更される可能性があり、受信バッファーがオーバーフローするとマルチキャスト通知が失われる場合があります。状態同期器は次の処理を行うべきです。

1. 必要なマルチキャストグループにソケットを開いてバインドします。
2. 一意のシーケンス番号でダンプを要求します。
3. シーケンス番号と送信元ポートIDによってユニキャスト返信を照合します。
4. ダンプ中に到着した通知を処理します。
5. ENOBUFS、中断されたダンプ、不正な属性を検出します。
6. 同期を証明できない場合はキャッシュを破棄し、ダンプを再実行します。

スコープの境界 #

Rtnetlinkはネットワークトポロジー、アドレス指定、転送、近隣、トラフィック制御を管理しますが、すべてのネットワークサブシステム向けのインターフェースではありません。

権威ある操作一覧はinclude/uapi/linux/rtnetlink.hで定義されています。カーネルは、リンク、アドレス、ルート、ルール、近隣、トラフィック制御向けの機械可読仕様も公開しています。高水準プログラムでは、UAPI構造体のレイアウトと属性検証を手作業で再現するのではなく、保守されているライブラリまたはiproute2を使用すべきです。

ユーザー空間ネットワークユーティリティ #

Linuxには、単一のユーザー空間ネットワークスタックはありません。コマンドラインツール、ポリシーデーモン、設定レンダラー、ルーティングデーモン、コンテナプラグインは、異なるカーネル制御インターフェースにアクセスします。そのため、高水準コマンドはカーネルではなくデーモンを制御する場合があります。

制御と依存関係の経路 #

矢印はパッケージの所有関係ではなく、実行時の制御フローを表します。NETLINK_ROUTE、NETLINK_NETFILTER、nl80211は、AF_NETLINKソケットを介して到達するカーネルプロトコルです。

flowchart LR
    subgraph clients[Clients and Configuration]
        nmcli["nmcli / GUI"]
        networkctl
        netplan[Netplan]
        firewallcmd[firewall-cmd]
    end

    subgraph controllers[Daemons and Direct Utilities]
        nm[NetworkManager]
        networkd[systemd-networkd]
        wifi["wpa_supplicant / iwd"]
        firewalld
        iproute["ip / bridge / tc"]
        nft
        iw
        ethtool
        bpftool
    end

    subgraph apis[Kernel Control Interfaces]
        rtnl["NETLINK_ROUTE<br/>(rtnetlink)"]
        nfnl[NETLINK_NETFILTER]
        nl80211["nl80211<br/>(Generic Netlink)"]
        ethtoolapi["ethtool Generic Netlink<br/>or device ioctl"]
        bpfapi["bpf() syscall"]
    end

    kernel[Linux Network Kernel]

    nmcli -->|"libnm + D-Bus"| nm
    networkctl -->|"daemon IPC"| networkd
    netplan -.->|"generates configuration"| nm
    netplan -.->|"generates configuration"| networkd
    firewallcmd -->|D-Bus| firewalld

    nm -->|"internal Netlink"| rtnl
    nm -->|D-Bus| wifi
    networkd -->|sd-netlink| rtnl
    iproute -->|"internal libnetlink"| rtnl
    firewalld -->|"nftables backend"| nfnl
    nft -->|"libnftables + libnftnl"| nfnl
    wifi --> nl80211
    iw --> nl80211
    ethtool --> ethtoolapi
    bpftool -->|libbpf| bpfapi

    rtnl --> kernel
    nfnl --> kernel
    nl80211 --> kernel
    ethtoolapi --> kernel
    bpfapi --> kernel

この図は、一般的なnmcliの依存関係に関する疑問に直接答えます。

1. nmcliはlibnmを通じて要求を構築します。
2. libnmはD-Bus経由で要求をNetworkManagerデーモンに送信します。
3. NetworkManagerは独自のNetlink実装を通じて、通常のカーネルネットワーク状態を適用します。
4. iproute2は同じカーネルAPIの独立した管理クライアントであり、NetworkManagerとカーネルの間の中間層ではありません。

シェル自動化では、プログラムからip、nft、または別のCLIを呼び出すことが依然として有用です。ただし、長時間実行されるマネージャーは一般にライブラリを使用するか、カーネルプロトコルを直接実装します。直接アクセスによってコマンド出力の解析を避けられ、マネージャーは非同期状態通知を購読できます。