ログイン後にしかVPNが動かないのはキーリングのせい

セッション内で動くプロファイルは起動時のサービスではありません。トンネルを起動するのは誰か、秘密はどこにあるのか、実際のイベントをどう検証するかを見ていきます。

ログインしている間はコマンドが動くので、起動スクリプトに入れて帰宅します。翌朝、マシンはオンラインなのにトンネルは動いていません。動く呼び出しは動くサービスだというのは俗説です。実際の違いはたいてい二つのうちのどちらかです。プロファイルがシステムではなくユーザーセッションに属しているか、秘密がログイン後にしか存在しない何かによって解錠されるかです。どちらも手動テストでは完璧に動き、誰も見ていないまさにその瞬間に失敗します。

なぜログインすると動くのか

グラフィカルログインはセッションバスとシークレットサービスエージェントを起動します。多くのデスクトップ向けクライアントは、プロファイルのパスワードや秘密鍵のパスフレーズをそこに保存します。ログイン後にユーザーとして実行されるアクティベーションは、そのエージェントに秘密を問い合わせて成功できます。起動時のユニットが実行する同じアクティベーションにはセッションもバスもエージェントもないため、検索は失敗するか、誰も見ていないプロンプトで止まります。

同じプロファイルをログインの前後で実行すると、一つの設定から二つの異なる結果が得られます。これは壊れたトンネルではなく資格情報への依存の兆候であり、端末での手動テストが見かけより少ないことしか証明しない理由でもあります。トンネルは正常です。その秘密を解錠するものが欠けています。

トンネルを起動する所有者を決める

サポートされるパターンは二つあり、それを混ぜることがこの失敗のもう一つの道です。NetworkManager はシステムスコープの接続を有効にでき、これはマシンがすでにネットワークをそこで集中管理している場合に適しています。あるいは、専用の systemd ユニットが VPN を直接実行し、インターフェース自体を所有します。

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

同じ設定に対して二人の所有者を同時に動かさないでください。NetworkManager がインターフェースを管理し、ユニットもそれを立ち上げると、ルートと DNS を奪い合い、結果の状態はどちらが最後に終わったかで決まります。

サービスが読める場所に秘密を置く

バックグラウンドサービスはプロンプトに答えられません。証明書のパスフレーズ、アカウントのパスワード、参照される認証ファイルはすべて、ユニットが人手なしで到達でき、サービスを実行するアカウントが所有し、他の誰にも読めない保存の仕組みを必要とします。

誘惑される近道は、権限エラーが消えるまでファイルを全員が読めるようにすることです。それは起動時の失敗を長期的な資格情報の露出と引き換えにし、誰も見直さない類の変更です。デプロイがすでに信頼している仕組みを使ってください。制限された資格情報ファイル、ファイル権限で保護された暗号化されていない鍵、あるいは独自の秘密ストアを持つシステムスコープの接続です。

実際に起きるイベントを検証する

ログイン後にサービスを手動で起動しても、ほとんど何も検証できません。再起動するか、一サイクルだけグラフィカルログインを無効にして、ユニットが自力で立ち上がるのを見てください。これが資格情報の可用性、ネットワークの準備、ユニットの順序を同時に試す唯一のテストです。また、手動起動では決して再現できない、ユーザーが報告した障害を再現するテストでもあります。

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

順序は資格情報と同じくらい重要です。基盤となるアップリンクが設定される前に起動するユニットは諦めてしまい、接続性を待つかどうかはディストリビューションによって異なります。ユニットが起動時に失敗を報告するのに、三十秒後に手で起動すると成功するなら、それは秘密の問題ではなく順序の問題を見つけたことになります。

インターフェースだけでなくルートと DNS を確認する

存在するインターフェースは動くトンネルではありません。無人起動の後、名前を確認する前にルート、リゾルバの状態、そしてアドレスによる一つの宛先を確認してください。そのうえで、トンネルが存在する理由であるアプリケーションを確認します。

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

アドレスが動いて名前が動かないなら、残る問題はトンネルではなく DNS ポリシーです。どの所有者がサービスを起動し、秘密がどこにあるかを記録してください。このマシンを次に再起動する人には両方の事実が必要です。

関連記事