Ubuntu 18.04 の VPN メニューに OpenVPN が出ないときの導入パッケージ

GNOME の VPN 一覧に、渡されたプロファイルに合う項目が何も出ないことがある。そのため、このデスクトップでは OpenVPN を使えないと結論しがちだ。だが使える。足りないのはプラグインパッケージで、同じマシンにあるコマンドラインクライアントはメニューとは無関係だ。まずこの俗説を潰すべきである。それが人を間違った再インストールへ導くからだ。

メニューに並ぶのはプラグインでありプロトコルではない

GNOME はネットワークマネージャーが報告する接続タイプを描画し、マネージャーはインストール済みのプラグインを報告する。したがって空の一覧が示すのはインストール済みプラグインの集合であり、プロトコルの能力ではない。動く openvpn バイナリがあってもパネルが変わらないのはそのためだ。

この区別が重要なのは、パネルから見ると二つの故障が同じに見えるからだ。プラグインの欠落とプラグインの破損はどちらも 役に立たないダイアログ を出し、インストールで直るのは前者だけだ。何かを入れる前に、マネージャーに何を知っているか尋ねれば両者は分かれる。その質問はコマンド一つで済み、一時間の当て推量を置き換える。

ダイアログの持ち主はどのパッケージか

Ubuntu 18.04 ではパッケージ名が定まっており、新しいリリースも同じ分担を保っている。これらは選択肢ではなく役割として読むべきだ。一つ入れるだけでは問題はめったに解決しない。一方のパッケージはデーモンとコマンドラインクライアントを持ち、どちらも設定ダイアログを認識しない。

ネットワークマネージャーが OpenVPN 接続を作成・保存・開始できるようにするのがプラグインパッケージだ。エディターパッケージはフォーム、その各フィールド、パネルが呼ぶ保存先を提供する。プラグインはあるがエディターがないマシンでは設定できないタイプが表示され、エディターはあるがプラグインがないマシンでは何も表示されない。一式をまとめて入れれば曖昧さは消える。

sudo apt install openvpn network-manager-openvpn network-manager-openvpn-gnome
nmcli --version

18.04 ではそれが実際のアーカイブ名であり、代用品ではない。KDE デスクトップは独自のエディターパッケージを必要とし、プラグインも依然として必要だ。そこが GNOME 専用の解説が省く部分である。

再起動もインストールの一部

パネルはサービスの開始時にサポートするタイプをマネージャーへ問い合わせるが、すでに描画された一覧はインストールでは更新されない。そのためサービス稼働中にインストールすると、インストールは成功したのにダイアログは変わらないという厄介な組み合わせになる。再起動は任意の手入れではなく、インストールを目に見えるようにする手順だ。

再起動は数秒間接続を切り、同じインターフェースを通る SSH セッションも道連れになるので、マシンが遠隔にあるならそのつもりで計画する。そのあとパネルを開き直し、マネージャーに何をサポートするか直接尋ねる。直接の問い合わせは、キャッシュされているかもしれないメニューより良い証拠になる。

sudo systemctl restart NetworkManager
nmcli -f NAME,TYPE connection show
nmcli connection add type vpn

最後のコマンドが識別テストだ。プラグインがあれば引数の不足で失敗し、なければ未知の VPN タイプだと報告する。一方の結果は記入待ちのフォームであり、もう一方は依然としてパッケージングの問題だ。対比をはっきりさせたいなら、インストールの前後で実行する。

.ovpn は nmcli に読ませる

渡されたプロファイルを制御項目ごとに作り直す必要はない。マネージャーは .ovpn ファイルを直接読み、その指示子をインライン証明書も含めて保存済みの接続に変換する。インポートは正確さでも書き写しに勝る。暗号の打ち間違いや鍵の切り詰めは、サーバーの問題に見える故障を生むからだ。

保存が終わるまで、プロファイルは参照する鍵や証明書の隣に置いておく。ファイルパスだけを保存する接続は、それらのファイルが移動すると壊れるからだ。そのあと接続を名前で試し、資格情報の要求には前面で答えて何を求めているか見えるようにする。一度も有効化していない保存済み接続は何の証拠にもならない。

nmcli connection import type openvpn file ~/Downloads/office.ovpn
nmcli --ask connection up office
nmcli -f NAME,TYPE,STATE connection show --active

その三番目のコマンドは、トンネルが期待した名前で上がっていることを確認する。失敗した接続と、一度も有効化されなかった接続も切り分ける。

メニューからは分からないこと

タイプがないことはゲートウェイについて何も語らず、サーバーが OpenVPN を拒否しているという意味でもない。メニュー項目を出すために無関係なプロトコルのプラグインを入れる理由にはならない。この二番目の誤りには実際の名前がある。提供されていた項目がそれだったという理由で、人は PPTP や AnyConnect のプロファイルを OpenVPN サービスに向けてしまうのだ。

まずパッケージングを直し、サーバーの話はそのあとだ。きれいにインポートできて一度も認証しないプロファイルは、エディターの問題ではなく証明書、TLS、資格情報の問題で失敗している。それぞれ残る証拠は異なり、どれもダイアログには現れない。設定パネルを開き直す前にクライアントのログを読む。

実際に使うリソースで確かめる

タイプが存在し接続が保存されたら、接続して実際に使うリソースを開く。有効化だけでは両端がトンネルで合意したことしか証明しない。トンネルが上がっても何も運ばないのが次の故障モードで、パネルからは見えない。

どのリソースを試したかを書き残せば、次の人が最初からやり直さずに同じ確認を繰り返せる。トンネルが上がっていてリソースがまだ失敗するなら、調査はダイアログに戻るのではなくルートと DNS へ移る。そのメモが、修正と物語の違いになる。