「NetworkManager」の版間の差分

2024年12月1日 (日) 15:49時点における最新版

NetworkManager は、システムがネットワークに自動的に接続できるようにするためにネットワークの検出と設定の機能を提供するプログラムです。NetworkManager の機能は無線ネットワークと有線ネットワークの両方で有用です。無線ネットワークでは、NetworkManager は既知の無線ネットワークを優先するようになっており、最も信頼性のあるネットワークに切り替える機能もあります。NetworkManager 対応のアプリケーションはオンラインモードとオフラインモードの切り替えが可能です。また、NetworkManager は無線接続よりも有線接続を優先するようになっており、モデム接続と特定の種類の VPN に対応しています。NetworkManager は元々 Red Hat によって開発されていましたが、現在では GNOME プロジェクトによってホストされています。

警告: デフォルトでは、機密情報 (Wi-Fi のパスワードなど) は root ユーザからファイルシステムでアクセス可能であり、さらに GUI (nm-applet など) を介して設定にアクセスできるユーザからもアクセス可能です。#Wi-Fi パスワードの暗号化を参照してください。

1 インストール
2 使い方
- 2.1 nmcli 例
- 2.2 接続を編集する
3 フロントエンド
4 設定
5 ネットワークサービスで NetworkManager dispatcher を使用する
- 5.1 ディスパッチャのタイムアウトを防ぐ
- 5.2 ディスパッチャの例
6 テスト
7 ヒントとテクニック
8 トラブルシューティング
9 参照

インストール

NetworkManager は networkmanager パッケージでインストールできます。このパッケージには、デーモン、コマンドラインインターフェイス (nmcli)、そして curses ベースのインターフェイス (nmtui) が含まれています。

NetworkManager を有効化する

インストールしたら、NetworkManager.service を起動/有効化する必要があります。NetworkManager デーモンが起動すると、既に構成されている利用可能な "システム接続" に自動的に接続します。"ユーザ接続" や未構成の接続を設定したり接続したりするには、nmcli やアプレットが必要です。

ノート:

ネットワークを設定しようとするサービスが他に動いていないことを確認しなければなりません。事実、ネットワーキングサービスが複数動いていると、互いに干渉してしまいます。現在動作中のサービスの完全なリストは systemctl --type=service で見られます。衝突の恐れのあるサービスは停止してください。NetworkManager サービスを有効化する方法は #設定を見てください。
systemd-resolved が起動されていない場合、エラーメッセージがログに溢れ始めます。詳細は #Unit dbus-org.freedesktop.resolve1.service not found を見てください。

追加のインターフェイス

nm-connection-editor: グラフィカルユーザインターフェイス。
network-manager-applet: システムトレイアプレット (nm-applet)。

モバイルブロードバンドサポート

NetworkManager はモバイルブロードバンド接続のサポートに ModemManager を使用します。

modemmanager と usb_modeswitch をインストールしてください。その後、ModemManager.service を有効化し、起動してください。

ModemManager を認識させるために NetworkManager.service を再起動する必要がある場合があります。サービスを再起動し、モデムを挿し直せば、認識されるはずです。

フロントエンド (例えば nm-connection-editor) から接続を追加し、接続タイプにモバイルブロードバンドを選択してください。ISP と料金プランを選んだら、APN とその他の設定が mobile-broadband-provider-info にある情報で自動的に書き込まれるはずです。

PPPoE / DSL サポート

PPPoE / DSL サポートに関しては rp-pppoe をインストールしてください。PPPoE 接続を追加するには、nm-connection-editor を使って新しい DSL/PPPoE 接続を追加してください。

VPN サポート

NetworkManager 1.16 から WireGuard のネイティブなサポートが追加されました。必要なのは wireguard カーネルモジュールだけです。詳細は NetworkManager のブログ記事の WireGuard を見てください。

その他の VPN タイプに対するサポートはプラグインなシステムをベースとしています。以下のパッケージで提供されています:

networkmanager-openconnect: OpenConnect 用
networkmanager-openvpn: OpenVPN 用
networkmanager-pptp: PPTP クライアント用
networkmanager-strongswan: strongSwan 用
networkmanager-vpnc
networkmanager-fortisslvpn^AUR
networkmanager-iodine-git^AUR
networkmanager-libreswan^AUR
networkmanager-l2tp
networkmanager-ssh-git^AUR
network-manager-sstp

警告: VPN サポートに関連するバグが大量に存在しています。デーモンプロセスのオプションが GUI から適切に設定されていることを確認し、パッケージのリリースの度にダブルチェックしてください。

ノート:

VPN 使用時に DNS 解決を完全に機能させるには、条件付きフォワーディングをセットアップする必要があります。
これらのプラグインは、ドキュメント化されたコマンドラインインターフェイスが存在しなかったり、アプレットが実行されていないと全く動作しなかったりする場合があります。通常のデスクトップ環境を使用している場合には問題になりません。通常とは異なるものを使用している場合は、接続を設定したりアクティブ化したりする際に必要なダイアログが表示されるようにするために #nm-applet を実行するべきです。[1]

使い方

NetworkManager には nmcli(1) と nmtui(1) が付属しています。

nmcli 例

近くの Wi-Fi ネットワークを一覧表示します:

$ nmcli device wifi list

Wi-Fi ネットワークに接続します:

$ nmcli device wifi connect SSID_または_BSSID password パスワード

非表示の Wi-Fi ネットワークに接続します:

$ nmcli device wifi connect SSID_または_BSSID password パスワード hidden yes

wlan1 インターフェイスで Wi-Fi に接続します:

$ nmcli device wifi connect SSID_または_BSSID password パスワード ifname wlan1 プロファイル名

インターフェイスを切断します:

$ nmcli device disconnect ifname eth0

名前、UUID、タイプ、バッキングデバイスを含む接続のリストを取得します:

$ nmcli connection show

接続を有効にします (つまり、既存のプロファイルでネットワークに接続します):

$ nmcli connection up 名前_または_uuid

接続を削除します:

$ nmcli connection delete 名前_または_uuid

ネットワークデバイスとその状態のリストを表示します:

$ nmcli device

Wi-Fi をオフにします:

$ nmcli radio wifi off

接続を編集する

設定の包括的なリストについては、nm-settings(5) を参照してください。

まず、接続のリストを取得する必要があります:

$ nmcli connection

NAME                UUID                                  TYPE      DEVICE
有線接続 2          e7054040-a421-3bef-965d-bb7d60b7cecf  ethernet  enp5s0
有線接続 1          997f2782-f0fc-301d-bfba-15421a2735d8  ethernet  enp0s25
MY-HOME-WIFI-5G     92a0f7b3-2eba-49ab-a899-24d83978f308  wifi       --

ここでは、後で使用する接続 ID として最初の列を使用できます。この例では、有線接続 2 を接続 ID として選択します。

作成後に接続 有線接続 2 を設定するには、次の3つの方法があります:

nmcli 対話型エディタ: nmcli connection edit '有線接続 2'。
使用法はエディタから十分に文書化されています。

nmcli コマンドラインインターフェイス: nmcli connection modify '有線接続 2' 設定.プロパティ値。使用方法については nmcli(1) を参照してください。例えば、nmcli connection modify '有線接続 2' ipv4.route-metric 200 コマンドを使用して、IPv4 ルートメトリックを 200 に変更できます。

設定を削除するには、次のように空のフィールド ("") を渡します:

nmcli connection modify '有線接続 2' 設定.プロパティ ""

接続ファイル: /etc/NetworkManager/system-connections/ で、対応する 有線接続 2.nmconnection ファイルを変更します。
nmcli connection reload で設定ファイルをリロードすることを忘れないでください。

フロントエンド

デスクトップ環境と統合するために、ほとんどのユーザはアプレットをインストールしたいと考えるでしょう。アプレットはネットワークの選択や設定を容易にするだけでなく、機密情報をセキュアに保存するために必要なエージェントも提供します。様々なデスクトップ環境は独自のアプレットを持っています。デスクトップ環境に独自のアプレットが存在しない場合、#nm-applet を使用することもできます。

GNOME

GNOME にはツールが内蔵されており、ネットワーク設定からアクセス可能です。

KDE Plasma

plasma-nm パッケージをインストールしてください。その後、パネルオプション > ウィジェットを追加 > ネットワーク で KDE タスクバーにアプレットを追加してください。

nm-applet

network-manager-applet は、システムトレイのある Xorg 環境で機能する GTK 3 フロントエンドです。

接続に関する機密情報 (Wi-Fi のパスワードなど) を保存するには、Secret Service D-Bus API を実装しているアプリケーション (GNOME/Keyring、KDE Wallet、KeePassXC など) をインストールし設定してください。

接続の設定で Make available to other users チェックボックスオプションを有効化すると、NetworkManager はその接続のパスワードを平文で保存することに注意してください。とはいえ、パスワードが含まれるファイルは root (及び nm-applet を通して他のユーザ) からしかアクセスできません。#Wi-Fi パスワードの暗号化を見てください。

trayer か stalonetray を使うことで、システムトレイ無しで nm-applet を実行することができます。例えば、以下のようなスクリプトをパスに追加することができます:

nmgui

#!/bin/sh
nm-applet    2>&1 > /dev/null &
stalonetray  2>&1 > /dev/null
killall nm-applet

stalonetray のウィンドウを閉じると、nm-applet も閉じます。なので、ネットワークの設定を終えたら余分なメモリが消費されることはありません。

このアプレットは、Wi-Fi ネットワークの接続や切断などのイベントの通知を表示することができます。これらの通知を表示させるには、通知サーバがインストールされている必要があります (デスクトップ通知を見てください)。アプレットを通知サーバ無しで使うと、標準出力や標準エラー出力にメッセージが表示され、最悪、アプレットがハングするかもしれません。[2] を参照してください。

通知を無効化した状態で nm-applet を実行するには、アプレットを以下のコマンドで起動してください:

$ nm-applet --no-agent

ヒント: nm-applet は自動起動デスクトップファイルによって自動的に起動されるかもしれません。そのような場合に --no-agent オプションを追加するには、デスクトップファイルの Exec 行を変更してください。つまり:

Exec=nm-applet --no-agent

警告: i3 では、nm-applet が --no-agent オプションで起動された場合、パスワード入力ダイアログが表示されないため、アイテムリストをクリックして新しい暗号化された Wi-Fi ネットワークに接続することができなくなります。journal には no secrets: No agents were available for this request と出力されます。

Appindicator

バージョン 1.18.0 から、Appindicator のサポートが公式の network-manager-applet パッケージで利用可能になりました。nm-applet を Appindicator の環境で使うには、アプレットを以下のコマンドで起動してください:

$ nm-applet --indicator

networkmanager-dmenu

フロントエンドのもう一つの選択肢は networkmanager-dmenu-git^AUR です。これは、NetworkManager の接続を nm-applet ではなく dmenu や rofi で管理する小さなスクリプトです。このスクリプトには必須の機能が全て揃っています。例えば: NetworkManager の既存の Wi-Fi 接続や有線接続に接続する、新しい Wi-Fi 接続に接続する、必要に応じてパスフレーズを要求する、既存の VPN 接続に接続する、ネットワークを有効化/無効化する、nm-connection-editor GUI を起動する、Bluetooth ネットワークに接続する。

switchboard

Pantheon の switchboard は、switchboard-plug-network と nm-connection-editor と組み合わせて使えば、NetworkManager を設定するためのデスクトップ環境に依存しない方法になります。以下のコマンドで実行できます:

$ io.elementary.settings

