SNMP や API を選ぶ前に VPN の対象を定めよ

通信方式より先に、アラートがどの対象を記述するのか、どの方向と範囲を覆うのか、どれほど新しい読み取りが必要なのかという三つの決定がある。SNMP、HTTPS API、アプリケーションプローブはいずれも VPN について何かを報告できるが、同じものを報告するわけではない。この三つを決めずにプロトコルを替えても、混乱が集まる場所が変わるだけだ。対象とアラートの意味が設計であり、プロトコルは配送にすぎない。

四つの異なる観測を一つの緑のアイコンに変えるダッシュボードは、すでにその決定を誤っている。

アラートは本来何を意味すべきか。

相手が認証できない、保護されたデータ状態が存在しない、経路が誤った場所を指す、アプリケーションが作業を終えられない、のいずれかを意味しうる。どれにも 固有の所有者と最初の確認、固有の誤検知率がある。認証できない相手は識別の問題であり、欠けたセキュリティアソシエーションはプロトコル状態の問題であり、経路は設定の問題であり、アプリケーションの失敗はどれでもないかもしれない。収集手段を選ぶ前に、アラートがどれを対象とするかを決めよ。

オンコールの技術者が行動できる文として書け。文が二つの対象を必要とするなら、それは二つのアラートであり、半分正しい一つではない。

TCP テーブルが記述するのは TCP だ

RFC 4022 は tcpConnectionTable を規定し、その行は確立済みの TCP 接続を、両端のアドレス種別・アドレス・ポートをキーとして記述する。接続が閉じると行は消え、待ち受けソケットは別のテーブルに現れる。同じ筐体で VPN を動かしても、TCP テーブルが IPsec セキュリティアソシエーションの一覧になるわけではない。管理セッション、アプリケーションのフロー、TCP 上で運ばれるトンネルのいずれかを記述しうるが、行そのものはどれかを教えてくれない。

インターフェースのカウンタは、より粗い水準で、インターフェース上のバイト数がそれを使うすべての相手とすべてのフローを合算するという同じ曖昧さを抱える。

小さな観測契約を組み立てる

各メトリックについて、対応する対象や API フィールド、所有する機器とソフトウェア版、相手やサービスの識別子、方向、収集時刻、期待される更新の挙動を記録する。そのうえで、プロトコル状態にはゲートウェイの文書化されたアソシエーション表示やセッション表示、経路状態には経路テーブル、アプリケーション状態には範囲を絞った許可済み要求を使う。管理エンドポイントが動くことは、管理エンドポイントが動くことの証明であり、その背後のアプリケーションについては何も語らない。

導入済みのエージェントに必要な対象がなければ、明示的に対応する別の読み取り専用インターフェースを選ぶ。OID をでっち上げる、一般的な TCP 数をトンネル数として読む、古いベンダー API が兄弟製品でも変わらず残ると期待する、いずれも行き止まりだ。

古いデータはトンネルの故障ではない

収集のタイムアウト、期限切れの資格情報、変更された API 経路は、欠測のテレメトリを生む。それは監視の失敗であり、落ちたトンネルとは別のインシデントだ。どの観測がいつ古くなったかを記録し、運用者がトンネルのリセットではなく意味のある最初の確認を得られるようにする。あらゆるタイムアウトを VPN 障害として扱うと、人は両方とも無視するようになる。

収集の権限も狭く保て。設定を変えたりセッションを消したりできるインターフェースは、監視作業が引き継ぐべきでない特権の境界を持ち、読み取り専用のアカウントで通常は足りる。

有用な設計は、対象と意味と鮮度の要件を名指しする。プロトコルの選択はそこから導かれ、その逆ではない。