第9章 ネットワーク

9.1. NetworkManager

9.1.1. 従来のネットワークスクリプトのサポート

Red Hat Enterprise Linux 8 では、ネットワークスクリプトが非推奨となっており、デフォルトでは提供されなくなりました。基本インストールでは、nmcli ツールを介して NetworkManager を呼び出す ifup スクリプトおよび ifdown スクリプトの新しいバージョンが提供されます。Red Hat Enterprise Linux 8 で ifup スクリプトおよび ifdown スクリプトを実行する場合は、NetworkManager が起動している必要があります。

注記

/sbin/ifup-local スクリプト、ifdown-pre-local スクリプト、およびifdown-local スクリプトのカスタムコマンドは実行されません。

このスクリプトが必要な場合は、次のコマンドを使用すれば、システムに非推奨のネットワークスクリプトをインストールできます。

~]# yum install network-scripts

ifup スクリプトおよび ifdown スクリプトが、インストールされた従来のネットワークスクリプトにリンクします。

従来のネットワークスクリプトを呼び出すと、そのスクリプトが非推奨であることを示す警告が表示されます。

9.1.2. NetworkManager が SR-IOV 仮想機能に対応

Red Hat Enterprise Linux 8 では、NetworkManager で、SR-IOV (Single Root I/O virtualization) に対応するインターフェースに仮想ファンクション (VF) の数を設定できます。また、NetworkManager では、MAC アドレス、VLAN、spoof checking 設定、許可されるビットレートなど、仮想関数の属性の一部を設定できます。SR-IOV に関連するプロパティーはすべて、sriov 接続の設定で利用できます。詳細は、man ページの nm-settings(5) を参照してください。

9.1.3. NetworkManager が、接続に対するワイルドカードインターフェースの名前一致に対応

以前は、インターフェース名の完全一致のみを使用して、特定のインターフェースへの接続を制限していました。今回の更新で、接続には、ワイルドカードに対応する新しい match.interface-name プロパティーが含まれるようになりました。この更新により、ワイルドカードパターンを使用した柔軟な方法で、接続用インターフェースを選択できるようになります。

9.1.4. NetworkManager が、ethtool オフロード機能の設定に対応

この機能強化により、NetworkManager は、ethtool オフロード機能の設定に対応するため、init スクリプトまたは NetworkManager ディスパッチャースクリプトを使用しなくなりました。その結果、以下のいずれかの方法を使用して、接続プロファイルの一部としてオフロード機能を設定できるようになりました。

  • nmcli ユーティリティーを使用
  • /etc/NetworkManager/system-connections/ ディレクトリーの鍵ファイルを編集
  • /etc/sysconfig/network-scripts/ifcfg-* ファイルを編集

この機能は、現在、グラフィカルインターフェースと nmtui ユーティリティーでは対応していないことに注意してください。

9.1.5. NetworkManager が、デフォルトで内部 DHCP プラグインを使用するようになる

NetworkManager は、DHCP プラグインの internal および dhclient に対応します。デフォルトでは、Red Hat Enterprise Linux (RHEL) 7 の NetworkManagerdhclient を使用し、RHEL 8 では 内部 プラグインを使用します。特定の状況では、プラグインの動作が異なります。たとえば、dhclient は、/etc/dhcp/ ディレクトリーで指定されている追加設定を使用できます。

RHEL 7 から RHEL 8 にアップグレードした際に NetworkManager の動作が異なる場合は、dhclient プラグインを使用するために、/etc/NetworkManager/NetworkManager.conf ファイルの [main] セクションに、以下の設定を追加します。

[main]
dhcp=dhclient

9.1.6. RHEL 8 では、NetworkManager-config-server パッケージがデフォルトでインストールされない

NetworkManager-config-server パッケージは、セットアップ中にベース環境の Server または Server with GUI のいずれかを選択した場合に限り、デフォルトでインストールされます。別の環境を選択した場合は、yum install NetworkManager-config-server コマンドを使用してパッケージをインストールします。

9.2. パケットのフィルタリング

9.2.1. nftables が、iptables を、デフォルトのネットワークパケットフィルタリングのフレークワークとして置き換え

