Ubuntu の起動時に OpenVPN を使う：NetworkManager と systemd のどちらか

ほとんどの解説はこの選択を、NetworkManager にトンネルを立ち上げさせるか systemd のインスタンスを有効にして終わりにするかという、外見上の問題として扱います。両者の違いは、画面のないマシンで結果を決める一点にあり、どちらのツールが新しいかとは関係ありません。NetworkManager はセッションを通じて秘密を解錠しますが、systemd のインスタンスには解錠するセッションがありません。目の前のマシンに合う秘密の扱いをするほうを選んでください。

ルートの導入から再接続の挙動まで、その他のすべてはこの最初の判断から決まります。

誰も語らない違いはキーリングです

NetworkManager が VPN プロファイルを所有している場合、パスワードはログイン時のキーリングに置くことができ、ユーザーがサインインすると解錠されます。ノート PC では、人がそこにいて、キーリングが開き、トンネルが立ち上がるので、うまく機能します。無人で起動するサーバーでは解錠する人がいないため、プロファイルは決して届かない秘密を待ち続けます。接続は設定済みに見えたまま、決して有効になりません。

systemd のインスタンスは、ディスクから認証情報ファイルを読むことでこの問題を避け、その結果、守るべきものはファイルそのものになります。chmod 400 と root による所有が最低条件であり、ファイルは管理下にないバックアップやイメージテンプレートの外に置くべきです。

VPN を接続に結びつけても起動は保証されません

nm-connection-editor で、VPN ではなく有線または無線の接続を選び、General タブを開き、自動的に VPN へ接続するオプションに印を付け、プロファイルに名前を付けます。すると NetworkManager は、プライマリ接続が接続済み状態になったときに VPN をセカンダリ接続として有効にします。これは依存関係であり、ファイアウォールの規則ではありません。トンネルが立ち上がる前の数秒間はパケットが外に出られるうえ、保存された秘密の解錠に失敗すれば、マシンはトンネルなしでオンラインのままになります。

トンネルなしでは何も外に出さないことが要件なら、そう明言してキルスイッチを構築してください。この設定だけではそれを提供しないので、復帰時にセカンダリ接続が再評価されることも踏まえて、サスペンドとレジュームも試してください。

systemd のインスタンスには一致するファイル名が必要です

プロファイルをパッケージが想定するクライアントディレクトリ、たとえば /etc/openvpn/client/office.conf に置き、その中から認証情報ファイルを auth-user-pass office.cred で参照します。インスタンス名は拡張子を除いたファイル名なので、openvpn-client@office は office.conf を読みます。sudo systemctl enable --now openvpn-client@office で有効にし、ブログの例を信じるのではなく systemctl cat openvpn-client@office で対応関係を確認してください。

プロファイル内のパスは、プロファイル自身ではなくユニットの作業ディレクトリを基準に解決されるため、相対的な ca や auth-user-pass の行は、手動で試すと動いても起動時に失敗することがあります。ユニットが見つける必要のあるものには絶対パスを使ってください。その後、実際に起動したあとで journalctl -u openvpn-client@office -b を読み、トンネルがないのに active と報告するユニットは、たいていそのログで欠けているファイルを示しています。

古いパッケージは別のテンプレート名を同梱しているため、systemctl list-unit-files 'openvpn*' でこのホストにどちらが存在するかを確定できます。

再接続の挙動は別の判断です

ping-restart を含むプロファイルは切断後にトンネルを再構築し、再起動の指示を含むユニットはサービス層で同様のことを行います。これらはあなたが選ぶ方針であり、引き継ぐ既定値ではありません。要求時だけ接続を立ち上げたいなら、再起動の挙動を意図的に外し、その理由を書き留めてください。ユニットがネットワークの使用可能になる前に起動するなら、起動時の一度の失敗はひとりでに繰り返されないため、再試行の方針が必要です。

停止も同じくらい文字どおりで、sudo systemctl disable --now openvpn-client@office は実行中のインスタンスを停止し、起動時のリンクを削除します。無効化だけではトンネルは次の再起動まで動き続けるため、無効化して試し、インターフェースが上がったままなのを見て驚く人は少なくありません。

再起動してから、四つのことを順に確認します

サービスの再起動はサービスを試し、マシンの再起動は起動経路を試します。再起動後に、ユニットが立ち上がったこと、次にリモートサブネットへのルートがあること、次にマシンがインターネットに見せるアドレス、最後に名前がトンネル経由で解決されることを確認します。何か問題があれば、この四つの確認はこの順に失敗するので、最初の失敗が役に立ちます。

ルートのない active なユニットは、通常、プロファイルは接続したがサーバーがルートを押し出さなかったか、ルートが後で消えたインターフェースに導入されたことを意味します。名前解決が機能しないルートは、トンネルそのものではなく DNS の設定を指し示します。

トンネルが立ち上がらないときにどうするかをあらかじめ決めてください。通常の接続性に戻すのは方針であり、先に起動した管理者に任せるのではなく、書き留めておくべきです。