VPN ログのための journalctl：どのユニットが接続を所有するのか

思い出したログコマンドからではなく、VPN 接続を実際に所有している systemd ユニットから始めます。直接の OpenVPN サービス、wg-quick ユニット、NetworkManager プロファイルは、有用なメッセージをそれぞれ別のユニットに置くため、間違ったユニットへの問い合わせは沈黙に見える空の結果を返します。よくある三つの所有者を比較し、時間枠を絞ってから、段階を順に読みます。

よくある三つの所有者を比較する

OpenVPN クライアントサービスは通常、プロファイル名を持つインスタンスユニットです（例：[email protected]）。そのメッセージには設定パス、オプションの解析、TLS ハンドシェイク、クライアントが行うルート設定が含まれます。

wg-quick ユニットは設計上より静かです。インターフェースの設定は起動時に行われ、ハンドシェイクはカーネルが処理し、定期的な鍵の再生成は既定では記録されないため、wg show のほうが journal より情報が多いことがよくあります。この違いは、交渉を記録するプロトコルと記録しないプロトコルを比べるときに意味を持ちます。

NetworkManager は自分が作成したプロファイルを所有し、基盤のプラグインが VPN ヘルパーであっても、そのメッセージは NetworkManager.service の下に残ります。プロファイルがその方式で管理されている場合は、マネージャーとヘルパーユニットの両方に問い合わせます。

問い合わせを一つのユニットと一つの時間枠に絞る

特定したユニットに問い合わせ、時間を調査対象の試行に限定します。通常は一日で足り、マシンが頻繁に再接続する場合はより短い枠が適しています。

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

問い合わせを信じる前にインストール名を確認する。ディストリビューションのパッケージはユニット名を変えるため、ファイルとして存在するプロファイルがサービスとして有効化されていないこともあります。ユニットが存在しない場合、空の journal はトンネルではなく配備について語っています。

最初に失敗した段階を読む

出来事を起きる順に読みます。エンドポイントの検索、トランスポート、身元、認証、ルート設定、その後のアプリケーションの失敗という流れの中で、最初の具体的な失敗こそ調べる価値があり、その後のすべては結果にすぎません。

正常に起動したサービスは、必要なリソースすべてに到達できることを証明しません。再接続ループは複数の別々の交渉を生むことがあるため、プロファイル名と試行時刻を出来事と一緒に保ち、統合されたストリームではなく一つの試行を読みます。単一の試行は原因を伴う順序であり、統合されたストリームは繰り返し行の壁です。さらに読む前に、最初のエラーをチケットに書きます。

失敗したサービスと手動クライアントを混ぜない

サービスが失敗した後に手動でクライアントを起動した場合、その出力は別の場所に送られ、挙動も異なることがあります。サポートされた修正の後、同じ所有者と同じ要求から新しい結果を取得し、二つの異なるプログラムを混ぜるのではなく、何が変わったかを比較で示します。

別のホストに合わせるために元のタイムスタンプを変更せず、タイムゾーンと既知の時計の差を別に記録してください。編集したタイムラインはもはや証拠ではないからです。

エクスポートではなく抜粋を共有する

journal の記録にはユーザー名、エンドポイントのアドレス、プライベートなトポロジ、スクリプト環境の情報が含まれることがあります。完全な無制限のエクスポートを公開するのではなく、実際の抜粋を確認して機密部分を伏せます。失敗を裏づける行を引用し、残りは要約します。短く確認済みの抜粋は、誰も読まないファイルより扱いやすいものです。

狭い時間枠、ユニット名、最初に失敗した段階を送り、すでに除外したことを伝えます。詳しくはsystemd journalctl のマニュアルがセレクターと出力オプションを説明しています（ディストリビューションの版が対応する形式が必要な場合）。