一つの OpenVPN drop-in が全トンネルを変えた：インスタンスとテンプレート

一つのトンネル用に追加した再起動ポリシーが、マシン上のすべてのトンネルに適用され始めます。これは systemd の不具合ではなく、インスタンスの drop-in とテンプレートの drop-in の違いです。ファイルをどのパスの下に書くかが、いくつのサービスがそれを継承するかを決めます。

設定より先に適用範囲を選びます。二つのディレクトリはほとんど同じに見え、意図したインスタンスに限定されるのは片方だけです。

症状：一回の編集で全トンネル

インスタンス固有の drop-in は、完全なインスタンス名のディレクトリ配下に置きます。たとえば [email protected] です。テンプレートの drop-in は [email protected] の配下に置き、間に @ 記号がありインスタンス名はありません。前者は office にだけ適用されます。後者はそのテンプレートから生成されるすべてのサービスに適用されます。

テンプレート形式は別個の [email protected] テンプレートには届かず、名前に openvpn を含む無関係なサービスにも届きません。

適用範囲に合うディレクトリを選ぶ

どちらのディレクトリも /etc/systemd/system/ の配下にあります。最後の system 要素を落とすと、systemd がシステム上書きとして読まないパスになり、これは正しく見えるファイルを何もしないようにする静かな方法です。完全なパスを一度書いて再利用します。

drop-in には正しいセクション見出しも必要です。サービスの設定は [Service] の配下に置きます。設定はあるがセクションがないファイルは無視または拒否され、ファイルがそこに置かれて権威ありげに見える間も、unit は以前と同じように動き続けます。

drop-in を複数追加するなら、目的をファイル名に残します。マージは辞書順で決まり、ファイルの役割を示す名前ならその順序が読めるようになります。

書く前にマージ後の unit を読む

何かを書く前にマージ後の unit を読みます。systemctl cat [email protected] はメインの unit と適用されるすべての drop-in をマージ順に出力します。テンプレートの変更を検討するときは、二つ目のインスタンスと比べます。その比較で、どのサービスが編集を継承するかが正確に分かります。

インスタンスのファイルはテンプレートの設定を消しません。両方がマージされるので、忘れていたテンプレートの値がまだ有効なことがあります。

名前付きの他の drop-in、実行時の設定、パッケージが提供する構成も関与します。最後に編集したファイルが unit の全体だと考えないでください。マージ後の出力が unit です。

unit のポリシーはプロファイルの外に置く

unit のポリシーと VPN の設定は分けておきます。プロファイルのディレクティブは、[Service] の配下にあるからといって有効な systemd 構文になるわけではありません。再起動の設定も .ovpn ファイルに入るものではありません。

この分離は、再起動ポリシーがOpenVPN自身のピア復旧とは同じものではない理由でもあります。適用範囲を選ぶ前に、望む動作を決めてください。

適用してインスタンスを検証する

変更後、systemctl daemon-reload でマネージャーの定義を再読み込みします。この再読み込みはトンネルを再起動せず、unit ファイルを読み直すだけです。その後、意図したライフサイクル操作を正確なインスタンスに適用します。

読み込まれた unit をもう一度読み、変更した動作を観察して検証します。稼働中の作業を抱える再起動には計画的な中断がふさわしく、本番トンネルでの手早いテストではありません。上書きの目的と範囲を配備のそばに記録し、次に触る人がそのファイルを共有するつもりだったのか分かるようにします。

ポリシーが本当に共有なら、意図的にテンプレートへ移し、完了と言う前に二つ目のインスタンスを確認します。systemd の unit リファレンスが drop-in の優先順位とマージ順を説明しています。