VPN サービスを再起動すると、それを使っているすべてのセッションが終了するので、時間帯はパッケージマネージャーではなく会話を中心に組む必要がある。利用者には機密作業を終えるための十分な予告が必要で、あなたにはこれから止めるトンネルに依存しない戻り道が要る。手順書のその他はすべて、この二つの事実を扱いやすくするために存在する。どちらか一方を飛ばせば、日常的な更新が出口のない停止になる。

以下の順序は意図的で、各段階は次の段階が必要とするものを生み出し、どの段階でも始める前に変更を中止できる。

変更する前に、いま存在するサービスを記録する

記憶しているユニットではなく、インストール済みのユニットを読む。systemctl cat [email protected] はユニットとすべての drop-in を出力し、systemctl show [email protected] -p ExecStart -p User -p WorkingDirectory は実際に何が誰として動いているかを示すので、そのユニットが指すバイナリに問い合わせる(シェルからの openvpn --version は別のビルドに解決されることがある)。プロファイルのパスと、それが参照するすべてのファイルを記録する。

待ち受けソケットにも注目すると、ss -lunp | grep 1194 は今日デーモンが持っているアドレスとプロトコルを教えてくれる。答えがプロファイルの示すものと違うなら、drop-in か環境ファイルが上書きしており、アップグレードはその驚きを引き継ぐ。

他の人が使える復旧用セットを組み立てる

復旧用セットは、あなたの文脈なしで同僚が 03:00 に使えるものでなければならない。実効設定と参照されるすべてのファイル、PKI 所有者の管理下にある信頼と失効の材料、クライアントごとの割り当てとフック、今日インストールされている正確なパッケージ版を含める。ファイル名が一つ載ったコピーは設定ではない。VPN なしで当番の運用者がたどり着ける場所に保管する。

そのセットにもアクセス制御が要るのは、秘密鍵やバックエンドの資格情報を含むからだ。パッケージ版が変わっただけで CA を作り直したり、識別情報を再発行したりしない。

実際のクライアントでパイロット用リスナーに練習する

候補リリースは、本番インスタンスと同じソケットの隣ではなく、独自のポートとアドレス計画を持つ別のリスナーで動かす。利用者が実際に使うクライアントエンジンで接続し、扱いにくいものも含める。アドレスの割り当て、プッシュされる DNS、重要なアプリケーション一つ、遮断されたままであるべき経路一つを確認する。独自のフックはサービスの実際の権限とファイルシステムの文脈で動かす必要がある(root シェルではそれについて何も証明できない)。

リリースノートは新機能のためだけでなく、振る舞いの変更のために読む。暗号と TLS の既定値はバージョン間で動き、まだ解析できるプロファイルでもハンドシェイクに失敗しうる。アップグレードにプロファイルや証明書の変更が要るなら、パッケージ更新に詰め込まず独立した手順として計画する。

トンネルの外側の経路から一度だけ切り替える

時間帯は、サービスを通らないコンソールか管理ネットワークから始める。利用者への周知と、二番目の運用者が切り戻しを知っていることを確認する。用意した変更を所有者経由で適用し、sudo systemctl restart [email protected] で再起動し、journalctl -u openvpn-server@office -b -f でジャーナルを追う。ユニット定義だけが変わったなら再読み込みで足りるが、プロファイルが変わったならプロセスの再起動が要る。

すべてのクライアントが再接続すると想定し、いくつかのアプリケーションセッションは再開しないと想定する。それが耐えられないワークロードとは事前に調整して、きれいに止める。

受け入れるか切り戻し、そのうえで利用者に何が変わったかを伝える

受け入れとは、新規ログインと実際の操作、そして今も有効な制限である。ユニットが動いていて状態行が緑なのはプロセスの事実にすぎない。時間帯の中で基準を満たせないなら、用意した方法で切り戻す(ファイル一つを戻して望みをかけるのではなく、変更したバイナリやサービス方針は設定の復元では戻らない)。時間帯の間に加えた失効や認可の変更は、切り戻しでセキュリティ作業を取り消さないよう残す。

版、プロファイルの変更、受け入れ結果を次の運用者のために記録し、パイロット用リスナーを退役させ、いま使うべきプロファイルを利用者に伝える。その記録なしで終わる時間帯は、次の更新で蒸し返される。

関連記事