NetworkManager で OpenVPN と WireGuard のファイルのインポートが失敗する

GNOME の設定で「ファイルからインポート…」を選び、ベンダーのクライアントで動くプロファイルを選んだところ、ダイアログは一覧に何も追加せずに閉じました。二台目のノート PC ではインポートが完了し、接続がプロファイル名で現れ、その後の最初の認証要求で失敗しました。NetworkManager はあなたの .ovpn や wg-quick ファイルをそのまま実行することはありません。ファイルをパーサーに渡し、パーサーが NetworkManager 自身の接続形式に変換し、以後トンネルはその解析済みオブジェクトから構築されます。秘密、ルート、DNS もすべてそこから来ます。したがって有用な問いは、ファイルがなぜ壊れているかではなく、解析が行われたのか、そして何が残ったのかです。

インポートは実際にファイルをどう扱うか

OpenVPN の場合、パーサーはプラグインのパッケージ内にあり、作成される接続は org.freedesktop.NetworkManager.openvpn のような D-Bus サービスを指します。プラグインがなければパーサーもありません。型は nmcli に知られておらず、GUI の VPN 追加一覧にはインポート項目すら出ないことがあります。WireGuard は重要な点で異なります。NetworkManager は 1.30 系から独自の WireGuard 設定を持っているため、別個のプラグインパッケージはありませんが、wg-quick リーダーは同梱するビルドにしか存在しません。

いずれにせよ、ファイルは一度だけ読み込まれます。結果は /etc/NetworkManager/system-connections/ の下に keyfile として書き出され、接続名が付き、root が所有し、鍵素材を含むため他のユーザーからは読めません。以後、その keyfile が接続そのものです。元の .ovpn を後から編集しても何も変わりません。

三つの症状は 三つの異なる段階に対応します。インポート項目がない、または型が不明なのは、プラグインかバージョンが欠けているという意味です。ディレクティブ名を含むインポートエラーは、パーサーがファイルを読み、その一部を拒否したという意味です。接続は存在するのに一度も有効化されないのは、解析済みオブジェクトが不完全か、サーバー側が拒否しているという意味です。何かを編集する前に、自分がどのケースかを見極めてください。

プロファイルをデバッグする前にプラグインを確認する

プラグインの欠如は壊れたプロファイルと見分けがつかないので、まずパッケージを確認します。Debian と Ubuntu では OpenVPN サポートは network-manager-openvpn とデスクトップ用ヘルパーとして提供されます。Fedora では NetworkManager-openvpn と NetworkManager-openvpn-gnome、Arch では networkmanager-openvpn です。

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

次に絶対パスからインポートします: nmcli connection import type openvpn file /home/you/profile.ovpn。相対パスでもたいてい動きますが、ディレクトリを移動したシェルでは簡単なインポートが回り道になります。WireGuard では nmcli --version を確認し、modprobe wireguard でカーネル側が存在することを確かめてください。モジュールのないマシンで成功したインポートは、デバイスが決して現れない接続を残します。nmcli のリファレンスには import サブコマンドと受け付けられる型名が記載されています。type wireguard が真っ向から拒否されるなら、そのビルドはこの機能より古く、正しい対処はディストリビューションのパッケージかバックポートです。設定を任意のディレクトリにコピーして何かが読むと期待するのは筋違いです。

.ovpn ではなく OpenVPN の接続を読む

接続ができたら、ファイルを読み直すのではなく解析済みの設定を読みます: nmcli connection show "Work VPN" | grep -E '^vpn\.'。必要なのは remote とポート、トランスポート、識別情報（ca、cert、key、tls-auth または tls-crypt）、そして認証方式です。秘密鍵のパスワードがあるプロファイルでは sudo nmcli --show-secrets connection show "Work VPN" を追加し、secret フラグを見ます。0 は none で、秘密は keyfile にあります。1 は agent-owned、2 は not-saved で keyfile には決して書かれません。4 は not-required で、秘密がまったく不要という意味です。これはビットであって尺度ではないので、3 は単に agent-owned と not-saved の組み合わせです。セッションごとに一度尋ねられる秘密は agent-owned (1) で、エージェントが要求します。そのための専用フラグ番号はありません。フラグの不一致は、デスクトップのアプレットからは接続でき、スクリプトや起動時には失敗する典型的な理由です。