設定

NetworkManager を適切に実行させるには、いくつか追加の手順が必要です。ネットワーク設定#ホスト名の設定で説明されているように、/etc/hosts が設定されていることを確認してください。

NetworkManager のグローバルな設定ファイルは /etc/NetworkManager/NetworkManager.conf です。追加の設定ファイルは /etc/NetworkManager/conf.d/ に置くことができます。通常、グローバルなデフォルト値に対して設定を行う必要はありません。

設定ファイルを編集したら、以下のコマンドで変更を適用することができます:

# nmcli general reload

NetworkManager-wait-online

NetworkManager.service を有効化すると、NetworkManager-wait-online.service も有効化されます。NetworkManager-wait-online.service は oneshot なシステムサービスで、ネットワークが構成されるまで待機します。このサービスには WantedBy=network-online.target が含まれているため、このサービスが終了するのは、network-online.target 自体が有効化されている時か、あるいは network-online.target が他のユニットによって実行された時のみです。systemd#ネットワークが稼働した後にサービスを実行するも参照してください。

デフォルトでは、NetworkManager-wait-online.service は、ネットワーク接続が確立されるのを待つ (nm-online(1) を参照) のではなく、NetworkManager の起動が完了するのを待ちます。ネットワークの準備が整う前に NetworkManager-wait-online.service が終了してしまってブート時に一部のサービスが失敗してしまう場合、NetworkManager-wait-online.service ユニットを拡張し、ExecStart 行から -s を削除してください:

[Service]
ExecStart=
ExecStart=/usr/bin/nm-online -q

ただし、これにより他の問題が発生する可能性があることに注意してください。

一部のケースで、タイムアウトの設定が短すぎるために、このサービスの起動が失敗してしまう場合があります。サービスを編集して NM_ONLINE_TIMEOUT を 60 からより大きい値に変更してください。

PolicyKit のパーミッションをセットアップする

デフォルトでは、アクティブなローカルセッションのユーザは全員パスワード無しでほぼ全てのネットワーク設定を変更することができます。セッションの種類を確認する方法については、一般的なトラブルシューティング#セッションのパーミッションを見てください。ほとんどの場合、特に設定しなくても全て動作するはずです。

一部のアクション (システムのホスト名を変更するなど) においては、管理者のパスワードが必要です。そのような場合、自身のユーザを wheel グループに追加し、パスワードのプロンプトを表示する Polkit の認証エージェントを実行する必要があります。

リモートセッションの場合 (例えば、ヘッドレス VNC)、NetworkManager を使用するために必要な特権を得る方法は複数あります:

自身を wheel グループに追加する。アクションの度にパスワードを入力する必要があります。注意点として、wheel グループに追加すると他の権限 (root パスワードを入力せずに sudo を実行できるなど) も付与される場合があります。
自身を network グループに追加し、以下の内容で /etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules を作成する:
```
polkit.addRule(function(action, subject) {
  if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {
    return polkit.Result.YES;
  }
});
```
network グループ内の全ユーザがパスワード無しでネットワークの追加と削除を行えるようになります (これは、Polkit 認証エージェントを実行する必要がないことを意味します。なので、この方法は SSH セッションでも使えます。)。

プロクシ設定

NetworkManager はプロキシに関するいくつかの設定をサポートしています。それらは nmtui から直接変更することはできませんが、nm-applet と nmcli はそれらをサポートしています。

プロキシの設定項目は nm-settings-nmcli(5) を参照してください。

また、ディスパッチャスクリプトを使うことでカスタムのプロキシコマンドを常時実行することができます。#ディスパッチャの例を参照してください。

参照: プロキシ設定

接続の確認

NetworkManager は、ネットワークに接続した後にウェブサーバへの接続を試みて、キャプティブポータルなどが存在しないか確認します。デフォルトの接続先ホスト (/usr/lib/NetworkManager/conf.d/20-connectivity.conf で設定されています) は ping.archlinux.org (redirect.archlinux.org の CNAME エイリアス) です。別のウェブサーバを使う、または接続チェックを無効化するには、/etc/NetworkManager/conf.d/20-connectivity.conf を作成してください (NetworkManager.conf(5) § CONNECTIVITY SECTION を参照)。以下は、GNOME のサーバを使用する例です (GNOME を使用する必要はありません):

/etc/NetworkManager/conf.d/20-connectivity.conf

[connectivity]
uri=http://nmcheck.gnome.org/check_network_status.txt

NetworkManager の接続チェックを無効化するには、以下の設定を使用してください。これは、接続チェックを無効化する VPN に接続している場合に便利です。

/etc/NetworkManager/conf.d/20-connectivity.conf

[connectivity]
enabled=false

ノート: 自動的な接続チェックはプライバシーの問題を引き起こす可能性がありますが、Arch Linux のデフォルトの接続先 URL は如何なるアクセスも記録しません。[3] [4] を参照してください。

キャプティブポータル

キャプティブポータルが存在している場合、デスクトップマネージャが、資格情報を求めるウィンドウを自動的に開く場合があります。あなたのデスクトップ環境がこれを行わない場合、capnet-assist パッケージを使用することができます (しかし現在、このパッケージの NetworkManager ディスパッチャスクリプトは壊れています)。あるいは、NetworkManager ディスパッチャスクリプトを以下の内容で作成することもできます:

/etc/NetworkManager/dispatcher.d/90-open_captive_portal

#!/bin/sh -e
# Script to dispatch NetworkManager events
#
# Runs shows a login webpage on walled garden networks.
# See NetworkManager(8) for further documentation of the dispatcher events.

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

if [ -x "/usr/bin/logger" ]; then
    logger="/usr/bin/logger -s -t captive-portal"
else
    logger=":"
fi

wait_for_process() {
    PNAME=$1
    while [ -z "$(/usr/bin/pgrep $PNAME)" ]; do
        sleep 3;
    done
}

#launch the browser, but on boot we need to wait that nm-applet starts
start_browser() {
    local user="$1"
    local display="$2"

    export DISPLAY="$display"
    wait_for_process nm-applet

    export XAUTHORITY="/home/$user/.Xauthority"

    $logger "Running browser as '$user' with display '$display' to login in captive portal"
    sudo -u "$user" --preserve-env=DISPLAY,XAUTHORITY -H xdg-open http://capnet.elementary.io 2>&1 > /dev/null
}

# Run the right scripts
case "$2" in
    connectivity-change)
    $logger -p user.debug "dispatcher script triggered on connectivity change: $CONNECTIVITY_STATE"
    if [ "$CONNECTIVITY_STATE" = "PORTAL" ]; then
        # Match last column of who's output with ' :[at least one digit] '
        who | awk '$NF ~ /\(:[0-9]+\)/ { print $1 " " substr($NF, 2, length($NF)-2) };' | \
        while read user display; do
            start_browser $user $display || $logger -p user.err "Failed for user: '$user' display: '$display'"
        done
    fi
    ;;
    *)
    # In a down phase
    exit 0
    ;;
esac

スクリプトには実行可能属性を付与してください。しかし、このスクリプトは X が使用されていることを仮定しており、単純に http ページを開きます。必ずしも動作するとは限らないかもしれません。

このスクリプトを実行するには、NetworkManager.service を再起動するか、システムを再起動する必要があります。そうしたら、ディスパッチャスクリプトはキャプティブポータルを検知するとログインウィンドウを開くはずです。

簡潔な解決策は captive-portal-sh です。これはキャプティブポータル URL を取得し、デフォルトのブラウザで開くシェルスクリプトです (Wayland のみ)。

別の解決策は Google Chrome ベースの captive-browser-git^AUR です。

DHCP クライアント

デフォルトでは、NetworkManager は自身の内蔵 DHCP クライアントを使用します。内蔵 DHCPv4 プラグインは nettools の n-dhcp4 ライブラリをベースにしていますが、内蔵 DHCPv6 プラグインは systemd-networkd ベースのコードから作られています。

別の DHCP クライアントを使用するには、以下の代替実装のどれかをインストールしてください:

dhclient - dhclient
dhcpcd - dhcpcd

DHCP クライアントのバックエンドを変更するには、/etc/NetworkManager/conf.d/ 内に設定ファイルを作成して、そのファイル内で main.dhcp=DHCP_クライアント名 オプションを設定してください。例えば:

/etc/NetworkManager/conf.d/dhcp-client.conf

[main]
dhcp=dhclient

ノート:

NetworkManger は IPv6 に dhcpcd を使用することをサポートしていません。NetworkManager issue #5 を参照してください。dhcpcd が DHCP クライアントとして設定されている場合、NetworkManager は DHCPv6 に対しては内臓の DHCP クライアントを使用します。
dhclient パッケージと dhcpcd パッケージに同梱されている systemd ユニットは有効化しないでください。NetworkManager と競合してしまいます。詳細は #インストールセクションに書かれているノートを見てください。

DNS の管理

NetworkManager の DNS 管理については、GNOME プロジェクトの wiki ページ Projects/NetworkManager/DNS で説明されています。

DNS キャッシングと条件付きフォワーディング

NetworkManager には、dnsmasq または systemd-resolved を使用して DNS キャッシングと条件付きフォワーディングを有効化するプラグインが存在します (以前は、"条件付きフォワーディング" は NetworkManager のドキュメントで "split DNS" と呼ばれていました)。このセットアップには、DNS ルックアップがキャッシュされるので名前解決の時間が短縮され、VPN ホストの DNS ルックアップが、関連する VPN の DNS サーバに転送されるという長所があります。これは、複数の VPN に接続する場合に特に便利です。

ノート: /etc/resolv.conf が /run/systemd/resolve/stub-resolv.conf や /run/systemd/resolve/resolv.conf、/lib/systemd/resolv.conf、/usr/lib/systemd/resolv.conf へのシンボリックリンクである場合、NetworkManager は systemd-resolved を自動的に選択します。dnsmasq を使用するには、まずシンボリックリンクを削除する必要があります。その後で、NetworkManager を再起動してください。

dnsmasq

dnsmasq がインストールされていることを確認してください。そして、/etc/NetworkManager/conf.d/ 内の設定ファイル (無い場合は作成してください) で main.dns=dnsmasq を設定してください:

/etc/NetworkManager/conf.d/dns.conf

[main]
dns=dnsmasq

次に、nmcli general reload を root として実行してください。NetworkManager は自動的に dnsmasq を起動し、/etc/resolv.conf に 127.0.0.1 を追加します。元の DNS サーバは /run/NetworkManager/no-stub-resolv.conf を見れば分かります。dnsmasq が使用されているかどうかは、drill example.com で同じ DNS ルックアップを2度行ってサーバとクエリの時間を計測すれば確認できます。

ノート:

dnsmasq.service を起動したり、/etc/dnsmasq.conf を編集したりする必要はありません。NetworkManager は、その systemd サービスを使わず、さらに dnsmasq のデフォルトの設定ファイルを読み込まずに dnsmasq を起動します。
NetworkManager によって起動された dnsmasq インスタンスは 127.0.0.1:53 にバインドされます。なので、これと同じアドレスとポートで他のソフトウェア (dnsmasq.service も含む) を実行することはできません。

dnsmasq のカスタム設定

/etc/NetworkManager/dnsmasq.d/ 内に設定ファイルを作成することで、dnsmasq のカスタム設定を作成することができます。例えば、DNS キャッシュ (RAM 内に格納されます) のサイズを変更するには:

/etc/NetworkManager/dnsmasq.d/cache.conf

cache-size=1000

設定ファイルの構文は以下のコマンドで確認できます:

