VPN サーバーから締め出されたときに備えて二つ目の入口を残す

コンソールを開き、ファイアウォールの規則を一つ変えると、接続していたトンネルが消えます。変更は正しく、再読み込みは正しくなく、いまやマシンへ戻る唯一の経路は、たったいま壊したものです。二つ目の入口は設計上の判断であり、障害が起きる前に、障害の最中ではなく存在していなければなりません。

まだ手元に残っているものを確認する

目の前のコンソール画面から始めて、トンネルに依存しない経路を列挙します。プロバイダーのウェブコンソールとシリアル接続または VNC のセッションが一つです。別ネットワーク上の管理インターフェースがもう一つです。物理的なアクセスが三つ目で、これこそが最も悪い場面で欠けていることに気づく経路です。

三列目は抽象ではなく障害の一覧として読んでください。そうした経路のうち二つは、たいてい同じ理由で失敗します。この表は、障害が説明してくれる前にそれへ気づくための手段です。

独立性は依存関係の問題である

復旧用アカウントは、そのパスワードがトンネル経由でしか届かないサービスに保存されているなら独立していません。同じホスト、同じポート、同じファイアウォール方針の二つ目の VPN も独立ではない、なぜなら最初の一方を壊した変更は両方を壊すからです。

連鎖をたどり、各段階が何を必要とするかを名指ししてください。ネットワーク到達性、名前解決、認証元、そして管理サービスそのものが四つの別々の依存であり、そのいずれかを共有する経路はその障害を引き継ぎます。

一度も試していない経路には、それ独自の疑いを持つ価値があります。何か月も開いていないコンソールは、メールによるパスワード再設定を求めることがあり、そのメールボックスは手の届かないマシン上にあるかもしれません。すべてが動いているうちに経路を試せば、穏やかな午後にこれが見つかります。

二つ目の経路で管理された変更を一つ行う

コンソールからスナップショットを取るか、これから編集する設定をコピーします。変更するのは一つだけにし、サービスを再読み込みして、ほかの何かに触れる前に結果を読みます。二つの変更を同時に行うと、復旧が実験になってしまうからです。

その作業の間、復旧セッションは開いたままにします。二つ目の経路の価値は、変更しているものに耐える点にあり、先に閉じてしまえば、それを有用にしていた唯一の性質を失います。

記憶ではなく復旧経路から検証する

重要な確認は通常の経路が戻るかどうかであり、それを順番に確かめるのが復旧セッションです:

systemctl status openvpn-server@server --no-pager
ss -lntup | grep -E ':(1194|443)\b'
nft list ruleset | sed -n '1,40p'
journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30

まずサービスの状態、次に待ち受け、次に規則、最後にログを読みます。待ち受けのないサービスはサービスの設定を指し、到達できる規則のない待ち受けはフィルタリングを指します。各段階が次の段階を狭めるので順序が重要であり、ログへ飛ぶのはたいてい、原因ではなく症状を述べるエラーを読むことになります。

systemctl のドキュメント はここで使う状態と再起動の挙動を扱っており、失敗した再読み込みが以前のプロセスを動かしたまま残す仕組みも含みます。整合したリビジョンを戻すほうが、サーバーを修復できないクライアントから何度も再接続するより優れています。変更前に定めたロールバック条件が満たされたなら、復元して止めてください。

台帳を最新に保つ

人やインフラが変わったときにアクセス一覧を見直します。すべてが動いているうちに復旧経路を試します。最後の再編以降だれも使っていないアカウントを引退させます。古いアカウント二つと期限切れの証明書一つは、火曜日の小さな片づけであり、日曜日の障害です。

だれが各経路を使えるのか、何を許すのか、資格情報をどう回すのかを記録します。所有者のない復旧経路は忘れられた入口になり、それは締め出されるのとは別種の障害です。