nftables フレームワークは、パケットの分類機能を提供し、iptables ツール、ip6tables ツール、arptables ツール、および ebtables ツールの後継となります。利便性、機能、パフォーマンスにおいて、以前のパケットフィルタリングツールに多くの改良が追加されました。以下に例を示します。

  • 線形処理の代わりにルックアップテーブルを使用
  • IPv4 プロトコルおよび IPv6 プロトコルに対する 1 つのフレームワーク
  • 完全ルールセットのフェッチ、更新、および保存を行わず、すべてアトミックに適用されるルール
  • ルールセットにおけるデバッグおよびトレースへの対応 (nftrace) およびトレースイベントの監視 (nft ツール)
  • より統一されたコンパクトな構文、プロトコル固有の拡張なし
  • サードパーティーのアプリケーション用 Netlink API

iptables と同様、nftables は、チェーンを保存するテーブルを使用します。このチェーンには、アクションを実行する個々のルールが含まれます。nft ツールは、以前のパケットフィルタリングフレームワークのツールをすべて置き換えます。libnftables ライブラリーは、libmnl ライブラリーの Netlink API nftables で、低レベルの対話のために使用できます。

iptables ツール、ip6tables ツール、ebtables ツール、および arptables ツールは、nftables ベースの同じ名前のドロップインツールに置き換えられました。外部の挙動は従来のものと同じですが、内部的には必要に応じて互換インターフェースを通して、従来の netfilter カーネルモジュールを使用した nftables を使用します。

nftables ルールセットに対するモジュールの効果は、nft list ruleset コマンドを使用して確認できます。これらのツールは、テーブル、チェーン、およびルールを nftables ルールセットに追加するため、nft flush ruleset コマンドなどの nftables ルールセット操作は、先に別の従来のコマンドを使用してインストールしたルールセットに影響を及ぼす可能性があることに注意してください。

どの種類のツールが存在するかをすばやく特定するために、バージョン情報にバックエンド名が追加されるようになりました。RHEL 8 では、nftables ベースの iptables ツールで、次のバージョン文字列が出力されます。

$ iptables --version
iptables v1.8.0 (nf_tables)

一方、従来の iptables ツールが存在する場合は、次のバージョン情報が出力されます。

$ iptables --version
iptables v1.8.0 (legacy)

9.2.2. RHEL 8 で、フィルターテーブルから Arptables FORWARD が削除される

arptables の FORWARD チェーン機能は、Red Hat Enterprise Linux (RHEL) 8 から削除されました。ebtables ツールの FORWARD チェーンを使用して、ルールを追加できるようになりました。

9.2.3. iptables-ebtables の出力の一部が、ebtables と互換性がない

RHEL 8 では、ebtables コマンドは、iptables-ebtables パッケージが提供します。ここには、このツールが nftables ベースで再実装されています。このツールには別のコードベースがあり、その出力は、側面が異なる場合があるため、無視できるか、設計上の選択を慎重に検討する必要があります。

したがって、ebtables 出力を解析するスクリプトを移行する際に、以下を反映するスクリプトを調整します。

  • MAC アドレスの書式が、長さが固定されるように変更されました。octet 値では、2 文字の書式を維持するために、必要に応じて、個々のバイト値の前にゼロが含まれます。
  • IPv6 接頭辞の形式が、RFC 4291 に準拠するように変更になりました。スラッシュ文字の後ろの終了部分には、IPv6 アドレスフォーマットのネットマスクが含まなくなりましたが、プレフィックス長は含まれます。この変更は、有効な (左連続の) マスクにしか適用されませんが、それ以外の場合は、古い形式で印刷されます。

9.2.4. iptablesnftables に変換する新しいツール

今回の更新で、既存の iptables ルールまたは ip6tables ルールを、nftables で同等のルールに変換する iptables-translate ツールおよび ip6tables-translate ツールが追加されました。拡張機能によっては変換機能がない場合もあります。対応する機能がない拡張機能が存在する場合は、ツールにより、その前に # 記号が付いた未変換ルールが出力されます。以下に例を示します。

| % iptables-translate -A INPUT -j CHECKSUM --checksum-fill
| nft # -A INPUT -j CHECKSUM --checksum-fill

また、ユーザーは、iptables-restore-translate ツールおよび ip6tables-restore-translate ツールを使用して、ルールのダンプを変換できます。その前に、iptables-save コマンドまたは ip6tables-save コマンドを使用して、現在のルールのダンプを出力できます。以下に例を示します。

| % sudo iptables-save >/tmp/iptables.dump
| % iptables-restore-translate -f /tmp/iptables.dump
| # Translated by iptables-restore-translate v1.8.0 on Wed Oct 17 17:00:13 2018
| add table ip nat
| ...