$ dnsmasq --test --conf-file=/dev/null --conf-dir=/etc/NetworkManager/dnsmasq.d

利用可能な全てのオプションについては dnsmasq(8) を参照してください。

IPv6

この記事またはセクションの正確性には問題があります。

理由: NetworkManager は ::1 を /etc/resolv.conf に追加しないため、以下の方法では問題を解決できません。@::1 を手動で drill に渡さない限り、Error: error sending query: No (valid) nameservers defined in the resolver というエラーで失敗します。 (議論: トーク:NetworkManager#)

NetworkManager で dnsmasq を有効化すると、IPv6 のみの DNS ルックアップ (つまり、drill -6 [hostname]) が機能しなくなる場合があります (しかし、それ以外では機能する)。この問題を解決するには、以下のファイルを作成し、IPv6 ループバックもリッスンするように dnsmasq を設定してください:

/etc/NetworkManager/dnsmasq.d/ipv6-listen.conf

listen-address=::1

さらに、dnsmasq は上流の IPv6 DNS を優先しません。残念ながら、NetworkManager も IPv6 DNS を優先しません (Ubuntu Bug)。回避策は、NetworkManager の設定で IPv6 DNS を無効化することです (IPv4 DNS があると仮定します)。

DNSSEC

NetworkManager によってデフォルトで開始される dnsmasq インスタンスは、--proxy-dnssec オプションを渡して開始されるため、DNSSEC を検証しません。なので、上流の DNS サーバからの DNSSEC 情報を何でも信頼します。

dnsmasq に DNSSEC を適切に検証させるには、以下の設定ファイルを作成してください (これにより、DNSSEC をサポートしない名前サーバでの DNS 解決が機能しなくなります):

/etc/NetworkManager/dnsmasq.d/dnssec.conf

conf-file=/usr/share/dnsmasq/trust-anchors.conf
dnssec

systemd-resolved

NetworkManager は systemd-resolved を DNS リゾルバ及び DNS キャッシュとして使用することができます。まず先に、systemd-resolved が適切に設定されていて、systemd-resolved.service が開始されていることを確認してください。

/etc/resolv.conf が /run/systemd/resolve/stub-resolv.conf や /run/systemd/resolve/resolv.conf、/usr/lib/systemd/resolv.conf へのシンボリックリンクである場合、systemd-resolved は自動的に使用されます。

/etc/NetworkManager/conf.d/ 内の設定ファイルで main.dns=systemd-resolved を設定することで、これを明示的に有効化することもできます:

/etc/NetworkManager/conf.d/dns.conf

[main]
dns=systemd-resolved

openresolv サブスクライバのある DNS リゾルバ

ローカルの DNS リゾルバへのサブスクライバ (加入者) が openresolv に存在している場合、サブスクライバをセットアップし、openresolv を使用するように NetworkManager を設定してください。

NetworkManager は単一の "インターフェイス" を resolvconf に広告するため、2つの NetworkManager 接続間で条件付きフォワーディングを行うのは不可能です。NetworkManager issue 153 を参照してください。

この問題は /etc/resolvconf.conf で private_interfaces="*" を設定すれば、部分的に緩和できます [5]。検索ドメインリストに無いドメインのクエリは、フォワーディングされません。そのようなクエリは、他の DNS サーバにフォワーディングされるか、DNS ルートサーバから回帰的に解決されるなどして、ローカルのリゾルバの設定に従って処理されます。

カスタム DNS サーバ

カスタムグローバル DNS サーバの設定

全ての接続に対して DNS サーバを設定するには、NetworkManager.conf(5) 内で [global-dns-domain-*] というセクション内で servers=serveripaddress1,serveripaddress2,serveripaddress3 という構文を使ってDNS サーバを指定してください。例えば:

/etc/NetworkManager/conf.d/dns-servers.conf

[global-dns-domain-*]
servers=::1,127.0.0.1

ノート:

NetworkManager の dnsmasq か systemd-resolved プラグイン、または openresolv サブスクライバを使用する場合、servers= オプションにループバックアドレスを指定しないでください。DNS 解決が機能しなくなる可能性があります。
指定されたサーバは systemd-resolved に送られず、接続の DNS サーバが代わりに使用されます。NetworkManager issue 1366 と systemd issue 33754 を参照。

接続でのカスタム DNS サーバの設定

接続でのカスタム DNS サーバの設定 (GUI)

セットアップ方法は、使用するフロントエンドの種類に依ります。手順としては通常、アプレットを右クリックし、プロファイルを編集 (または作成) し、DHCP タイプに 自動 (アドレスのみ) (Automatic (specify addresses)) を選択するというものです。DNS アドレスを入力する必要があり、通常、127.0.0.1, DNS-server-one, ... という形です。

接続でのカスタム DNS サーバの設定 (nmcli / 設定ファイル)

接続の設定で dns フィールド (及び、関連する dns-search と dns-options) を使うことで、接続毎に DNS サーバをセットアップすることができます。

method が auto に設定されている場合 (DHCP を使用する場合)、ignore-auto-dns を yes に設定する必要があります。

/etc/resolv.conf

NetworkManager の /etc/resolv.conf 管理モードは、main.rc-manager で設定されます。networkmanager パッケージはこれを、上流のデフォルトである auto ではなく、symlink に設定します。設定と値は NetworkManager.conf(5) man ページでドキュメント化されています。

ヒント: openresolv を使用すると、NetworkManager は、resolvconf によってサポートされている他のソフトウェアと共存できます。例えば、openresolv が subscriber を持つローカル DNS キャッシングおよび分割 DNS リゾルバを実行できます。openresolv で NetworkManager を使用する場合、条件付きフォワーディングはまだ完全にサポートされていないことに注意してください。

また、NetworkManager は、ネットワークの変更後に /etc/resolv.conf を変更するために使用できる、いわゆるディスパッチャスクリプトを介したフックも提供します。詳細は #ネットワークサービスで NetworkManager dispatcher を使用すると NetworkManager(8) を参照してください。

ノート:

NetworkManager が dnsmasq または systemd-resolved のいずれかを使用するように設定されている場合、適切なループバックアドレスが /etc/resolv.conf に書き込まれます。
NetworkManager が書き込む resolv.conf、または /etc/resolv.conf に書き込む内容は、/run/NetworkManager/resolv.conf で見られます。
取得したネームサーバーと検索ドメインを含む resolv.conf ファイルは、/run/NetworkManager/no-stub-resolv.conf にあります。

管理対象外の /etc/resolv.conf

NetworkManager が /etc/resolv.conf に干渉しないようにするには、/etc/NetworkManager/conf.d/ の設定ファイルで main.dns=none を設定してください:

/etc/NetworkManager/conf.d/dns.conf

[main]
dns=none

ヒント: NetworkManager が DNS 設定を systemd-resolved に送信しないように、main.systemd-resolved=false を設定することもできます。

ノート: main.dns=none を使うのではなく、dnsmasq や systemd-resolved などの他の DNS バックエンドを使用するように NetworkManager を設定する方法については、#DNS キャッシングと条件付きフォワーディングを見てください。

その後、/etc/resolv.conf が壊れたシンボリックリンクになり、削除する必要が生じるかもしれません。その場合、新しい /etc/resolv.conf ファイルを作成してください。

openresolv を使う

ノート: NetworkManager は、systemd-resolvconf によって提供されている systemd-resolved の resolvconf インターフェイスの使用をサポートしていません (resolvectl(1) § COMPATIBILITY WITH RESOLVCONF(8))。

systemd-resolved を使用する際は main.rc-manager=resolvconf を設定しないでください。代わりに、/etc/resolv.conf シンボリックリンクを適切に作成するか、systemd-resolved を使用するように NetworkManager を明示的に設定してください。
systemd-resolved を使用しない場合は、systemd-resolvconf パッケージがインストールされていないことを確認してください。systemd-resolved.service が起動されていないと、このパッケージは、resolvconf を使用する全てのネットワーキングソフトウェア (NetworkManager だけではありません) の機能を破壊します。

openresolv を使用するように NetworkManager を設定するには、/etc/NetworkManager/conf.d/ 内の設定ファイルで main.rc-manager=resolvconf を設定してください:

/etc/NetworkManager/conf.d/rc-manager.conf

[main]
rc-manager=resolvconf

ファイアウォール

現在の接続に基づいて firewalld ゾーンを割り当てることができます。たとえば、職場では制限の厳しいファイアウォールを使用し、自宅では制限の少ないファイアウォールを使用します。

これは、NetworkManager dispatcher を使用して行うこともできます。

ネットワークサービスで NetworkManager dispatcher を使用する

NetworkManager がインターフェイスを立ち上げるまで実行したくないようなネットワークサービスはたくさんあります。NetworkManager には、(例えば NFS や SMB、NTPd を使用する時などに) ネットワークに接続したらサービスを開始し、切断したらサービスを停止する機能があります。

この機能を有効化するには、NetworkManager-dispatcher.service を有効化し、かつ起動する必要があります。

このサービスを有効化したら、/etc/NetworkManager/dispatcher.d 内にスクリプトを追加することができます。

スクリプトは root によって所有されていなければなりません。ディスパッチャは、root によって所有されていないスクリプトを実行しません。セキュリティを高めるために、スクリプトのグループ所有権も root に設定してください:

# chown root:root /etc/NetworkManager/dispatcher.d/10-script.sh

スクリプトファイルを実行可能にするのを忘れないでください。

スクリプトは、ネットワークへの接続時にはアルファベット順で実行され、切断時には逆アルファベット順で実行されます。実行される順番を保証するために、スクリプトの名前の前に数字を置くのが一般的です (例: 10-portmap、30-netfs。こうすることで、NFS がマウントを試みる前に、portmapper が立ち上がります)。

スクリプトは以下の引数を受け取ります:

インターフェイス名: 例えば eth0
アクション: up、down、vpn-up、vpn-down など (完全なリストは NetworkManager-dispatcher(8) を見てください)

警告: 外部ネットワークや公開ネットワークに接続する場合は、どのサービスを起動するのか、どのサーバにサービスは接続できるのかに注意してください。公開ネットワークに接続する際に間違ったサービスを起動してしまうとセキュリティホールを作ってしまう可能性があります。

ディスパッチャのタイムアウトを防ぐ

上記がうまくいっているのであれば、このセクションは関係しません。しかし、ディスパッチャのスクリプトの実行に時間が掛かってしまうという一般的な問題があります。最初は、3 秒だけの内部タイムアウトが使用されていました。呼ばれたスクリプトが時間内に完了しないと、そのスクリプトは kill されていました。後に、タイムアウトは約 20 秒に延長されました (詳細は Bugtracker を参照)。タイムアウトのせいで依然として問題が発生する場合は、NetworkManager-dispatcher.service に対するドロップインファイルを使って、終了後もアクティブ状態を維持するように設定することで問題を回避できます:

/etc/systemd/system/NetworkManager-dispatcher.service.d/remain_after_exit.conf

[Service]
RemainAfterExit=yes

その後、変更した NetworkManager-dispatcher サービスを開始し、かつ有効化してください。

警告: RemainAfterExit 行を追加すると、ディスパッチャが閉じられなくなります。残念ながら、ディスパッチャは、スクリプトを再び実行する前に閉じなければなりません。先の設定により、ディスパッチャはタイムアウトしませんが、閉じられもしません。これは、スクリプトはブート毎に 1 度しか実行されないことを意味します。なので、タイムアウトが実際に問題を起こしていない限り、この行を追加しないでください。

ディスパッチャの例

タイムゾーンを自動的に設定する

tzupdate^AUR をインストールし、以下の実行可能なスクリプトを作成してください:

/etc/NetworkManager/dispatcher.d/update-timezone.sh

#! /bin/bash
# Automatically set time zone when connected to the network
iface=$1
action=$2

if [[ $iface != lo && $action == up ]]; then
    tz=$(tzupdate -s 1 -p 2>/dev/null)
    if [[ -n $tz && -r /usr/share/zoneinfo/$tz ]]; then
	timedatectl set-timezone $tz
    fi
fi

条件式 $iface != lo は、必要に応じて特定のインターフェイスとマッチするように変更してください。

sshfs でリモートディレクトリをマウントする

このスクリプトは非常に制限された環境内で実行されるため、SSH エージェントに接続するためには SSH_AUTH_SOCK 変数をエクスポートする必要があります。これを行う方法はいくつかあります (詳細はこのメッセージを見てください)。以下の例は GNOME Keyring を使って動作し、キーリングがまだアンロックされていない場合はパスワードを要求します。NetworkManager がログイン時に自動的にネットワークに接続するような状況では、gnome-keyring がまだ開始されておらず、変数のエクスポートが失敗する可能性が高いです (そのために sleep コマンドがあります)。接続とマッチする UUID は、nmcli connection status か nmcli connection list を実行すれば確認できます。

#!/bin/sh
USER='username'
REMOTE='user@host:/remote/path'
LOCAL='/local/path'

interface=$1 status=$2
if [ "$CONNECTION_UUID" = "uuid" ]; then
  case $status in
    up)
      # sleep 10
      SSH_AUTH_SOCK=$(find /tmp -maxdepth 1 -type s -user "$USER" -name 'ssh')
      export SSH_AUTH_SOCK
      su "$USER" -c "sshfs $REMOTE $LOCAL"
      ;;
    down)
      fusermount -u "$LOCAL"
      ;;
  esac
