ステータスファイルが数えるのはセッションであり、その背後のLANではない

VPN 上に何台のマシンがあるのかと問われ、証拠としてステータスファイルが示される。このファイルが答えるのはもっと狭い問いだ。このスナップショットにいくつのセッションがあり、サーバーがどの仮想アドレスをルーティングしているか。二つの問いの間の隔たりこそ、報告の誤りのほとんどが生まれる場所であり、そこを埋めるにはファイル自身のヘッダーを読むことから始まる。

スナップショットに実際に含まれるもの

このファイルは、そのサーバーインスタンスでステータス出力が設定されているとき一定間隔で書き込まれるため、ライブのフィードではなく周期的な写真である。各セクションはセッションと内部ルーティング状態を分けて一覧し、フォーマットのバージョンが列の配置を決める。

status /run/openvpn/office.status 30
status-version 3

バージョン 3 はヘッダー行を伴うタブ区切りのフィールドを書き、古いフォーマットは異なり、新しいバージョンではフィールドが増えることがある。列番号を固定するのではなくヘッダーを読むべきだ。位置を前提にしたスクリプトは次のアップグレードで静かに壊れる。

数えるのはセッションであり、人やマシンではない

拠点の接続ひとつが、その背後の複数の認可済みマシンの通信を運ぶことがある。ひとりの人物がノートPCとスマートフォンから同時に複数のセッションを持つこともある。どちらのパターンも件数には現れないため、接続ユーザー数は単位を定義してはじめて意味を持つ。誰かが数え始める前に、レポートに必要な単位を問うべきだ。

その数がライセンスや容量に関わるなら、レポートと同じ文書で単位を定義する。セッション、ID、デバイスのどれを数えるのかを書かないレポートは、読み手が想定した単位として読まれてしまう。

外側のアドレスは識別子ではない

実アドレスのフィールドは、サーバーから見たピアのアドレスとポートだ。翻訳されたひとつの公開アドレスの背後にいる複数のクライアントはそのアドレスを共有するため、それでグループ化すると無関係なセッションが混ざる。ポートも接続ごとに変わるので、この組は安定したキーとしては使えない。そうやって集計したレポートは精緻に見えて誤っている。

グループ化には実効的なクライアント ID を使い、アドレスはトランスポートの詳細として扱う。二つの行が同じ ID を共有しているときは、通常は重複レコードではなく同時セッションを意味する。

ルーティング行はホストの棚卸しではない

ルーティングの項目は、あるピアが責任を持つサブネットを示すことがあり、サブネットはそのホストの一覧ではない。サーバーはその範囲を特定のセッションへ送るべきだと知っているが、そのマシンのどれが電源の入った状態か、アプリケーションで認証済みか、誰かの役に立つかは知らない。ルーティングテーブルが示すのは到達可能性であり、稼働状況ではない。この違いこそ、VPN が棚卸しの問いに答えられない理由そのものだ。

複数の行が同じピアを指すこともある。拠点が複数の範囲を広告することがあるからだ。行を数えてデバイス数と呼ぶと、導入規模を恣意的な倍率で過大に見積もることになる。

要件が本当に資産の棚卸しなら、そのネットワークを管理する棚卸しプロセスを使う。VPN はどのピアが経路を運んでいるかを特定できるが、それは背後にどのホストが存在するかとは別の事実だ。

鮮度、権限、ライブ表示

回答には必ずファイルの更新時刻を添える。数時間前に停止したサーバーは最後のスナップショットをそのまま残すし、古いファイルを最新として示すのは、レポートが無いより悪い。

ディレクトリは存在し、サービスが実際に動作しているアカウントで書き込める必要がある。堅牢化の作業のあとでは忘れやすい。ファイルには通常、名前とアドレスが含まれるので、Web サーバーが配信できる場所ではなく管理用の場所に置く。権限は自分のシェルではなくサービスアカウントで確認する。黙って更新が止まったスナップショットは、静かなネットワークとまったく同じに見える。

イベント駆動の要件には、ポーリングを速めるのではなく、サポートされている管理インターフェースを使う。そのインターフェースはメトリクスではなく制御として扱い、セッションを数えるためだけにインターネットへ公開してはならない。