Ansible タスクを書く前に、もっと小さな問いに答えてください。何を数えているのでしょうか。設定済みピア、IKE セッション、IPsec セキュリティ アソシエーション、監視対象のトンネル状態レコードは四つの異なる単位であり、鍵の再生成や複数の保護ネットワークによって合計は食い違います。ダッシュボードと playbook が一致しないとき、多くはどちらかが間違っているのではなく、別のものを数えています。

人が「アクティブ」と呼ぶ四つのもの

設定済みピアはトポロジのオブジェクトです。誰かが定義したから存在します。IKE セッションは制御プレーンの関係で、トラフィックが流れていなくても確立できます。IPsec SA は特定のセレクタ ペアに対するデータプレーンのアソシエーションで、一つのトンネルが複数を運べます。監視対象のトンネル状態はプラットフォーム自身の運用上の判定であり、通常は運用者が「トンネルが上がっている」と言うときに意味するものに最も近いものです。

運用上の数え方の根拠として妥当なのは最後の一つだけです。最初のものは構成の棚卸しであり、それをアクティブとして報告するのは、火曜日から落ちているピアに対してダッシュボードが緑を表示する仕組みです。数字の利用者にどの単位が必要かを決め、その単位をメトリクスの名前に含めてください。

第一の判断:どの管理プレーンか

デバイスが FDM で管理されているなら、対象となる面は FTD REST API です。FMC で管理されているなら、その API は互換の代替ではなく、オブジェクトは FMC 自身の API の背後にあります。リクエストを一つ書く前にこれを確認してください。間違ったプレーンは、権限の問題に見えるもっともらしいエラーを返します。

フリートの場合、答えは数え上げをどこに置くかも決めます。FDM 経由のデバイス単位か、FMC 経由のドメイン単位か。これらは異なる範囲であり、同じフリートでも異なる数字になります。

第二の判断:どのリソースが答えるか

バージョンに縛られた例として、FMC 7.3 API のオブジェクト リファレンスは health パス配下の GET リソースを記載しています。

/api/fmc_config/v1/domain/{domainUUID}/health/tunnelstatuses
/api/fmc_config/v1/domain/{domainUUID}/health/tunnelsummaries

トンネル状態リソースはデバイスと状態のフィルタをサポートし、TUNNEL_UPも含みます。これにより、そのリリースで確認できる実際の運用リソースが得られ、フィールド名の推測に頼る必要はありません。

パーサーを実装する前に、導入済み FMC の API Explorer で可用性、権限、リクエスト パラメータ、レスポンス スキーマを確認してください。あるバージョンのドキュメントは出発点であり、実行しているバージョンの契約ではありません。

数え方の契約を書く

メトリクスを一文で述べてください。意図した一つのデバイスとドメインについて、報告された状態が TUNNEL_UP である一意の運用トンネル レコード。次に、冗長なデバイスと一つの論理サイトに対する複数レコードがどう表現されるかを記録してください。この二つのケースが、あなたの数字が会議の数字と一致するかどうかを決めます。

単位をトンネル レコードから遠隔サイトへ黙って変えないでください。ビジネスがサイトを求めているなら、レコードをサイトに明示的にマッピングし、そのマッピングを公開します。静かに自己定義を変える数え方は、いつ変わったか誰にも分からないため、数えないより悪いものです。

サマリー リソースは、何を要約しているかを確認した後でのみ便利なものとして扱ってください。必要なものを正確に集計しているかもしれませんし、微妙に異なる問いに答えているかもしれません。スキーマを一度読み、違いを書き留め、要約を説明できないなら状態リソースを使ってください。理解できない要約は、レビューで弁護できない数字です。

ワークフローに不確実性を残させる

承認された HTTPS API を使い、証明書を検証し、トークンをタスク出力の外に保ち、そのリリースがサポートするフィルタとページネーションで範囲を取得してください。その後、何かを計算する前にスキーマを検証します。

fetch intended domain/device runtime records
validate response, completeness and freshness
deduplicate by the documented tunnel identity
count records matching the approved up-state definition
report count with scope, timestamp and metric unit

これはワークフローの疑似コードであり、テスト済みの playbook ではありません。active という名前の JSON キーを発明するのではなく、インストール済み API から実際のフィールド名を取ってください。

重要な原則は失敗時の振る舞いです。認可エラー、未サポートのリソース、古いサンプル、不完全なページ集合は unknown または error を生み出すべきで、成功したゼロにしてはいけません。問い合わせられなかったことを意味するゼロは、最も高くつく種類の誤りです。

プラットフォーム自身の見方に対して検証する

最初の結果を、同じデバイスと同じ時点について、そのリリースの VPN 監視ビューと比較してください。異なる場合は、playbook を変える前にどちらがどの単位を使っているかを突き止めます。

実行ごとに秘密でないコンテキストを残してください。範囲、タイムスタンプ、メトリクスの単位、レコード数。FMC 7.3 API のオブジェクト リファレンスが上記のリソース パスの出典であり、自分の導入環境の API Explorer がその他すべての出典です。

関連記事