fi

SMB 共有をマウントする

SMB 共有は特定のネットワークや場所 (例えば自宅) でしか利用できないことがあります。ディスパッチャを使えば、現在の場所で利用可能な SMB 共有のみをマウントすることができます。

以下のスクリプトは、特定のネットワークに接続していることを確認し、それに応じて共有をマウントします:

/etc/NetworkManager/dispatcher.d/30-mount-smb.sh

#!/bin/sh

# 接続 UUID はターミナルで "nmcli connection show" を実行して確認してください。
# 全種類の NetworkManager 接続がサポートされています: 無線、VPN、有線など。
if [ "$2" = "up" ]; then
  if [ "$CONNECTION_UUID" = "uuid" ]; then
    mount /your/mount/point & 
    # add more shares as needed
  fi
fi

以下のスクリプトは、ソフトウェアが特定のネットワークからの切断を開始する前に、全ての SMB 共有をアンマウントします:

/etc/NetworkManager/dispatcher.d/pre-down.d/30-umount-smb.sh

#!/bin/sh

if [ "$CONNECTION_UUID" = "uuid" ]; then
  umount -a -l -t cifs
fi

ノート: このスクリプトは上記の通り pre-down.d サブディレクトリに配置してください。さもないと、接続状態が変わる度に毎回、全ての共有がアンマウントされてしまいます。

以下のスクリプトは、特定のネットワークから予期せずに切断されてしまった時に、全ての SMB 共有のアンマウントを試みます:

/etc/NetworkManager/dispatcher.d/40-umount-smb.sh

#!/bin/sh

if [ "$CONNECTION_UUID" = "uuid" ]; then
  if [ "$2" = "down" ]; then
    umount -a -l -t cifs
  fi
fi

ノート:

NetworkManager 0.9.8 から、pre-down と down のイベントはシャットダウン時や再起動時に実行されなくなりました。詳細はこのバグレポートを見てください。
上記 2 つの umount スクリプトでは、マウントに実際にアクセスしているアプリケーションが 'ハング' してしまう傾向が依然としてあります。

代替案は、NFS#NetworkManager dispatcher を使うにあるスクリプトを使うことです:

/etc/NetworkManager/dispatcher.d/30-smb.sh

#!/bin/sh

# 接続 UUID はターミナルで "nmcli connection show" を実行して確認してください。
# 全種類の NetworkManager 接続がサポートされています: 無線、VPN、有線など。
WANTED_CON_UUID="CHANGE-ME-NOW-9c7eff15-010a-4b1c-a786-9b4efa218ba9"

if [ "$CONNECTION_UUID" = "$WANTED_CON_UUID" ]; then
    
    # スクリプトパラメータ $1: ネットワークインターフェイス名 (未使用)
    # スクリプトパラメータ $2: ディスパッチされたイベント
    
    case "$2" in
        "up")
            mount -a -t cifs
            ;;
        "down"|"pre-down"|"vpn-pre-down")
            umount -l -a -t cifs >/dev/null
            ;;
    esac
fi

ノート: このスクリプトは noauto オプションのマウントは無視します。これらのマウントをディスパッチャが管理できるようにするには、このオプションを取り除くか、auto を使ってください。

pre-down イベントをキャッチできるようにするために /etc/NetworkManager/dispatcher.d/pre-down/ 内にシンボリックリンクを作成してください:

# ln -s ../30-smb.sh /etc/NetworkManager/dispatcher.d/pre-down.d/30-smb.sh

NFS 共有をマウントする

NFS#NetworkManager dispatcher を使うを見てください。

ディスパッチャを使って、LAN ケーブルが挿入されているかに応じて Wi-Fi を自動的にオンオフする

アイディアとしては、LAN ケーブルが抜かれた時にのみ Wi-Fi をオンにし (例えば、ラップトップのドックから取り外された時など)、LAN ケーブルが挿入されたら Wi-Fi を自動的に無効化します。

以下のディスパッチャスクリプト[6]を作成してください。LAN_interface の部分はあなたの LAN インターフェイスに置き換えてください。

コンピュータがオンの時に LAN インターフェイスが接続され、コンピュータがオフの時に切断された場合のフェイルセーフがあることに注意してください。このフェイルセーフがないと、コンピュータがオンに戻っても Wi-Fi は依然としてオフであり、LAN インターフェイスが切断されていれば、ネットワーク接続が利用できなくなってしまいます。

/etc/NetworkManager/dispatcher.d/wlan_auto_toggle.sh

#!/bin/sh

if [ "$1" = "LAN_interface" ]; then
    case "$2" in
        up)
            nmcli radio wifi off
            ;;
        down)
            nmcli radio wifi on
            ;;
    esac
elif [ "$(nmcli -g GENERAL.STATE device show LAN_interface)" = "20 (unavailable)" ]; then
    nmcli radio wifi on
fi

ノート: nmcli を使えばインターフェイスの一覧を得られます。イーサネット (LAN) インターフェイスの名前は en で始まります (例: enp0s5)。

ディスパッチャを使って、ネットワーク接続が確立された後に VPN に接続する

この例では、特定の Wi-Fi ネットワークに接続した後に、以前定義された VPN 接続に自動的に接続したいと思います。最初にすべきことは、そのネットワークに接続した後にすることを定義するディスパッチャスクリプトを作成することです。

この記事またはセクションの正確性には問題があります。

理由: A scripting without iwgetid does work too and may be more reliable? (議論: en:Talk:NetworkManager#Fixes for automatic VPN dispatcher script) (議論: トーク:NetworkManager#)

ノート: このスクリプトでは iwgetid を使うために wireless_tools を必要とします。

/etc/NetworkManager/dispatcher.d/vpn-up

#!/bin/sh
VPN_NAME="NetworkManager に定義されている VPN 接続の名前"
ESSID="Wi-Fi ネットワークの ESSID (接続名ではない)"

interface=$1 status=$2
case $status in
  up|vpn-down)
    if iwgetid | grep -qs ":\"$ESSID\""; then
      nmcli connection up id "$VPN_NAME"
    fi
    ;;
  down)
    if iwgetid | grep -qs ":\"$ESSID\""; then
      if nmcli connection show --active | grep "$VPN_NAME"; then
        nmcli connection down id "$VPN_NAME"
      fi
    fi
    ;;
esac

全ての Wi-Fi ネットワークで VPN への接続を試みたい場合は、次の ESSID 定義を使用できます: ESSID=$(iwgetid -r)。スクリプトのパーミッションを適宜設定することを忘れないでください。

VPN の機密情報が保管される方法により、上記のスクリプトで VPN への接続しようとしても、NetworkManager-dispatcher.service が 'no valid VPN secrets' というエラーで失敗する場合があります。幸運なことに、スクリプトから VPN のパスワードにアクセスする方法は他にもあります。

1: それらの方法の1つでは、VPN 接続の設定ファイルを編集して、root からはアクセスできないキーリングではなく自身で機密情報を保存させるように NetworkManager を設定する必要があります: /etc/NetworkManager/system-connections/VPN接続の名前 を開き、password-flags と secret-flags を 1 から 0 に変更してください。

それだけではうまく行かない場合は、以下の内容で passwd-file を安全な場所にディスパッチャスクリプトと同じパーミッションと所有権で作成する必要があるかもしれません:

/path/to/passwd-file

vpn.secrets.password:パスワード

ファイルからパスワードを得られるようにするために、スクリプトは適宜変更する必要があります:

/etc/NetworkManager/dispatcher.d/vpn-up

#!/bin/sh
VPN_NAME="NetworkManager に定義されている VPN 接続の名前"
ESSID="Wi-Fi ネットワークの ESSID (接続名ではない)"

interface=$1 status=$2
case $status in
  up|vpn-down)
    if iwgetid | grep -qs ":\"$ESSID\""; then
      nmcli connection up id "$VPN_NAME" passwd-file /path/to/passwd-file
    fi
    ;;
  down)
    if iwgetid | grep -qs ":\"$ESSID\""; then
      if nmcli connection show --active | grep "$VPN_NAME"; then
        nmcli connection down id "$VPN_NAME"
      fi
    fi
    ;;
esac

2: あるいは、password-flags を変更して、設定ファイル内に vpn-secrets セクションを追加してパスワードを直接書き込むという方法もあります:

 [vpn]
 ....
 password-flags=0
 
 [vpn-secrets]
 password=パスワード

ノート: NetworkManager の接続エディタを再び開き、VPN のパスワード/機密情報を保存し直す必要があるかもしれません。

ディスパッチャを使って、VPN プロバイダの接続時に IPv6 を無効化する

多くの商用 VPN プロバイダーは IPv4 のみをサポートしています。つまり、IPv6 のトラフィックは全て VPN をバイパスし、事実上、使い物にならなくなります。ディスパッチャを使って、VPN に接続されている時は全ての IPv6 トラフィックを無効化することで、この問題を回避できます。

/etc/NetworkManager/dispatcher.d/10-vpn-ipv6

#!/bin/sh

case "$2" in
	vpn-up)
		echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
		;;
	vpn-down)
		echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6
		;;
esac

代替案としては、ディスパッチャを使って、VPN 接続に使用しているデバイスの IPv6 モードを一時的に link-local に設定することもできます。これにより、NetworkManager が、IPv6 が無効化されていることについて警告をログに大量出力することを防ぐことができます。このスクリプトは、複数のデバイスや接続が IPv6 接続を提供している場合、動作しません。しかし、複数のデバイスを反復させることで応用することができます。注意点として、接続に対して何らかの変更が加えられた場合 (nmcli(1) やデスクトップ環境の機能を使った場合)、そのデバイスに対する接続全体が再適用され、IPv6 が再有効化されます (その接続で有効化されている場合)。

