再起動後のVPNサーバー復旧を確認する:最初に何を見るか
誰もログインしていない状態で再起動し、外部から接続します。自動で戻るべきユニット、インターフェース、ルート、ファイアウォール規則を確認します。
誰もログインしていない状態でサーバーを再起動し、その後、管理していないネットワークから接続します。この一つのテストで、復旧が本物かどうかが分かります。誰かが手作業でコマンドを実行した後にしか動かないトンネルは復旧ではなく、修理だからです。ほとんどの確認は早すぎる段階で止まります。デーモンは active と表示され、インターフェースは上がっているのに、ページは読み込まれないのです。隙間はほとんどいつも、トンネルそのもののコマンドではなく、トンネルの周辺部分の永続性にあります。
四つの所有者、四つの異なるテスト
再起動の前に、何がトンネルを戻すべきなのかを名指ししてください。実行するテストと適用する修正はどちらもその答えに依存します。よくある所有者は四つです。VPN デーモンの systemd ユニット、WireGuard インターフェースの wg-quick インスタンスユニット、コンテナランタイム、ネットワークマネージャーのプロファイルです。所有者を名指しできないなら、立ち止まって見つけてください。想定された起動経路のない再起動テストは、何かが起きたことしか教えてくれません。
所有者ごとに設定の置き場所は違います。systemd が管理する OpenVPN サーバーは起動時に設定を読むので、起動時点でファイルにある内容がそのまま動きます。wg-quick インターフェースは同じファイルからアドレス、ルート、DNS を導くため、シェルから手で立ち上げてユニットとして有効化していないインターフェースは戻りません。コンテナはエントリーポイントを戻しますが、ホスト側のファイアウォール変更は、それがコンテナの外にある場合を除いて戻しません。
まずベースライン、でなければ結果に意味はない
動いているうちに動作状態を記録します。トンネル上のアドレス、クライアントサブネットへのルート、NAT や転送の規則、待ち受けソケット、転送の sysctl です。ip addr show wg0、ip route、nft list ruleset または iptables-save、ss -lunp、sysctl net.ipv4.ip_forward で、ほとんどのホストには足ります。
サービスが実行中かどうかだけでなく、どう起動する設定になっているかを記録します。systemctl is-enabled wg-quick@wg0 と systemctl is-active wg-quick@wg0 は別の問いに答えるもので、起動時に重要なのは有効化の状態です。systemctl(1) に書かれているとおりです。OpenVPN については、ホストがどのテンプレートを使っているかを確認します。openvpn@server と openvpn-server@server は既定値の異なる別のユニットだからです。
再起動を実行し、最初の失敗を読む
自分で選んだ時間帯に、意図して再起動します。コンソールか帯域外の経路を開いた状態で行います。最終状態ではなく出来事の順序を見ます。ホストに到達できる、ユニットが有効化された、インターフェースがある、ルートが入った、ファイアウォール規則がある、待ち受けが結び付いた、クライアントが受け入れられた。起きなかった最初の段階が発見であり、その先はすべて雑音です。
トンネルが使えないのにデーモンが active であることはよくあり、これが最も多い誤った合格です。ユニットが network-online.target ではなく network.target だけを待つ場合、ネットワークがオンラインになる前に起動が完了することがあります。証明書、鍵、CRL といった参照ファイルは、マウントや秘密の経路がまだ準備できていないため、その時点では読めないことがあります。どちらの問題も、ユニットのジャーナルを読むまで systemctl status には現れません。
ホストの外から試します。同じ LAN のクライアントは、遠隔のクライアントが決して使わないルートで成功することがあり、マシンへの SSH セッションはトンネルについて何も証明しません。接続し、内部名を解決し、プライベートなリソースに到達し、それからもう一度接続して、失効状態と鍵がまだ有効かを確認します。
修正を決める三つの条件
トンネルは戻るのにクライアントが何にも届かないなら、失敗はルーティングか NAT の永続性にあります。クライアントがハンドシェイクすら完了できないなら、失敗はインターフェースか認証素材にあります。サービスがまったく起動しないなら、失敗はユニットファイルかその依存関係にあります。この三つの分岐はそれぞれ別の修正に導くので、ベースラインなしの盲目的な再起動は節約する時間より多くの時間を費やします。
修正は設定の所有者がいる場所で行います。転送は sysctl の drop-in に、NAT 規則は起動時に読み込まれる規則セットに置き、ユニットは起動するのではなく有効化し、秘密はユニットの起動前から存在する経路に置きます。ユニットに sleep を足すのは、依存関係を宣言するのではなく隠すことです。
結果をランブックに記録する
何が自動で戻ったのか、何を起動する必要があったのか、隙間がどれだけ続いたのかを書きます。確認に使った正確なコマンドを含めてください。次の人が新しいテストを考案するのではなく、同じテストを繰り返せるようにするためです。手作業のコマンドが必要だった段階があるなら、そのコマンドは設定に属し、ランブックの恒久手順ではありません。
次に、次のテストはホストのネットワークスタックへの次の変更の後に予定します。半年先の暦の日付ではありません。あなたが防いでいる故障モードは、恒久的に感じられた一時的なコマンドであり、それは誰かがファイアウォール規則を編集したり、サービスを新しいユニットへ移したりしたときにちょうど現れます。