OpenVPN Access Server で同じ作業に見えるものに対して二つのコマンドが貼り付けられますが、やることは違います。systemctl restart openvpnas は製品全体を停止して起動し直します。sacli start は、たった今変更した設定を読む内部サービスを立ち上げます。どちらを選ぶかは好みの問題ではありません。設定そのもののドキュメントが何と言っているか、これから再起動するサーバーを自分のセッションが通っているか、そして正しい製品を見ているかで決まります。

二つの層、一つのデーモン

Access Server は単一の systemd ユニット openvpnas として動作し、そのデーモンがウェブインターフェースの背後にある内部サービスと VPN リスナーを監督します。sacli は同じインストールへのコマンドラインインターフェースで、/usr/local/openvpn_as/scripts/sacli にあり、ユニットを置き換えることなくそれらの内部コンポーネントを起動・停止・照会できます。

だから両方のコマンドが存在します。デーモンの再起動はすべてを実行し直し、クライアントのトンネルを終了させるプロセスも含みます。sacli start はすでに動いているデーモンにコンポーネントを立ち上げさせ、新しい設定を読ませます。ほとんどのプロパティ変更が実際に必要とするのはこちらです。

第一の条件: 設定のドキュメントが何と言うか

変更した設定のページを読んでください。先月変更した設定のページではありません。ConfigPut で書かれたプロパティの後には通常 sacli start が続き、その組み合わせが文書化された適用手順です。リスナー水準の振る舞いの変更、またはページがサービスの再起動が必要だと説明しているものは、ユニットの再起動が正しい分類です。

二つのコマンドは交換できません。そのため、推測したときの失敗の形は非対称です。完全な再起動が必要なときに sacli start を使うと、古いプロセスが以前の設定のまま動き続け、設定が無視されたように見えます。sacli start で足りるときに完全な再起動をすると、理由もなく接続中のすべてのクライアントを切断します。

第二の条件: 自分のセッションがトンネルの中か

Access Server が提供する VPN 経由で管理している場合、再起動はシェルを運ぶ接続を切ります。コマンドはセッションが切れた後に完了することがあり、動いたかどうかを推測することになります。同じ理由で sacli start も、再起動されるコンポーネントが自分の通信を扱っているときはセッションを短く中断することがあります。

どちらのコマンドでも、事前に帯域外の経路を開いておいてください。プロバイダーのコンソール、ハイパーバイザーのコンソール、またはシリアルセッションです。この条件が決めるのはコマンドをいつ実行するかであり、どちらを実行するかではありません。二分の変更を障害報告に変えるのはこれです。

第三の条件: それが思っている製品か

Access Server は Community OpenVPN ではない。コミュニティ版のインストールは openvpn@server や openvpn-client@profile といったユニットを動かし、設定は /etc/openvpn にあり、sacli はそこに存在しません。共有ホストで名前に openvpn を含むユニットをすべて再起動するのは、無関係なトンネルを一緒に落とす方法です。

何かに触れる前に見極めてください。systemctl status openvpnas --no-pager は Access Server が動いているかを答え、sacli status はその内部コンポーネントを一覧し、systemctl list-units --type=service は名前に openvpn を含むユニットを一覧します。最後のコマンドがプロファイル名のユニットを示すなら、コミュニティ版の製品であり、ここから先は当てはまりません。

適用し、そのうえで active の先を検証する

active と報告するユニットには動いているプロセスがありますが、それは機能している認証経路と同じではありません。適用の手順の後、再起動されるはずだったコンポーネントについて sacli status を確認し、値が sacli ConfigQuery で保存されたことを確かめ、それからテストアカウントで限定的なクライアントログインを一度実行します。

最後はアプリケーション水準の何かで締めてください。トンネルを通って非公開のリソースに到達することであり、サーバーの公開アドレスへの ping だけではありません。押し出されたルートや DNS 設定が誤っているのに成功するハンドシェイクは、サービスの検査をすべて通過し、それでも問題を報告した人を失敗させます。

ベンダーのサービス管理チュートリアル はどの操作が sacli に属するかの参照であり、再起動が安全な選択だと決める前に開く価値があります。

判断は一度の流れで

この四行をたどり、最初に当てはまる行で止めてください。

  • 設定ページが sacli start を挙げている、またはたった今 ConfigPut を実行した: sacli start を使ってください。
  • ページが再起動を要求している、または変更がプロパティではなくリスナーに触れる: systemctl restart openvpnas を使ってください。
  • シェルがこのサーバー経由で入っている: まずコンソールへの経路を用意し、次に上の二行が選んだコマンドを実行してください。
  • 検証: sacli status、値の ConfigQuery、ログイン一度、非公開リソース一つ。サービスの状態だけが終着点ではありません。

これらの行のうち二つは確認で、二つは行為です。順番の意味はそこにあります。製品の問いに答えられないなら止めてください。これから実行しようとしていたコマンドは別のインストールのものであり、落とすトンネルは意図したものではありません。

関連記事