/etc/NetworkManager/dispatcher.d/10-vpn-ipv6

#!/bin/sh

case "$2" in
	vpn-up)
		nmcli device modify "${DEVICE_IFACE}" ipv6.method link-local
		;;
	vpn-down)
		nmcli device reapply "${DEVICE_IFACE}"
		;;
esac

OpenNTPD

OpenNTPD#NetworkManager dispatcher を使うを参照してください。

systemd-timesyncd で DHCP 経由で受信した NTP サーバを動的に設定する

異なるネットワーク間 (例: 会社の LAN、自宅の Wi-Fi、その他の様々な Wi-Fi) でローミングする場合、timesyncd によって使用されている NTP サーバを DHCP によって提供されているものに設定したい場合があります。ただし、NetworkManager 自体は systemd-timesyncd と通信して NTP サーバを設定することはできません。

ディスパッチャを使うことで、この問題を回避できます。

systemd-timesyncd の設定ようのオーバーレイディレクトリ /etc/systemd/timesyncd.conf.d を作成してください (まだ存在していない場合)。/etc/NetworkManager/dispatcher.d 内に以下を追加してください:

/etc/NetworkManager/dispatcher.d/10-update-timesyncd

#!/bin/sh

[ -z "$CONNECTION_UUID" ] && exit 0
INTERFACE="$1"
ACTION="$2"

case $ACTION in
up | dhcp4-change | dhcp6-change)
	[ -n "$DHCP4_NTP_SERVERS" ] || exit 0
	mkdir -p /etc/systemd/timesyncd.conf.d
	cat <<-THE_END >"/etc/systemd/timesyncd.conf.d/${CONNECTION_UUID}.conf"
		[Time]
		NTP=$DHCP4_NTP_SERVERS
	THE_END
	systemctl restart systemd-timesyncd.service
	;;
down)
	rm -f "/etc/systemd/timesyncd.conf.d/${CONNECTION_UUID}.conf"
	systemctl restart systemd-timesyncd.service
	;;
esac

NetworkManager が新しいネットワーク接続を設定する (ACTION=up) か、既存の接続の更新を取得する (ACTION=dhcp4-change または ACTION=dhcp6-change) 度に、接続データに NTP サーバ (DHCP4_NTP_SERVERS) に関する情報が含まれていると、接続固有のオーバーレイ設定ファイルが /etc/systemd/timesyncd.conf.d に書き込まれ、このファイルには、提供された NTP サーバ (1台または複数) の情報が記述されます。提供された NTP サーバが含まれます。接続が停止される (ACTION=down) と、接続固有のオーバーレイファイルは削除されます。systemd-timesyncd の設定が変更されるたびに、サービスは再起動され、更新された設定を取得します。NetworkManager で 2つ以上の接続を並行して管理する場合、up、dhcp4-change、dhcp6-change、そして down アクションが任意の順序で来るかもしれないので、設定内の異なる NTP サーバ名が上書きされないように接続固有の設定ファイルを意図的に使用しています。

テスト

NetworkManager アプレットはログイン時にロードされるようになっているので、ほとんどのユーザにとって追加の設定は必要ないはずです。以前のネットワーク設定を無効化し、ネットワークから切断されているならば、NetworkManager が動作するかどうかをテストできます。まず始めに、NetworkManager.service を起動してください。

一部のアプレットは、NetworkManager アプレットをアプリケーションメニューからロードできるようにするために、.desktop ファイルを提供しています。デスクトップファイルが提供されていない場合は、アプレットを使用するためのコマンドを見つけるか、アプレットをロードするために一度ログアウトして再度ログインする必要があります。アプレットが開始されれば、DHCP サーバを使って自動設定によるネットワーク接続のポーリングが開始されるでしょう。

awesome などの XDG 非互換のウィンドウマネージャで GNOME のアプレットを開始するには:

nm-applet --sm-disable &

固定 IP アドレスの場合は、NetworkManager にそのことを伝えなければなりません。手順としては通常、アプレットを右クリックし、'接続を編集する' ('Edit Connections') などのような項目を選択します。

ヒントとテクニック

Wi-Fi パスワードの暗号化

デフォルトでは、NetworkManager はパスワードを平文で /etc/NetworkManager/system-connections/ 内の設定ファイルに保存します。保存されているパスワードを表示するには、以下のコマンドを使ってください:

# grep -r '^psk=' /etc/NetworkManager/system-connections/

パスワードは root ユーザからファイルシステムでアクセス可能であり、さらに GUI (例: nm-applet) を通して設定にアクセスできるユーザからもアクセス可能です。

パスワードは、平文ではなく、キーリングの中で暗号化された形で保存するのが望ましいです。しかし、これの欠点は、それぞれのユーザで接続をセットアップしなけれならないことです。

キーリングを読み書きするために、利用可能なシークレットエージェントが存在していなければなりません。いかのどれかを使用できます:

nmcli で --ask オプションを使う。
#フロントエンドに挙げられているグラフィカルインターフェイス

シークレットエージェントが利用できないと、no secrets: No agents were available for this request. というエラーで認証が失敗します。

GNOME Keyring を使う

以下の方法を使うには、GNOME Keyring のキーリングデーモンが開始されていて、キーリングがアンロックされている必要があります。

さらに、全ユーザのパスワードを保存しないように NetworkManager を設定する必要があります。GNOME の network-manager-applet を使って、ターミナルから nm-connection-editor を実行し、ネットワーク接続を選択し、編集 (Edit) をクリックし、Wi-Fi セキュリティー (Wi-Fi Security) タブを選択し、パスワード入力欄の右のアイコンをクリックして、このユーザーのパスワードのみ保存する (Store the password only for this user) にチェックを入れてください。

KDE Wallet を使う

KDE の plasma-nm を使う場合、アプレットをクリックし、右上の設定アイコンをクリックし、ネットワーク接続を選択し、一般設定 (General configuration) タブを選択し、すべてのユーザはこのネットワークに接続可能 (All users may connect to this network) のチェックを外してください。このオプションにチェックが入っていると、たとえキーリングデーモンが実行されていたとしても、パスワードが平文で保存されてしまいます。

以前このオプションにチェックが入っていて、後にチェックを外した場合、ファイルからパスワードを消すために reset オプションを使用する必要がある場合があります。あるいは、接続を削除し、再度セットアップしてください。

Wi-Fi でインターネット接続を共有する

数クリックでインターネット接続 (例: 3G、有線) を共有することができます。ただし、ファイアウォールはインターネット共有を妨害する場合があることに注意してください。

AP モードをサポートする Wi-Fi カードが必要になります。詳細はソフトウェアアクセスポイント#Wi-Fi デバイスが AP モードをサポートしていることを見てください。

接続を共有できるようにするために dnsmasq パッケージをインストールしてください。NetworkManager は (dnsmasq.service とは独立に) 独自の dnsmasq インスタンスを DHCP サーバとして開始することに注意してください。これに関する注意事項は #dnsmasq を見てください。

共有された接続を作成してください:

アプレットをクリックし、新規 Wi-Fi ネットワークを作成 (Create new wireless network) を選んでください。
ウィザードに従ってください (WPA2 以上を選んでください。パスワードは 8 文字以上にしてください。さもないと失敗します)。
Wi-Fi モードとしてホットスポットかアドホックを選択してください。

これで、次回必要になるときのために接続は保存されます。

ノート: Android はアドホックネットワークへの接続をサポートしていません。Android と接続を共有するには、インフラストラクチャモードを使用してください (つまり、Wi-Fi モードを "ホットスポット" に設定する)。

イーサネットでインターネット接続を共有する

シナリオ: デバイスが Wi-Fi 経由でインターネットに接続されていて、イーサネットで他のデバイスとインターネット接続を共有したいと考えている場合。

要件:

接続を共有できるようにするために dnsmasq パッケージと nm-connection-editor パッケージをインストールしてください。NetworkManager は (dnsmasq.service とは独立に) 独自の dnsmasq インスタンスを DHCP サーバとして開始することに注意してください。これに関する注意事項は #dnsmasq を見てください。
インターネットに接続されたデバイスとその他のデバイスが適切なイーサネットケーブルで接続されていること (これは通常、間をクロスオーバーケーブルやスイッチで繋ぐことを意味します)。
インターネット共有がファイアウォールによってブロックされていないこと。

手順:

ターミナルから nm-connection-editor を実行してください。
新しいイーサネット接続を追加してください。
何かわかりやすい名前を付けてください。例えば "Shared Internet"。
"IPv4 設定" ("IPv4 Settings") を開いてください。
"メソッド:" ("Method:") で "他のコンピューターへ共有" ("Shared to other computers") を選択してください。
保存

これで、NetworkManager の有線接続に "Shared Internet" という新しいオプションができたはずです。

cron ジョブやスクリプトでネットワークが立ち上がっているか確認する

この記事またはセクションは情報が古くなっています。

理由: nm-tool は NetworkManager から削除されました [7]。代わりに nmcli を使用するべきです。 (Discuss)

一部の cron ジョブではネットワークが立ち上がっている必要があり、ネットワークが落ちている状態でそのようなジョブを実行したくない場合があります。そうするには、NetworkManager の nm-tool にクエリして、ネットワークの状態をチェックする if テストを追加してください。このテストは、何らかのインターフェイスが立ち上がっていれば成功し、インターフェイスが全て落ちている場合は失敗します。これは、ある時は有線接続されていて、ある時は無線で、またある時はネットワークから切断されているようなノート PC で便利です。

if [ $(nm-tool|grep State|cut -f2 -d' ') == "connected" ]; then
    # ネットワークがオンラインの時に実行したいコード
else
    # ネットワークがオフラインの時に実行したいコード (注記: この部分と上の else は任意です)
fi

これは、例えば F-Prot ウイルススキャナのシグネチャを更新するために fpupdate を実行する cron.hourly で便利です。また、nm-tool の出力の様々な部分を使えば、ネットワークを識別することもできます。例えば、アクティブなワイヤレスネットワークにはアスタリスクが付くので、ネットワーク名を grep して、その後でアスタリスクを grep しますs。

ブート時にシークレットを使ってネットワークに接続する

デフォルトでは、NetworkManager はシークレットを要求するネットワークにはブート時に自動的に接続しません。NetworkManager では、そのようなネットワークは、そのネットワークをデフォルトで使用するユーザがログインした後にのみ、接続されるからです。この動作を変更するには、以下を行ってください:

パネルの nm-applet のアイコンを右クリックし、"接続を編集する" を選択し、Wi-Fi タブを開いてください。
使いたい接続を選択し、編集ボタンをクリックしてください。
“Connect Automatically” と “Available to all users” のボックスにチェックを入れてください。
加えて、"Wi-Fi Security" タブで "Store password for all users (not encrypted)" が選択されていることを確認してください。

ログアウトし、ログインし直せば完了です。

OpenConnect で KWallet 内のパスワードを使う

接続時にユーザ名とパスワードを入力することはできますが、plasma-nm 0.9.3.2-1 から、KWallet から直接 OpenConnect のユーザ名とパスワードを取得することが可能になりました。

"KDE Wallet Manager" を開き、"Network Management|Maps" で対象の OpenConnect VPN 接続を見つけてください。"Show values" をクリックし、認証情報を以下の形式で "VpnSecrets" に入力してください (ユーザ名 と パスワード の部分は適宜置き換えてください):

form:main:username%SEP%ユーザ名%SEP%form:main:password%SEP%パスワード

