OpenVPN 3 Linux：ロールバックする前に D-Bus エラーを読む
五つのサービス、一つのフロントエンド。D-Bus エラーを拒否したコンポーネントに結びつけ、セッションの有無を確かめ、その境界で直す。
OpenVPN 3 Linux の障害は、見慣れない名前が添えられた D-Bus メソッドエラーとして届き、パッケージを戻して祈りたくなる。クライアントは 一つのプログラムではない。コマンドラインのフロントエンドはバス越しに、プロファイル、セッション、VPN エンジン、特権を要するネットワーク変更をそれぞれ所有するサービスと話す。失敗した呼び出しをこの 五つのどれが持つかを見極めることが診断の大半であり、費用はロールバックではなくコマンド 一つ分である。以下はその判断を、障害が現れる通常の順に並べたものだ。
一つのコマンドの背後の 五人の所有者
重要なのは 五つのプロセスで、それぞれ自分のバス名を持つ。コマンドを受け取るフロントエンド、プロファイルとそのアクセス方針を保持する設定マネージャ、セッションの寿命を所有するセッションマネージャ、OpenVPN 3 Core Engine を通して接続を走らせるバックエンド、そしてインターフェース、経路、DNS 設定を入れるネットワーク設定サービスだ。したがって設定オブジェクトを名指すエラーはバックエンドのエラーではなく、起動しないバックエンドは認証の失敗ではない。メッセージをどの行に置くかは何かを変える前に決める必要がある。以降の手順はすべて、どの行が正しいかにかかっているからだ。行を当て推量することが、小さな修正をパッケージ作業の半日へ変える道である。
他の何かを尋ねる前にシステムバスにどのサービスが居るかを問い、そのうえで導入済みの部品が同じバージョンで一致していることを確かめる。OpenVPN 3 Linux はそれらのサービスをシステムユニットとして登録するので、問うべきバスはシステムバスであり、バージョンの照会には管理者権限が要り、--user で作った一覧はあなたのログインセッションを読む。そこにユニットは決して現れない。サービスは要求に応じて起動し、一部はアイドルで終了するので、最初の要求より前に欠けているサービスは、まだ何も尋ねられていないだけだ。下の 三つのコマンドは、VPN セッションを開かずに存在、バージョン、ユニットの状態を答えている。
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'各一覧が実際に何を証明するか
クライアント自身の見え方は最も安価な証拠であり、そのどれもが見た目より少ないことしか証明しない。設定一覧のプロファイルは、プロファイルが取り込まれたことを示すだけで、誰かがそれで接続してよいかは何も語らない。セッション一覧のセッションは、セッションオブジェクトが存在することを示すだけで、遠隔の認証が終わったかは何も語らない。
openvpn3 configs-list
openvpn3 sessions-listこれらの出力のオブジェクトパスはバス上の管理対象を指し、ファイルではない。だから編集はできず、以前に書き留めたパスはそのセッションが切れた瞬間に古くなる。手元のメモから 一つ使い回すと、VPN とは無関係な "no such object" エラーが出る。下の段階表は、接続の各段が何を確立し何を開いたままにするかを分けている。ロールバックの判断が拠って立つのはまさにその区別だ。証拠に合う行を読み、それからエラーの文面をもう一度読む。
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
接続呼び出しはトンネルが存在する前に戻る
接続呼び出しは見張るためのセッションを渡して戻る。だから見た目に成功した呼び出しのあとに沈黙が続くのは、矛盾ではなく正常な中間状態だ。フロントエンドは依然として状態変化を追い、やり取りの要求に答えねばならない。資格情報を要するのに応答が返らないプロファイルは、固まったバックエンドとまったく同じに見える状態で待つ。その待ち状態は見分ける価値がある。人を誤ったコンポーネントへ送るからだ。
試行が走っている間は、そのプロファイルについてセッション一覧とフロントエンド自身のログを見る。初期状態から決して抜けないセッションは、止まったコンポーネントを名指す。ログはたいてい最初の数行でそれを名指す。プロファイル名を手元に置くこと。ログのコマンドはセッションのパスではなくプロファイルを取る。これもパスを使い回さず一覧を読み直す理由の 一つだ。
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6セッションを開かずに 一つのコンポーネントのログを読む
フロントエンドが役に立つことを何も報告しないときは、別の接続を始めるのではなく 失敗を記録したコンポーネント へ向かう。systemd-journald のロガーを設定してあれば、管理者のスコープ付きジャーナル表示は、バスの方針に触れずセッションも開かずに 一つのコンポーネントの出来事を読む。これは重要だ。測っている系を変えてしまう診断はほとんど何も証明しないからだ。syslog タグではなくユニットで絞る。個々のサービスユニットは共通の識別子を保証しないので、タグでの照会は空のページを返すことがある。ユニット自身は失敗を記録しているのに、ということが起こる。
誰かに助けを求める前に 四つの欄を記す。エラーの完全な名前、関与したサービスとオブジェクト、時刻の印、そして導入済みパッケージのバージョンだ。保守する者が必要とするのはこれらであり、どれもプロファイルや資格情報をチケットに貼ることを求めない。エラーを黙らせるためにバスアクセス方針を広げるのは診断ではない。あなたの代わりにコンポーネントを名指していた境界を消してしまう。プロファイルの私的な中身が共有の報告から外れるのは、資格情報と同じ理由だ。
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>拒否した境界を直す
地図の各行にはそれぞれの直し方があり、行同士は互いの代わりにならない。プロファイル上で拒否された操作は方針と所有の問いであり、起動しないバックエンドはサービスとパッケージングの問いだ。認証を拒むサーバはどちらでもないので、パスワードを何度変えてもローカルの起動問題は直らない。間違った直し方を選ぶことが、方針の問題を再インストールへ変える道だ。
パッケージを変えたあとは、古いバイナリを 一つ元の場所に写すのではなく、整合の取れた supported な導入を確かめる。統制されたロールバックは確認済みの regression に対する正当な答えであり、パッケージが互換のまま保たれ、supported な保守へ戻る道があることが条件だ。その道は、サービスが起動しなくなる前に整える。あとではない。
別のプラットフォームは同じ中核 VPN ライブラリを共有していても、Linux のバスサービスは共有していない。だから Windows での似た障害はこの障害について何も語らない。D-Bus の概観 は設定とセッションのために公開されるオブジェクトパスを記しており、この診断が依拠するのはまさにその部分だ。一度読めば、次のエラーはすでにコンポーネントを伴って届く。