ローカルシステムログが VPN 接続について明かすこと

オペレーティングシステムは、アプリが決して書き残さないサービスの起動、アダプターの変更、ルートの失敗を記録している。狭い時間窓をひとつ読み、突き合わせる。

どのデスクトップも VPN が何をしたかを独自に記録しており、アプリの書き出しはたいていその中で最も不完全なものだ。サービスマネージャーはユニットがいつ起動したかを記し、カーネルはインターフェースがいつ現れたかを記し、ネットワークスタックはルートがいつ適用できなかったかを記す。これらの仕組みはいずれもクライアントが何を意図したかを知らず、クライアントはカーネルが自分の要求をどう扱ったかを知らない。

そのような記録をひとつだけ切り離して読むと、誤った結論に誘われる。同じ一分の二つを読めば、順序が見えてくる。

三つの仕組み、三つの語彙

Linux では systemd ジャーナルが wg-quick@wg0 や NetworkManager の VPN プラグインからユニットのライフサイクルメッセージを捉え、カーネルのリングバッファーがインターフェースとルーティングのメッセージを運ぶ。Windows ではイベントログが物語をシステム、WLAN、リモートアクセスの各プロバイダーに分けており、それぞれ独自の識別子を持つ。macOS では統合ログがサブシステムに限定されたメッセージを運び、グラフィカルな Console はその一部しか表示しない。

語彙は翻訳できない。あるプラットフォームのイベント識別子は別のプラットフォームでは何の意味も持たず、Windows のダイアログのスクリーンショットは Linux のユニットについて何も証明しない。

三つに共通するのはタイムスタンプ、発生源、重大度であり、この三つ組がクライアントログとオペレーティングシステムの記録の突き合わせを可能にする。可用性も一様ではない：ジャーナルのないコンテナ、削られた Windows イメージ、ビルド時に下げられたログレベルは、層ひとつを丸ごと隠しうる。

FacilityWhat it recordsWhat it cannot show
systemd journalUnit start and stop, helper output, exit statusWhether packets actually reached the peer
Kernel and netlinkInterface creation, address assignment, route changesWhy the client asked for that configuration
Windows event logProvider-specific connection and adapter eventsAnything the provider chose not to log

接続済みの一行が証明することと、しないこと

サービスの起動イベントは、ローカルのユニットに起動が要求され、すぐには終了しなかったことを記録する。完了したハンドシェイクも、有効なピア鍵も、機能するルートも記録しない。その一行をトンネルの証拠とみなすのは、これらのログで最もよくある誤読だ。その行が証明するのは意図とプロセスの状態だけで、到達性については何も証明しない。

転送の状態は別の観察であり、どのログからではなくルーティングテーブルから来る。

アダプターのイベントは静かな失敗を説明できる：インターフェースが上がり、アドレスが割り当てられ、ポリシー規則が拒否したためにルートが一度も設置されなかった、という順序だ。その並びでは、何も転送されていないのに見える行はすべて健全に見え、それを見る唯一の方法は同じ瞬間のルーティングテーブルとログのタイムスタンプを比べることだ。何を要求したかを知っている唯一の情報源はクライアントなのだから、クライアント自身のイベント順序を両者の隣に置いておくこと。一緒に必要な二つの事実が同じ行に現れることは、ほとんどない。

後から再接続すると、この像の興味深い部分は上書きされるので、三度の再試行のあとではなく、最初の失敗の時点で窓を取得しておく。

狭い時間窓を突き合わせる

試行の時刻をタイムゾーンとともに記録し、その前後の数分を抜き出す。窓の中の最初のエラーは、サポートチケットが引用する切断行よりもほぼ必ず前にある。

journalctl -u wg-quick@wg0 --since "today 09:00" --until "today 09:20"
ip route show table all | grep wg0
log show --last 20m --predicate 'subsystem == "com.apple.network"'

各コマンドは問いの別の部分に答える：一つ目はライフサイクル、二つ目は転送の状態、三つ目は macOS のネットワークサブシステムだ。Windows ではチャネル全体をスクロールするのではなくプロバイダー名でシステムログを絞り込み、一致するイベントだけを書き出す。

抜粋は読み手が追える程度に小さく保つ。関連するイベントが四つある二十分の窓は結論を支えるが、何千行もの丸一日の書き出しは何も支えない。

これらの記録が止まる場所

ローカルの記録が描写するのは端末であり、経路ではない。プロバイダーが何を保存したか、セッションがアカウントに紐づけられたか、宛先が何を見たかは示せない。ログを保持しないというプロバイダーの説明は、あなたのノート PC のオペレーティングシステムについて何も語らず、ローカルのイベントはプロバイダーの過去の記録について何も証明しない。

予想より多くの個人データも含む：ユーザー名、ホスト名、マウントパス、端末識別子は、閲覧内容がまったくなくても普通のシステムメッセージに現れる。チケットに何かを添付する前にそれらを取り除き、原本は通常のアクセス制御の下に置く。

管理された端末では、組織のログを消そうとするのではなく、IT に関連する抜粋を求める。診断の目的は二つの情報源が答えるひとつの狭い問いであって、機械の完全な履歴ではない。

関連記事