次回の接続時に、ユーザ名とパスワードが "VPN secrets" ダイアログボックスに入力されるはずです。

特定のデバイスを無視する

NetworkManager で特定のデバイスを無視し、そのデバイスに対してはアドレスとルート (route) の設定を試みないようにすることが望ましい場合があります。/etc/NetworkManager/conf.d/unmanaged.conf で以下のオプションを使うことで、MAC またはインターフェイス名によって特定のデバイスを無視することができます:

[keyfile]
unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth0

ファイルを編集したら、nmcli general reload を root として実行してください。その後、NetworkManager があなたの設定を変更することなく、インターフェイスを構成できるようになっているはずです。

MAC アドレスのランダム化を設定する

ノート: (安定した) リンク接続[8]や、MAC アドレスに基づいてデバイスを制限したりネットワーク容量に制限を設けているネットワークへの接続には、MAC アドレスのランダム化を無効化する必要がある場合があります。

MAC アドレスのランダム化は、本物の MAC アドレスをネットワークに開示しないことで、プライバシーを向上させることができます。

NetworkManager は2種類の MAC アドレスランダム化をサポートしています: スキャン中のランダム化とネットワーク接続におけるランダム化です。どちらのモードも、/etc/NetworkManager/NetworkManager.conf を変更するか、/etc/NetworkManager/conf.d/ 内に別の設定ファイルを作成することで設定できます (前者は NetworkManager によって上書きされる場合があるので、後者が推奨されます)。

Wi-Fi スキャン中のランダム化はデフォルトで有効化されていますが、以下の行を /etc/NetworkManager/NetworkManager.conf か /etc/NetworkManager/conf.d 内の別の設定ファイルに追加することで無効化することができます:

/etc/NetworkManager/conf.d/wifi_rand_mac.conf

[device]
wifi.scan-rand-mac-address=no

ネットワーク接続における MAC アドレスランダム化は、無線インターフェイスとイーサネットインターフェイスで別々のモードを設定することができます。モードに関する詳細は GNOME のブログ記事を参照してください。

MAC アドレスランダム化に関して、最も重要なモードは stable と random です。stable は、新しいネットワークに接続した時にランダムな MAC アドレスを生成し、そのネットワークと MAC アドレスを永続的に関連付けます。これはつまり、そのネットワークに接続すると毎回同じ MAC アドレスが使用されることを意味します。それとは対照的に、random は、ネットワークに接続する度に、そのネットワークが新しかろうが既知であろうが、新しい MAC アドレスを生成します。/etc/NetworkManager/conf.d 内に設定ファイルを追加してこの MAC アドレスランダム化を設定することができます:

/etc/NetworkManager/conf.d/wifi_rand_mac.conf

[device-mac-randomization]
# "yes" は既にスキャンにおけるデフォルトです。
wifi.scan-rand-mac-address=yes
 
[connection-mac-randomization]
# 全てのイーサネット接続に対して MAC をランダム化する
ethernet.cloned-mac-address=random
# 各 Wi-Fi に対してランダムな MAC を生成し、それらを関連付ける。
wifi.cloned-mac-address=stable

詳細は GNOME ブログ記事を参照してください。

IPv6 プライバシー拡張を有効にする

IPv6#NetworkManager を参照してください。

接続ごとに一意の DUID を設定する

DHCPv6 Unique Identifier (DUID) は、DHCPv6 クライアントが DHCPv6 サーバに対して自身を識別するために使用する値です。NetworkManager は3種類の DUID をサポートしています:

DUID-UUID (RFC 6355): Universally Unique IDentifier (UUID) から生成されます。
DUID-LL (RFC 3315): リンク層アドレス (別名 MAC アドレス) から生成されます。
DUID-LLT (RFC 3315): リンク層アドレスとタイムスタンプから生成されます。

NetworkManager の内部 DHCP クライアントが使用されている場合 (デフォルト)、machine-id (/etc/machine-id) から生成されたグローバルで永続的な DUID-UUID で自身を識別します。これは、すべての接続が同じ UUID を共有することを意味し、プライバシーの侵害となる可能性があります。

幸いなことに、NetworkManager は、接続の stable-id とホストごとの一意のキーから派生した、接続ごとの一意の DUID を提供できます。/etc/NetworkManager/conf.d 内に次の設定を追加することで、これを有効にすることができます:

/etc/NetworkManager/conf.d/duid.conf

[connection]
ipv6.dhcp-duid=stable-uuid

stable-ll および stable-llt の値もサポートされています。詳細については、nm-settings(5) § ipv6 setting の dhcp-duid の説明を参照してください。

有線接続の操作

NetworkManager は、デフォルトで、有線イーサネット接続を検出するたびにそれぞれに対して接続プロファイルを生成します。接続を生成する時点では、利用可能なイーサネットアダプターがさらにあるかどうかはわかりません。そのため、最初の有線接続は "有線接続 1" となります。no-auto-default (NetworkManager.conf(5) を参照) を設定するか、単に削除することで、この接続を生成しないようにできます。そうすれば、NetworkManager はこのインターフェイスの接続を二度と生成しないように記憶します。

また、接続を編集 (およびディスクに永続化) したり、削除したりすることもできます。NetworkManager は新しい接続を再生成することはありません。それから、名前を好きなものに変更することができます。この作業には nm-connection-editor などを使うことができます。

Wi-Fi バックエンドとして iwd を使用する

ノート:

iwd.service を有効化したり、iwd を手動で構成したりしないでください。NetworkManager は自身で iwd を開始し、管理します。
iwd に切り替える前に、既知の問題を考慮してください。

実験的な iwd バックエンドを有効化するには、iwd をインストールしてから、以下の設定ファイルを作成してください:

/etc/NetworkManager/conf.d/wifi_backend.conf

[device]
wifi.backend=iwd

または、networkmanager-iwd^AUR をインストールすることもできます。これは、iwd のみで動作する NetworkManager をビルドするように設定された修正パッケージです。主な違いは、iwd が必要であり、wpa_supplicant はビルド後にアンインストールできることです。

ノート: iwd に切り替えた後、既存の NetworkManager ネットワークプロファイルを変換する必要がある場合があります。

ネットワーク名前空間内で実行する

ネットワーク名前空間内で NetworkManager を実行する場合 (たとえば、選択したアプリケーションで使用する必要がある特定のデバイスを管理する場合)、その名前空間に移動させる前にデバイスを落としてください:

$ ip link set dev MY_DEVICE down
$ ip link set dev MY_DEVICE netns MY_NAMESPACE
$ ip netns exec MY_NAMESPACE NetworkManager
...
$ ip netns exec MY_NAMESPACE killall NetworkManager

そうしないと、NetworkManager は後で device is strictly unmanaged エラーにより接続の確立に失敗します。

VPN に自動的に接続する

NetworkManager は、インターネットへの接続時に VPN に自動的に接続するように (ネットワーク毎に) 設定できます。VPN 接続自体は、GNOME の NetworkManager フロントエンドで追加できますが、VPN を自動的に使用するようにするには、nmcli を使用しなければなりません。他のフロントエンドにはこの制限はない場合があります。

まず、対象の VPN が全ユーザで利用可能であることを確認してください。GNOME では、details タブ内のあるボックスにチェックを入れれば良いです。Identity タブのパスワード入力欄内の右側にあるアイコンをクリックし、Store the password for all users を選択してください。

そして、VPN 接続の UUID を見つけ、インターネット接続の connection.secondaries にその UUID を追加してください:

# UUID=$(nmcli --get-values connection.uuid connection show VPN接続の名前)
# nmcli connection modify インターネット接続の名前 connection.secondaries "$UUID"

NetworkManager を再起動して、設定したインターネット接続に接続したら、自動的に VPN に接続されるようになっているはずです。

トラブルシューティング

セキュアな Wi-Fi ネットワークのパスワードプロンプトが表示されない

セキュアな Wi-Fi ネットワークに接続しようとすると、パスワードのプロンプトが表示されず、接続が確立されません。これは、キーリングのパッケージがインストールされていない時に起こります。簡単な解決法は、gnome-keyring をインストールすることです。パスワードを暗号化して保存したい場合は、GNOME Keyring に書かれてある指示に従い、gnome-keyring-daemon をセットアップしてください。

Network management disabled

時々、NetworkManager を終了したときに pid (state) ファイルが削除されずに Network management disabled というメッセージが表示されることがあります。これが発生した場合は、そのファイルを手動で削除してください:

# rm /var/lib/NetworkManager/NetworkManager.state

内蔵 DHCP クライアントに関する問題