パーサーが何を落としたかを見る最短の方法は、プラグインにファイルを書き戻させて比較することです: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn。その差分で消えるディレクティブは接続時には存在しません。犯人はたいていフックです。script-security、up、down、route-up は昇格した権限でスクリプトを実行することを前提とし、意図的に引き継がれません。インポートを成功させるために検証を下げたり追加の権限を与えたりしないでください。未対応のオプションは通常、到達不能なサーバーではなくプラグインの機能範囲を反映しています。その振る舞いは NetworkManager の dispatcher スクリプトかサーバー側ポリシーへ移してください。

識別情報の項目が残っていることも確認します。CA 参照、remote-cert-tls、そしてプロファイルが頼っていた名前の検査です。これらなしで上がる接続は、そのアドレスに応答する何かと話している可能性があります。

wg-quick ファイルではなく WireGuard の接続を読む

wg-quick ファイルはシェル意味論を持つ形式で、インポートされた接続は設定の集合です。PrivateKey はインターフェースの秘密鍵になり、Address は 一つ以上の IPv4 と IPv6 アドレスになり、DNS は NetworkManager の resolver プロパティに写像され、MTU は wireguard.mtu に写像されます（wg-quick 自身の既定値は 1420）。各 peer ブロックは公開鍵、endpoint、許可 IP、persistent keepalive を持つ peer エントリになります。何が保存されたかを nmcli --show-secrets connection show wg0 で出力してください。peer 一覧がその出力に現れない場合は keyfile を読みます:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

残らないのは wg-quick のシェル側の半分です。PreUp、PostUp、PreDown、PostDown、Table はそのツールの振る舞いであり、WireGuard インターフェースの属性ではないので、インポート後に何も実行しません。元が既定ルートに触れないために Table = off を使っていたなら、最近の NetworkManager は同じ目的で ip4-auto-default-route と ip6-auto-default-route を公開しています。接続がスクリプトと同じように振る舞うと決めつけず、明示的に設定してください。独自ルートを押し込んでいたフックは、そのルートを接続のルーティング設定に追加する必要があり、そうしなければ単に欠落します。

接続の所有者をちょうど 一つにする

よくある後追いの不具合は、次の起動までは動いてからループする接続です。たいていは [email protected] が以前の実験から有効なままか、ベンダーのクライアントが独自のデーモンを起動していて、二人の所有者が同じ宛先のためにルートと DNS を書いていました。NetworkManager は独自の経路で resolver を設定し、wg-quick は resolvconf 経由で書き込み、最後に書いた者が勝ちます。そのため名前解決は動き、止まり、また動きます。systemctl status wg-quick@wg0、nmcli connection show --active、ip link show type wireguard を確認し、メトリクスを調整するのではなく 二人目の所有者を無効にしてください。

本当に両方が必要な場合は、別々のインターフェースと重複しない許可 IP を与え、既定ルートをインストールするのはちょうど 一つにしてください。メトリクスの異なる 二本の既定ルートはスプリットトンネルではありません。二番目に起動したサービスが決める競争です。再接続後は適用状態をもう一度確認してください。一度きりの手動 resolver 編集で動くようになっても、インポートが完全だという証拠にはなりません。

トラフィックで検証し、再起動を生き延びる

接続を nmcli connection up "Work VPN" で上げ、アイコンを信じるのではなく状態、アドレス、ルートを読みます: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE'、ip route show default、そしてトンネル内でしか解決されない名前の実際の照会です。ハンドシェイクや ping の成功は暗号が動くことしか示しません。転送、スプリットトンネルのプレフィックス、プライベート DNS については何も語らず、そこがたいてい壊れます。

次に再起動して繰り返します。autoconnect の挙動、名前が変わったインターフェース、デバイスの後に読み込まれるプラグインは、きれいな起動でしか見えない不具合です。journalctl -u NetworkManager -b --no-pager | tail -n 40 はこの起動でデーモンがこの接続に何をしたかを示します。二台目には keyfile をコピーして root 所有・モード 600 で保つか、OpenVPN では nmcli connection export を使い、できた .ovpn を再インポートしてください。エクスポート経路には WireGuard の同等物がないため、その方向はファイルコピーか保護された元からの新規インポートになります。

短くまとめると、順に: プラグインか NetworkManager のバージョンを確認し、絶対パスからインポートし、secret フラグを含む解析済み設定を読み、OpenVPN のエクスポートを元と比較し、WireGuard 側のフックとルートを確認し、二人目の所有者を無効にし、再起動後に名前解決とルート表を検証します。接続がそこまで通れば、それを始めたプロファイルファイルは保護された保管へ戻せます。