レポートでいう「VPN ログイン成功」とは何を数えるのか
認証、初期化済みのトンネル、実際に通ったリクエストは三つの異なる結果です。何かを数える前に、レポートがどれを測るのかを決めてください。
同じ VPN についての三つのレポートは、どれも誤りでなくても食い違うことがある。成功したログインという言葉が、それぞれで別のものを指しているからだ。一つはサーバーに到達した接続を数え、もう一つは認証の段階が受け入れた身元を数え、三つ目は初期化を終えたセッションを数える。データを集める前にどれを選ぶかが、指標と主張の分かれ目になる。
役に立つ問いは、一般論としてどの定義が正しいかではなく、読み手がどの結果に基づいて行動するかである。
三つの異なる事象が同じ名前をまとう
サーバーはハンドシェイクが終わった時点でトランスポート接続を受け入れるが、これは資格情報が提示される前に起きる。この事象が示すのはポートに到達でき、ネットワーク経路が機能しているということで、誰が接続したかについては何も示さない。認証はその後の段階で、失敗することもあれば、ネットワークへの接続を一度も許可されない身元に対しても成功することがある。
初期化は認証の後に来るが、初期化を終えたトンネルがそのまま一日中遊んでいることもある。アプリケーションのリクエストだけが、利用者が欲しかったものに到達したことを示す事象だ。これらの段階は入れ子になっているので、最も広い段階の数は常に最も狭い段階の数を上回る。事象の並びのどこにも、利用者が生産的だったことは示されず、各関門が順に開いたことしか示されない。
製品のドキュメントは通常、状態を明示的に名づけている。OpenVPN の 管理インターフェースのメモ は、TCP 接続、認証の結果、初期化の完了を分けており、まさにレポートが必要とする区別である。connected と表示された状態は、その後にファイル共有やデータベース操作が成功したことを保証しない。
セッション、身元、リクエストのどれを数えるか
数を決める前に単位を決める。セッション数はサービスが何回使われたかに答え、身元の数は何個の異なるアカウントが現れたかに答え、リクエスト数はどれだけの仕事が行われたかに答える。ベンダーもこれを別々に数えており、ユーザーで測った権利はセッションで測ったグラフとは比べられない。誤った単位を選ぶと、容量計画が誤った量に合わせて作られてしまう。
再接続はセッション数が静かに膨らむ場所だ。数分おきに切れて再接続するクライアントは、一人の人間に対して数十件のセッションレコードを生む。だからセッションを人数として数えるレポートは、信頼性が最も悪い状況でこそ利用を過大に示す。ルールを書き留めておこう。再接続後の新しいセッションは別に数えるか、定めた時間内なら前のセッションの継続とみなす。
アドレスは手に入る最も弱い身元だ。トンネルのアドレスは数分後に別の利用者へ割り当てられることがあり、二人の利用者が変換を介して一つのアドレスを共有することもある。ログのアドレスから人を推測するのではなく、認証の事象から得たアカウント識別子を結びつけるべきだ。
定義を実際の一日で試す
一日分のログを取り、同じ通信を三つの方法で数える。三つの数が近ければ、目的にとって定義はあまり重要でないかもしれない。大きく食い違うなら、レポートはどれを使うのかを書く必要がある。
journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Initialization Sequence Completed"
journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Peer Connection Initiated"
awk '/VERIFY OK/ {print $NF}' /var/log/openvpn-server.log | sort -u | wc -l
既知の障害があった日に同じ抽出を実行し、合計ではなく形を比べる。上流リンクが揺れた日なら、接続の事象が跳ね上がり、異なるアカウント数は控えめに増えるはずだ。そうならないなら、そのカウンターはレポートが主張するものとは別のものを測っている可能性が高い。
結果と一緒にクエリそのものを残す。文書化されたフィルタは誰でも再現できるし、フィルタのない数は監査できない。
事象が何を立証するかを報告する
失敗した試行は、どちらかの側に折り込むのではなく、独自の分類を与えるべきだ。失敗には打ち間違えたパスワード、古いプロファイルのクライアント、意図的な探索が含まれ、三つはそれぞれ対応が違う。失敗は侵入の成功を示す証拠ではなく、無害さの証拠でもない。
結論は事象が支える強さで書く。このアカウントはこの時間帯にこのサービスへこの送信元から認証し、セッションは初期化に達した。その後に利用者が何をしたかについては、トンネルのデータを増やすのではなく、アプリケーション側の記録が要る。
レポートがライセンス、容量、セキュリティの判断をする人の元へ行くなら、定義は脚注ではなく最初の行に置く。定義こそが所見であり、数はその内側でしか意味を持たない。