内臓の DHCP クライアントを使用すると IP アドレスの取得に問題が発生する場合、他の DHCP クライアントを使用することを検討してください (手順は #DHCP クライアントを見てください)。この回避策は、eduroam などの巨大なワイヤレスネットワークにおける問題を解決するかもしれません。

dhclient における DHCP の問題

DHCP での IP アドレス取得に問題が発生する場合、以下を /etc/dhclient.conf に追加してみてください:

 interface "eth0" {
   send dhcp-client-identifier 01:aa:bb:cc:dd:ee:ff;
 }

aa:bb:cc:dd:ee:ff は NIC の MAC アドレスです。この MAC アドレスは iproute2 パッケージの ip link show インターフェイス コマンドを使って確認できます。

3G モデムが検知されない

USB 3G モデム#NetworkManager を参照してください。

ノートパソコンで WLAN をオフにする

時々、ノートパソコンに付いているスイッチを使って Wi-Fi アダプタを無効化し、再び有効化しようとすると NetworkManager が機能しなくなることがあります。これは、しばしば rfkill の問題であることがあります。ドライバが rfkill にワイヤレスアダプタの状態について通知しているかどうか確認するには、以下のコマンドを使ってください:

$ watch -n1 rfkill list all

アダプタを切り替えた後にどれかの識別子がブロックされたままになる場合、手動でアンロックしてみることができます (X の部分は、上記のコマンドで得られた識別子の番号です):

# rfkill event unblock X

固定 IP アドレスの設定が DHCP に戻る

とある未解決のバグにより、デフォルトの接続を固定 IP アドレスに変更すると、nm-applet が設定の変更を適切に保存せずに、自動 DHCP に戻ってしまいます。

この問題を回避するには、nm-applet でデフォルトの設定 (例: "Auto eth0") を編集し、接続名を変更 (例: "my eth0") し、"Available to all users" チェックボックスのチェックを外し、固定 IP アドレスの設定を好きに変更し、Apply をクリックしてください。これで、指定した名前で新しい接続が保存されます。

そうしたら、デフォルトの接続に自動的に接続しないようにしたいと思うでしょう。そうするには、まず nm-connection-editor を実行してください (root としてではありません)。接続エディタで、デフォルトの接続 (例: "Auto eth0") を編集し、"Connect automatically" のチェックを外してください。Apply をクリックし、接続エディタを閉じてください。

通常ユーザとして接続を編集できない

#PolicyKit のパーミッションをセットアップするを参照してください。

隠されたワイヤレスネットワークを削除する

隠されたネットワークはワイヤレスの選択リストに表示されないので、GUI から削除することができません。以下のコマンドでそのようなネットワークを削除できます:

# rm /etc/NetworkManager/system-connections/SSID

これは、他の接続でも使えます。

VPN が GNOME で動作しない

GNOME を使用している時に NetworkManager で OpenConnect や vpnc の接続をセットアップすると、ダイアログボックスが表示されず、以下のエラーが /var/log/errors.log に現れることがあります:

localhost NetworkManager[399]: <error> [1361719690.10506] [nm-vpn-connection.c:1405] get_secrets_cb(): Failed to request VPN secrets #3: (6) No agents were available for this request.

これは、GNOME NetworkManager Applet が、ダイアログスクリプトが /usr/lib/gnome-shell にあると想定していることが原因です (NetworkManager のパッケージはダイアログスクリプトを /usr/lib/networkmanager 内に置きます)。"一時的な" 修正として (このバグはしばらく前から存在しています)、以下のシンボリックリンクを作成してください:

OpenConnect の場合: ln -s /usr/lib/networkmanager/nm-openconnect-auth-dialog /usr/lib/gnome-shell/
VPNC (つまり Cisco VPN) の場合: ln -s /usr/lib/networkmanager/nm-vpnc-auth-dialog /usr/lib/gnome-shell/

これは、他の NetworkManager VPN プラグインでも行う必要がある場合がありますが、上記が最も一般的です。

検出されてはいるのにヨーロッパのワイヤレスネットワークに接続できない

WLAN チップにはデフォルトの規制範囲が設定されています。アクセスポイントがその規制内で動作しない場合、そのネットワークに接続することはできません。これは簡単に解決できます:

wireless-regdb をインストールしてください。
/etc/conf.d/wireless-regdom で適切な国名コードをアンコメントしてください。
システムを再起動してください。この設定はブート時にしか読み込まれないからです。

ブート時の VPN への自動接続が機能しない

この問題は、システム (つまり、root ユーザとして動作している NetworkManager) が VPN 接続を確立しようと試みたが、パスワードが特定のユーザの GNOME Keyring 内に保存されているためにアクセスできなかった場合に発生します。

解決策は、#ディスパッチャを使って、ネットワーク接続が確立された後に VPN に接続するの手順 2 で説明されている通りに、VPN のパスワードを平文で保存することです。

nm-applet GUI で新しい "auto-connect VPN" オプションを使用している場合は、自動接続するために手順 1 で説明されているディスパッチャを使用する必要はありません。

Systemd のボトルネック

時が立つにつれてログファイル (/var/log/journal) が膨大になってしまうことがあります。そうすると NetworkManager を使う場合にブートパフォーマンスに大きな影響を与えます。参照: systemd#少しづつ起動時間が長くなっている。

定期的なネットワーク接続断、遅延、パケットロス (WiFi)

NetworkManager は2分ごとにスキャンを行います。

一部の WiFi ドライバは、接続/アソシエーション中にベースステーションのスキャンを行うと問題が発生します。症状としては、VPN 接続断/再接続、パケットロス、ウェブページのロードに失敗してリフレッシュすると良くなるなどがあります。

journalctl -f を root として実行すると、スキャンが行われていることがわかります。以下のようなメッセージが定期的にログに現れます:

NetworkManager[410]: <info>  (wlp3s0): roamed from BSSID 00:14:48:11:20:CF (my-wifi-name) to (none) ((none))

ローミングが重要でないならば、WiFi 接続プロファイルでアクセスポイントの BSSID をロックすることにより、定期的なスキャンの挙動を無効化することができます。

Lenovo ラップトップ (IdeaPad、Legion など) で Wi-Fi をオンにできない

これは、Wi-Fi ドライバがソフトブロックを誤って報告することによる、一部の Lenovo モデルにおける ideapad_laptop モジュールの問題です。カードは依然として netctl で操作できますが、NetworkManager などのマネージャーは機能しません。この問題が発生しているかどうかを確認するには、ハードウェアのスイッチをオンオフしたあとで rfkill list の出力を確認し、ソフトブロックされ続けるかどうか確認してください。

この記事またはセクションの正確性には問題があります。

理由: rfkill の問題を解決するには、rfkill.default_state と rfkill.master_switch_mode を使用してみてください (kernel-parameters.html を参照))。 (議論: トーク:NetworkManager#)

ideapad_laptop モジュールをアンロードすれば、この問題は解決するはずです。(警告: これにより、ラップトップのキーボードとタッチパッドも無効になる可能性があります!)

ホスト名の送信をオフにする

NetworkManager はデフォルトでホスト名を DHCP サーバに送信します。ホスト名の送信は、グローバルには無効化できず、接続毎にしか無効化できません (Issue #584)。

特定の接続で DHCP サーバへのホスト名の送信を無効化するには、以下をネットワークの設定ファイルに追加してください:

/etc/NetworkManager/system-connections/your_connection_file

...
[ipv4]
dhcp-send-hostname=false
...
[ipv6]
dhcp-send-hostname=false
...

nm-applet が i3wm で消える

通知に xfce4-notifyd.service を使用する場合は、そのユニットを編集して、以下を追加する必要があります:

/etc/systemd/user/xfce4-notifyd.service.d/display_env.conf

[Service]
Environment="DISPLAY=:0.0"

デーモンをロードし直したら、xfce4-notifyd.service を再起動してください。i3 を終了し、再び起動すると、アプレットがトレイに表示されているはずです。

Unit dbus-org.freedesktop.resolve1.service not found

systemd-resolved.service が開始されていない場合、NetworkManager は D-Bus を使用して開始しようとし、失敗します:

dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")
dbus-daemon[991]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.
dbus-daemon[991]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='dbus-org.freedesktop.resolve1.service' requested by ':1.23' (uid=0 pid=1012 comm="/usr/bin/NetworkManager --no-daemon ")

これは、NetworkManager が NetworkManager.conf(5) の main.dns= 設定に関係なく、DNS 情報を systemd-resolved に送信しようとするためです。[9]

これは、/etc/NetworkManager/conf.d/ 内の設定ファイルで無効にできます:

/etc/NetworkManager/conf.d/no-systemd-resolved.conf

[main]
systemd-resolved=false

FS#62138 を参照してください。

Secrets were required, but not provided

ネットワークに接続しようとして以下のエラーが発生する場合:

$ nmcli device wifi connect SSID password パスワード

Error: Connection activation failed: (7) Secrets were required, but not provided

このエラーの原因となりうるものはたくさんあり、journal を読む必要があります (-u NetworkManager で出力をフィルタしてください)。例えば、接続の確立に時間がかかりすぎると、NetworkManager はパスワードが正しくなかったと結論づけます:

NetworkManager[1372]: <warn>  [1643991888.3808] device (wlan0): Activation: (wifi) association took too long
NetworkManager[1372]: <info>  [1643991888.3809] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
NetworkManager[1372]: <warn>  [1643991888.3838] device (wlan0): Activation: (wifi) asking for new secrets

接続プロファイルを削除し、新しいプロファイルを作成してみてください:

$ nmcli connection delete SSID
$ nmcli device wifi connect SSID password パスワード

また、MAC アドレスランダム化を無効化してみるのも良いでしょう:

/etc/NetworkManager/conf.d/wifi_rand_mac.conf

[device]
wifi.scan-rand-mac-address=no

iwd での WPA Enterprise 接続

iwd バックエンドと NetworkManager で 'eduroam' などの WPA Enterprise ネットワークに接続しようとした際に、NetworkManager sで以下のエラーが発生します:

 Connection 'eduroam' is not avialable on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)

NetworkManager は WPA Enterprise ネットワークを設定できないことが原因です。なので、iwd#WPA Enterprise で説明されているように iwd の設定ファイル /var/lib/iwd/essid.8021x を使って設定する必要があります。

Failed to request VPN secrets

以下のエラーが発生する場合:

Failed to request VPN secrets #1: No agents were available for this request.

パスワードが空であるか、PolicyKit のパーミッションをセットアップする必要があるかのどちらかです。

OpenSSL の "ca md too weak" エラーで OpenVPN の接続に失敗する

openssl がバージョン3に更新されたため、レガシーな暗号化アルゴリズムで生成された証明書はデフォルトで拒否されます。このような設定で networkmanager-openvpn を使用しようとすると、ログに次のエラーが記録される可能性があります:

nm-openvpn[14359]: OpenSSL: error:0A00018E:SSL routines::ca md too weak
nm-openvpn[14359]: Cannot load certificate file /home/archie/.local/share/networkmanagement/certificates/my_issued_cert.crt
nm-openvpn[14359]: Exiting due to fatal error

正しいアプローチは、OpenVPN サーバの管理者に、より安全な証明書を生成して再発行してもらうことです。ただし、当面の回避策として、OpenVPN には tls-cipher "DEFAULT:@SECLEVEL=0" が必要です。この設定は、プラグイン GUI からでは無理かもしれませんが、nmcli からなら可能です。これとは別に、OpenSSL でレガシーなプロバイダを有効化する必要もあります。

まず、以下のコマンドの出力から、問題のある VPN 接続の名前を取得してください:

$ nmcli connection show

接続の名前は vpn.example.com であると仮定します。以下のように nmcli を使ってください:

$ nmcli connection modify vpn.example.com +vpn.data tls-cipher=DEFAULT:@SECLEVEL=0

変更は即座に /etc/NetworkManager/system-connections/vpn.example.com.nmconnection に反映されるはずです。

OpenSSL に関しては、OpenSSL wiki で説明されている通りに /etc/ssl/openssl.cnf を編集してください。

具体的には、[provider_sect] セクションの最後に legacy = legacy_sect を追加してください。[default_sect] で activate = 1 のコメントを外してください。最後に、activate = 1 という行も含む新しいセクション [legacy_sect] を追加してください。他のほとんどの既存の構成セクションを除外すると、最終結果は次のようになります:

/etc/ssl/openssl.cnf

openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

最後に、NetworkManager.service を再起動して、新しい OpenSSL 設定を有効化してください。

OpenSSL の "unsupported protocol" エラーで WPA Enterprise の接続の認証に失敗する

openssl がバージョン 3 に更新されたため、デフォルトで SSL 3、TLS 1.0、TLS 1.1、そして DTLS 1.0 はセキュリティレベル 0 でのみ動作するようになりました。それよりも古い標準しかサポートしていない Wi-Fi ネットワークでの認証は、ログに以下のエラーを吐いて失敗します:

wpa_supplicant[3320]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:protocol version
wpa_supplicant[3320]: OpenSSL: openssl_handshake - SSL_connect error:0A000102:SSL routines::unsupported protocol
wpa_supplicant[3320]: wlp3s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

正しい方法は、設備の管理者を説得して、暗号化されたネットワークトンネルのプロトコルを TLS 1.3 にアップグレードし、任意で TLS 1.0/1.1、DTLS 1.0、SSL 1-3 を含む非推奨となっているセキュリティ標準のサポートを落としてもらうことです。しかし、当面の回避策として、TLS 1.0 や 1.1 をデフォルトで許可する方法は複数あります。一つは、手動で OpenSSL にパッチを当てるか、破壊的な変更をもとに戻すことです ([10])。これは、OpenSSL レベル 1 を使用する他の全てのプログラムのセキュリティも低下してしまうため、推奨されません。代わりに、(BBS#286417 で説明されているように) wpa_supplicant によって使用されるレベルを直接設定することができます。問題のある接続設定ファイルの [802-1x] セクションで phase1-auth-flags=32 または phase1-auth-flags=64 を設定することで、その接続のみを変更できます。これは GUI からは無理かもしれませんが、nmcli でなら可能です。

まず、以下のコマンドの出力から、問題のある Wi-Fi 接続の名前を手に入れてください:

$ nmcli connection show

この接続では TLS 1.0 が使用され、接続名は Example WiFi であるとします。以下のように nmcli を使用してください:

$ nmcli connection modify 'Example WiFi' 802-1x.phase1-auth-flags 32

TLS 1.1 接続に対しては、代わりに "64" を使用してください:

$ nmcli connection modify 'Example WiFi' 802-1x.phase1-auth-flags 64

ノート: ここで入力した数字は、2 の n 乗です。ただし、n はネットワーク認証ビットオクテットのインデックス (右から左に数えます) です。5番目のビットを1にすると TLS 1.0 が有効になり ([log(2) 32])、6番目のビットを1にすると TLS 1.1 が有効になります ([log(2) 64])。

変更は即座に /etc/NetworkManager/system-connections/Example WiFi.nmconnection に反映されるはずです。

最後に、NetworkManager.service を再起動して、新しい OpenSSL の設定を有効化してください。

参照

翻訳ステータス: このページは en:NetworkManager の翻訳バージョンです。最後の翻訳日は 2024-12-01 です。もし英語版に変更があれば、翻訳の同期を手伝うことができます。

@@ 250行目: / 250行目: @@
 === プロクシ設定 ===
+NetworkManager はプロキシに関するいくつかの設定をサポートしています。それらは ''nmtui'' から直接変更することはできませんが、''nm-applet'' と ''nmcli'' はそれらをサポートしています。
-NetworkManager は直接プロクシ設定を扱いませんが、[[GNOME]] や [[KDE]] を使っている場合、NetworkManager の情報を使ってプロクシ設定を管理する {{AUR|proxydriver}}{{Broken package link|package not found}}  を使うことができます。
+プロキシの設定項目は {{man|5|nm-settings-nmcli}} を参照してください。
-''proxydriver'' でプロクシ設定を変更できるようにするには、GNOME スタートアッププロセスの一部として、次のコマンドを実行する必要があります ([[GNOME#自動起動]] を参照):
+また、ディスパッチャスクリプトを使うことでカスタムのプロキシコマンドを常時実行することができます。[[#ディスパッチャの例]] を参照してください。
- $ xhost +si:localuser:''ユーザ名''
 参照: [[プロキシ設定]]
@@ 1,062行目: / 1,062行目: @@
 * ''iwd'' に切り替える前に、[https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=iwd 既知の問題]を考慮してください。}}
-[https://iwd.wiki.kernel.org/networkmanager 実験的な iwd バックエンド]を有効化するには、{{Pkg|iwd}} を[[インストール]]してから、以下の設定ファイルを作成してください:
+[https://archive.kernel.org/oldwiki/iwd.wiki.kernel.org/networkmanager.html 実験的な iwd バックエンド]を有効化するには、{{Pkg|iwd}} を[[インストール]]してから、以下の設定ファイルを作成してください:
 {{hc|/etc/NetworkManager/conf.d/wifi_backend.conf|2=
@@ 1,071行目: / 1,071行目: @@
 または、{{AUR|networkmanager-iwd}} をインストールすることもできます。これは、''iwd'' のみで動作する ''NetworkManager'' をビルドするように設定された修正パッケージです。主な違いは、''iwd'' が必要であり、''wpa_supplicant'' はビルド後にアンインストールできることです。
-{{Note|1=''iwd'' に切り替えた後、[https://iwd.wiki.kernel.org/networkmanager#converting_network_profiles 既存の NetworkManager ネットワークプロファイルを変換する]必要がある場合があります。}}
+{{Note|1=''iwd'' に切り替えた後、[https://archive.kernel.org/oldwiki/iwd.wiki.kernel.org/networkmanager.html#converting_network_profiles 既存の NetworkManager ネットワークプロファイルを変換する]必要がある場合があります。}}
 === ネットワーク名前空間内で実行する ===
@@ 1,348行目: / 1,348行目: @@
 === OpenSSL の "unsupported protocol" エラーで WPA Enterprise の接続の認証に失敗する ===
-{{Pkg|openssl}} がバージョン 3 に更新されたため、[https://www.openssl.org/news/openssl-3.0-notes.html デフォルトで] SSL 3、TLS 1.0、TLS 1.1、そして DTLS 1.0 はセキュリティレベル 0 でのみ動作するようになりました。それよりも低い標準しかサポートしていない Wi-Fi での認証は、ログに以下のエラーを吐いて失敗します:
+{{Pkg|openssl}} がバージョン 3 に更新されたため、[https://www.openssl.org/news/openssl-3.0-notes.html デフォルトで] SSL 3、TLS 1.0、TLS 1.1、そして DTLS 1.0 はセキュリティレベル 0 でのみ動作するようになりました。それよりも古い標準しかサポートしていない Wi-Fi ネットワークでの認証は、ログに以下のエラーを吐いて失敗します:
 {{bc|
@@ 1,356行目: / 1,356行目: @@
 }}
-正しいアプローチは、WiFi の管理者に TLS 1.3 をサポートしてもらい、さらにオプションで TLS 1.0/1.1、DTLS 1.0、SSL 1-3 を含む低いセキュリティ標準のサポートを落としてもらうことです。しかし、当面の回避策として、TLS 1.0 をデフォルトで許可する方法は複数あります。一つは、手動で OpenSSL にパッチを当てるか、破壊的な変更をもとに戻すことです ([https://github.com/openssl/openssl/commit/7bf2e4d7f0c7ae19b7a8c416910886a7171e9820])。これは、OpenSSL レベル 1 を使用する他の全てのプログラムのセキュリティも低下してしまうため、推奨されません。代わりに、([https://bbs.archlinux.org/viewtopic.php?id=286417#p2104492 BBS#286417] で説明されているように) wpa_supplicant によって使用されるレベルを直接設定することができます。問題のある接続の {{ic|1=[802-1x]}} セクションで {{ic|1=phase1-auth-flags=32}} を設定することで、その接続のみを変更できます。これは GUI からは無理かもしれませんが、''nmcli'' でなら可能です。
+正しい方法は、設備の管理者を説得して、暗号化されたネットワークトンネルのプロトコルを TLS 1.3 にアップグレードし、任意で TLS 1.0/1.1、DTLS 1.0、SSL 1-3 を含む非推奨となっているセキュリティ標準のサポートを落としてもらうことです。しかし、当面の回避策として、TLS 1.0 や 1.1 をデフォルトで許可する方法は複数あります。一つは、手動で OpenSSL にパッチを当てるか、破壊的な変更をもとに戻すことです ([https://github.com/openssl/openssl/commit/7bf2e4d7f0c7ae19b7a8c416910886a7171e9820])。これは、OpenSSL レベル 1 を使用する他の全てのプログラムのセキュリティも低下してしまうため、推奨されません。代わりに、([https://bbs.archlinux.org/viewtopic.php?id=286417#p2104492 BBS#286417] で説明されているように) wpa_supplicant によって使用されるレベルを直接設定することができます。問題のある接続設定ファイルの {{ic|1=[802-1x]}} セクションで {{ic|1=phase1-auth-flags=32}} または {{ic|1=phase1-auth-flags=64}} を設定することで、その接続のみを変更できます。これは GUI からは無理かもしれませんが、''nmcli'' でなら可能です。
 まず、以下のコマンドの出力から、問題のある Wi-Fi 接続の名前を手に入れてください:
@@ 1,362行目: / 1,362行目: @@
  $ nmcli connection show
-接続名は ''Example WiFi'' であると仮定します。以下のように ''nmcli'' を使用してください:
+この接続では TLS 1.0 が使用され、接続名は ''Example WiFi'' であるとします。以下のように ''nmcli'' を使用してください:
- $ nmcli connection modify Example\ WiFi 802-1x.phase1-auth-flags 32
+ $ nmcli connection modify 'Example WiFi' 802-1x.phase1-auth-flags 32
+TLS 1.1 接続に対しては、代わりに "64" を使用してください:
-変更は即座に {{ic|/etc/NetworkManager/system-connections/Example\ WiFi.nmconnection}} に反映されるはずです。
+ $ nmcli connection modify 'Example WiFi' 802-1x.phase1-auth-flags 64
+{{Note|1=ここで入力した数字は、2 の '''n''' 乗です。ただし、'''n''' はネットワーク認証ビットオクテットのインデックス (右から左に数えます) です。5番目のビットを1にすると TLS 1.0 が有効になり ('''[log(2) 32]''')、6番目のビットを1にすると TLS 1.1 が有効になります ('''[log(2) 64]''')。}}
+変更は即座に {{ic|/etc/NetworkManager/system-connections/Example WiFi.nmconnection}} に反映されるはずです。
 最後に、{{ic|NetworkManager.service}} を[[再起動]]して、新しい OpenSSL の設定を有効化してください。
@@ 1,376行目: / 1,382行目: @@
 * [https://networkmanager.dev/ NetworkManager 公式ウェブサイト]
-{{TranslationStatus|NetworkManager|2024-10-10|817905}}
+{{TranslationStatus|NetworkManager|2024-12-01|821531}}

「NetworkManager」の版間の差分

2024年12月1日 (日) 15:49時点における最新版

目次

インストール

NetworkManager を有効化する

追加のインターフェイス

モバイルブロードバンドサポート

PPPoE / DSL サポート

VPN サポート

使い方

nmcli 例

接続を編集する

フロントエンド

GNOME

KDE Plasma

nm-applet

Appindicator

networkmanager-dmenu

switchboard

設定

NetworkManager-wait-online

PolicyKit のパーミッションをセットアップする

プロクシ設定

接続の確認

キャプティブポータル

DHCP クライアント

DNS の管理

DNS キャッシングと条件付きフォワーディング

dnsmasq

dnsmasq のカスタム設定

IPv6

DNSSEC

systemd-resolved

openresolv サブスクライバのある DNS リゾルバ

カスタム DNS サーバ

カスタムグローバル DNS サーバの設定

接続でのカスタム DNS サーバの設定

接続でのカスタム DNS サーバの設定 (GUI)

接続でのカスタム DNS サーバの設定 (nmcli / 設定ファイル)

/etc/resolv.conf

管理対象外の /etc/resolv.conf

openresolv を使う

ファイアウォール

ネットワークサービスで NetworkManager dispatcher を使用する

ディスパッチャのタイムアウトを防ぐ

ディスパッチャの例

タイムゾーンを自動的に設定する

sshfs でリモートディレクトリをマウントする

SMB 共有をマウントする

NFS 共有をマウントする

ディスパッチャを使って、LAN ケーブルが挿入されているかに応じて Wi-Fi を自動的にオンオフする

ディスパッチャを使って、ネットワーク接続が確立された後に VPN に接続する

ディスパッチャを使って、VPN プロバイダの接続時に IPv6 を無効化する

OpenNTPD

systemd-timesyncd で DHCP 経由で受信した NTP サーバを動的に設定する

テスト

ヒントとテクニック

Wi-Fi パスワードの暗号化

GNOME Keyring を使う

KDE Wallet を使う

Wi-Fi でインターネット接続を共有する

イーサネットでインターネット接続を共有する

cron ジョブやスクリプトでネットワークが立ち上がっているか確認する

ブート時にシークレットを使ってネットワークに接続する

OpenConnect で KWallet 内のパスワードを使う

特定のデバイスを無視する

MAC アドレスのランダム化を設定する

IPv6 プライバシー拡張を有効にする

接続ごとに一意の DUID を設定する

有線接続の操作

Wi-Fi バックエンドとして iwd を使用する

ネットワーク名前空間内で実行する

VPN に自動的に接続する

トラブルシューティング

セキュアな Wi-Fi ネットワークのパスワードプロンプトが表示されない

Network management disabled

内蔵 DHCP クライアントに関する問題

dhclient における DHCP の問題

3G モデムが検知されない

ノートパソコンで WLAN をオフにする