nmcli の VPN 一覧：保存済みプロファイルと稼働中トンネル

nmcli connection show を実行して VPN の一覧を期待しても、マシンがこれまでに保存したすべての接続が返ります。ブリッジやホットスポットも含まれます。探している VPN はそこにあるかもしれませんし、vpn 以外の型かもしれませんし、NetworkManager の接続でないかもしれません。この三つのうちどれなのかを知るには二つのコマンドが要ります。

二つの一覧、二つの問い

connection show は NetworkManager が保存したものを答え、connection show --active は現在デバイスに接続されているものを答えます。最初の一覧には非アクティブなプロファイルも含まれますが、これは意図的です。停止している保存済み VPN も、修正が必要かもしれないプロファイルだからです。二つを混同すると、設定だけが存在するのにトンネルが動いているという印象になります。

既定の表を読むのではなくフィールドを選んでください。既定の出力は細い端末では型を隠し、長い名前を折り返します。

最初の確認には通常 NAME、UUID、TYPE で足ります。そのあと気になる一つの項目を UUID で調べます。

TYPE こそ驚きのある場所です

OpenVPN プラグイン経由で管理される接続は type vpn として表示されます。プラグインは汎用 VPN フレームワーク内のサービスだからです。ネイティブの WireGuard 対応は独自の第一級の接続型なので、vpn で絞り込んでも見つかりません。何も返さない WireGuard トンネルの検索は、プロファイルの欠落ではなくフィルタの問題であることが普通です。これは命名の妙ではなく、アーキテクチャの違いです。

同じことは、NetworkManager が時間をかけてネイティブに扱えるようになった他のトンネル型にも当てはまります。何かが欠けていると結論づける前に TYPE 列を読んでください。

すべてを一覧してから絞り込めば、プロファイルが現れます。

名前だけでなく UUID を読んでください

名前は人が編集するラベルであり、不注意なインポートのあと二つのプロファイルが同じ名前を共有することがあります。UUID はコマンドとファイルが参照する同一性です。項目が重複して見えるときは、何かを削除する前に UUID と基盤の設定を比較してください。

アクティベーションのコマンドはどちらも受け付けるので、名前頼みの習慣はやがて誤ったプロファイルを変更します。

取り消す必要があるかもしれない変更をするときは、UUID をメモにコピーしてください。

保存済みプロファイルが教えてくれないこと

保存済みプロファイルはトンネルが上がっているかどうかを何も語らず、アクティブな接続は内部のトラフィックが動いているかどうかを何も語りません。wg-quick やサービスユニットが起動したトンネルは NetworkManager の接続ではまったくありません。そのためインターフェースが明らかにトラフィックを通していても、どちらの一覧にも現れません。プロファイルがないと決めつける前に、インターフェースとルーティングテーブルを確認してください。空の一覧が証明するのは、NetworkManager が所有者ではないということだけです。

同じインターフェースに二人の管理者がいるのはこの問題の別バージョンで、カーネルの状態を別のものが所有しているのに一覧だけは正しく見えます。

インターフェースごとに所有者を一人にすれば一覧は正直に保たれます。そして nmcli のリファレンス には、各ビューが実際にどのフィールドを報告するかが記されています。

秘密を漏らさずに報告する

connection show に名前を付けると設定が表示され、--show-secrets を加えると 秘密鍵とパスワードも表示されます。チケットへのトラブルシューティングの貼り付けにそれらは要りません。代わりに型、UUID、状態、関連するルートを報告し、シークレットストアから来たものは伏せてください。

--ask による対話的なアクティベーションが不足した資格情報を渡す正式な方法で、無人自動化には保存された平文パスワードではなく別の承認された仕組みが必要です。

短く伏せ字にした報告は、完全なダンプより見直しが容易です。