別の OpenVPN クライアントでは問題なく接続できるプロファイルが、NetworkManager へのインポートを拒否することがあり、ダイアログはプラグインのインポート機能を責める。この一文は目の前のマシンについての話であり、ファイルやサーバーの話ではない。インポートはマネージャーの VPN プラグインが行うローカルな処理であり、失敗した瞬間、どこにも何も送られていない。まずパッケージの問題として、次にパースの問題として扱おう。

メッセージをローカルな文として読む

この一文はプラグインの機能群を説明している。OpenVPN 対応を提供するプラグインが入っていないか、インポート操作を提供するコンポーネントが渡そうとしている形式より古いか、そのどちらかだ。どちらも目の前のマシンの中の話である。

メッセージが言っていないことに注目しよう。証明書が間違っている、パスワードが切れた、サーバーが落ちている、とは言っていないので、再起動や認証情報の変更では直らない。インストール済みソフトウェアについての文として読むべきだ。

この区別がこの記事全体でいちばん時間を節約するのは、障害がまるごとデスクトップ側にあるのに反射的に外のゲートウェイを見てしまうからだ。

ステップ 1: プラグインとエディターを確認する

重要なパッケージは二つあり、役割が違う。一つは接続を所有する NetworkManager の VPN プラグインを提供し、もう一つはデスクトップの編集とインポートのフロントエンドを提供する。ランタイムだけ、あるいはエディターだけを入れても、機能の半分しか手に入らない。

nmcli --version
nmcli connection show
rpm -q NetworkManager-openvpn NetworkManager-openvpn-gnome 2>/dev/null

dpkg -l | grep -i network-manager-openvpn

実際にディストリビューションにあるパッケージコマンドを使い、上の二行は選択肢であって順番ではないと心得よう。そもそも NetworkManager の流れの中にいることも確認したい、独自のインポーターを持つ別の OpenVPN クライアントはこの助言に一切反応しないからだ。

プラグインを入れると通常 NetworkManager が再起動または再読み込みされ、既存の接続が一時的に切れる。サポート通話の途中ではなく、意図して行おう。

ステップ 2: nmcli でインポートして本物のメッセージを得る

グラフィカルなダイアログは複数の失敗を一つの文に押し込みがちだ。コマンドラインのインポーターはより具体的で、しかも同じ操作である:

nmcli connection import type openvpn file /path/to/client.ovpn
nmcli connection show --active

応答を注意深く読もう。プラグインがないという不満はパッケージの問題だ。特定のディレクティブについての不満はパーサーの問題だ。参照されたファイルについての不満はパスの問題であり、この三つに共通するのはインポートという言葉だけである。

ここでの成功は保存されたプロファイルを作るだけだという点を忘れないように。接続はしないし、元のプロファイルの機能がすべて残った証拠にもならない。

ステップ 3: インライン証明書はそのままにしておく

古い助言は、インポート前にインラインの証明書と鍵のブロックをすべて取り除けと言う。その助言はもう古い。現在のインポーターはインラインのオブジェクトを扱えるし、削除すると接続に必要な身元情報が消え、しかもインポートはできて認証で失敗するプロファイルが出来上がる。

特定の理由でどうしても素材を切り出す必要があるなら、元のファイルを残し、どのブロックをどこへ移したか記録しておこう。三人が三回編集したプロファイルは、後から筋道立てて考えられる設定ではない。

同じ注意はベンダーのディレクティブにも当てはまる。クライアント固有のオプションは、無効な OpenVPN 構文ではないのに、あるプラグイン版の機能群の外にあることがあり、ダイアログを閉じさせるためだけに外すと挙動が静かに変わりうる。

ステップ 4: プロファイルが今なにを意味するか確認する

インポートが成功したら、何かを有効にする前にエンドポイント、認証の構成、ファイル参照、秘密の保存先を点検しよう。この四つが、インポートと意図が最もよく食い違う場所だ。

そのうえで、本当に気にしている挙動、つまりルート、DNS、元のプロファイルの機能が残ったかどうかを確認しよう。成功したインポートが依頼者を失望させうるのは、この三か所である。インポートの成功と正しく動く接続は別の結果であり、利用者にとって重要なのは後者だけだ。

インポートしたプロファイルが元のクライアントと違う挙動をするなら、違いはたいてい一行なので、記憶から作り直すのではなく二つの設定を比べよう。

ステップ 5: トンネルの所有者を一人のマネージャーにする

プロファイルが NetworkManager の中に住んだら、 接続の所有権もそちらに持たせよう。回避策として別の OpenVPN プロセスを起動すると、独自のリゾルバ挙動、独自の認証情報、独自のライフサイクルを持つ二本目の管理経路ができる。

どちらも自分がデフォルトルートを所有していると思っている二本のトンネルは、プロバイダーが壊れたような症状を生むので、直すべきはどちらかを調整することではなく片方を外すことだ。

関連記事