9.3. wpa_supplicant の変更点

9.3.1. journalctlwpa_supplicant ログを読み込む

Red Hat Enterprise Linux (RHEL) 8 の wpa_supplicant パッケージは、CONFIG_DEBUG_SYSLOG が有効になった状態で構築されています。これにより、/var/log/wpa_supplicant.log ファイルの内容を確認する代わりに、journalctl ユーティリティーを使用して wpa_supplicant ログを読み取ることができます。

9.3.2. wpa_supplicant のワイヤレス拡張に対する compile-time サポートが無効になっている

wpa_supplicant パッケージでは、ワイヤレス拡張に対応していません。コマンドラインの引数として wext を使用する場合、またはワイヤレス拡張にのみ対応する古いアダプターのみを使用する場合は、wpa_supplicant デーモンを実行できません。

9.4. 新しいデータチャンクタイプ I-DATA が SCTP に追加

今回の更新で、新しいデータチャンクタイプ (I-DATA)、およびストリームスケジューラーが SCTP (Stream Control Transmission Protocol) に追加されました。以前は、ユーザーが送信する順序で SCTP がユーザーメッセージを送信していました。このため、SCTP ユーザメッセージが大きくなると、送信が完了するまで、ストリーム内の他のすべてのメッセージがブロックされていました。I-DATA チャンクを使用している場合は、Transmission Sequence Number (TSN) フィールドがオーバーロードされません。そのため、SCTP ではさまざまな方法でストリームをスケジュールできるようになり、I-DATA ではユーザーメッセージのインターリーブ (RFC 8260) が可能になりました。両方のピアが I-DATA チャンクタイプに対応する必要があることに注意してください。

9.5. RHEL 8 における TCP の新機能

Red Hat Enterprise Linux 8 には、TCP ネットワーキングスタックバージョン 4.18 が同梱され、より高いパフォーマンスおよび安定性と、より優れたスケーラビリティーが提供されます。特に、入力接続率が高い、ビジー状態の TCP サーバーのパフォーマンスが向上します。

また、2 つの新しい TCP 輻輳制御アルゴリズム (BBR および NV) が利用でき、ほとんどのシナリオで、キュービックよりもレイテンシーが短く、スループットも良くなります。

9.5.1. RHEL 8 における TCP BBR への対応

Red Hat Enterprise Linux (RHEL) 8 では、新しい TCP 輻輳制御アルゴリズムである BBR (Bottleneck Bandwidth and Round-trip time) に対応するようになりました。BBR は、ボトルネックリンクおよびラウンドトリップ時間 (RTT) の帯域幅を決定します。ほとんどの輻輳アルゴリズムは、パケットロス (デフォルトの Linux TCP 輻輳制御アルゴリズムである CUBIC を含む) に基づいており、高スループットのリンクの問題をかかえています。BBR は、損失イベントに直接反応せず、利用可能な帯域幅をそれと一致させて、TCP ペーシングレートを調整します。TCP BBR を使用する場合は、関係するすべてのインターフェースの fq キュー設定に切り替える必要があります。

ユーザーが明示的に fq を使用し、fq_codel は使用しないことに注意してください。

詳細は、man ページの tc-fq を参照してください。

9.7. ネットワークインターフェース名の変更

Red Hat Enterprise Linux 8 では、RHEL 7 と同じ一貫性のあるネットワークデバイス命名スキームがデフォルトで使用されます。ただし、一部のカーネルドライバー (e1000enfpqedesfctg3bnxt_en など) では、RHEL 8 の新規インストールで一貫した名前が変更になりました。ただし、RHEL 7 からアップグレードする場合はこの名前が保持されます。

9.8. tc コマンドの -ok オプションが削除される

tc コマンドの -ok オプションが、Red Hat Enterprise Linux 8 から削除されました。回避策として、カーネルを使用した netlink から直接通信するコードを実装できます。受け取った応答メッセージは、送信した要求の完了およびステータスを示します。時間がそれほど重要ではないアプリケーションに対する別の方法は、各コマンドに対して個別に tc を呼び出すことです。これは、カスタムスクリプトで発生する可能性があります。これは、成功したそれぞれの tc 起動に対して OK を出力することで、tc -batch 動作をシミュレートします。


このページには機械翻訳が使用されている場合があります (詳細はこちら)。