11.6. ネットワーク
/etc/iproute2/ 内のカスタム iproute2 設定が期待どおりに動作します
以前は、RHEL 10.0 に更新すると、iproute2 パッケージによってデフォルトの設定が /usr/share/iproute2/ ディレクトリーに保存されていました。また、/etc/iproute2/ にカスタム設定がある場合、更新時に関連するファイルの名前が変更され、.rpmsave 接尾辞が追加されていました。その結果、カスタム設定が適用されていませんでした。RHEL 10.1 バージョンの iproute2 パッケージに更新すると、パッケージ内のインストールスクリプトがカスタム設定ファイルの名前を変更しなくなります。また、/etc/iproute2/ に .rpmsave 接尾辞を持つファイルが検出された場合、スクリプトがこの接尾辞を削除します。その結果、カスタム設定が期待どおりに再び機能するようになりました。
iproute2 のデフォルト設定は /usr/share/iproute2/ に残ることに注意してください。
Jira:RHEL-99163[1]
実行時に SR-IOV VF の数を減らしてもカーネルがパニックを起こさなくなりました
以前のリリースでは、次の条件がすべて当てはまる場合、Linux カーネルがパニックを起こすことがありました。
- ホストの Input-Output Memory Management Unit (IOMMU) が有効化されている。
- ネットワークドライバーがページプールを使用している。
- このドライバーを使用するネットワークインターフェイスの Single Root I/O Virtualization (SR-IOV) Virtual Function (VF) の数を減らした。
この更新により、カーネルが、ページプールに属している DMA マッピングされたメモリーページを追跡するようになりました。VF の削除などによりページプールが破棄されると、メモリーページの DMA マッピングが解除されます。これにより、VF が削除された後にメモリーページをアンマップしようとする試みが防止されます。その結果、実行時に SR-IOV VF の数を減らしてもカーネルがパニックを起こさなくなりました。
Jira:RHEL-68401[1]
NAT エンジンが戻り方向のアドレス競合をチェックするようになりました
この更新前は、ネットワークアドレス変換 (NAT) エンジンが戻り方向のアドレス競合をチェックしていませんでした。これにより、新しい着信接続が既存の接続と同じ送信元アドレスと送信元ポートを使用する場合に、接続障害が発生していました。このリリースでは、NAT エンジンが戻り方向をチェックして競合を検出し、新しい接続の送信元ポートが新しい使用可能なポート番号に内部的に再マッピングされます。そのため、接続が期待どおりに処理されます。
Jira:RHEL-99656[1]
nft_fib 式が、VRF ドメインの IPv4 と IPv6 の両方に対して一貫した結果を返すようになりました
この更新前は、デバイスが Virtual Routing and Forwarding (VRF) ドメインに含まれている場合、Netfilter の "nft_fib" 式が local ではなく unicast を返していました。さらに、fib daddr . iif 式が、VRF インターフェイスに到達する IPv4 パケットと IPv6 パケットに対して異なる動作をしました。着信 IPv6 パケットの場合は、基盤となる物理インターフェイスの名前が誤って返されていました。一方、IPv4 パケットの場合は、VRF デバイス自体の名前が正しく返されていました。この更新により、デバイスが VRF ドメインに含まれている場合に、nft_fib 式が IPv4 と IPv6 の両方に対して一貫した結果を提供するようになりました。
Jira:RHEL-88574[1]
wpa_supplicant の PKCS #11 を使用したネットワーク認証方式が修正されました
RHEL 10 で、OpenSSL エンジン API など、Federal Information Processing Standards (FIPS) と互換性のないエンジンが削除されました。その結果、削除されたエンジンに依存していた wpa_supplicant サービスが、PKCS #11 URI 形式で保存された X.509 証明書と鍵をロードできなくなりました。これにより、EAP-TLS 認証方法がすべて阻止され、PKCS #11 を使用するバリアントが適切なネットワークに接続できなくなりました。この問題を解決するために、wpa_supplicant が pkcs11-provider パッケージに依存するようになり、これと同じ名前のライブラリーを使用して PKCS #11 ストレージから X.509 証明書と鍵をロードするようになりました。そのため、PKCS #11 を使用したネットワーク認証方法が期待どおりに機能します。