鍵を公開せずに IPsec の状態を確認する方法

IPsec の状態ダンプは状態報告書ではなく、そう扱うことこそが鍵素材を公開の課題トラッカーに載せてしまう道です。カーネルの検査出力には、カーネルが使っている通信鍵が、アドレス、セレクタ、本当に役立つカウンタとともに含まれることがあります。安全な習慣は、まず要約を集め、要約で問いに答えられないときだけ生の状態に手を伸ばすことです。生の状態を見なければならない場合でも、ローカルで見て、より狭い範囲だけを共有してください。

確認 1：この成果物はそもそもマシンの外に出せるのか

設定ファイル、秘密鍵、無制限のパケットキャプチャ、生の状態ダンプは、反証がない限りすべて秘密です。鍵を表示するコマンドは、診断のために実行したという理由で安全になるわけではありません。

ルールは一文で言えるほど単純で、共有すべきは問いに答える観察であって、それを生んだマシンの状態ではありません。

確認 2：状態ダンプではなく要約コマンドを選ぶ

strongSwan では swanctl --list-sas が、ID、導入済みの子 SA、状態、カウンタというアソシエーションの要約を表示します。生の鍵ダンプは不要で、チケットに最初に貼るべきものです。カーネル側では、このオプションを文書化しているバージョンで iproute2 が ip xfrm state list nokeys に対応しており、アソシエーションのフィールドを保ったまま鍵素材を伏せます。

当てにする前に、このオプションがすべてのリリースにあるわけではなく、それなしの一般的な状態一覧は別の出力を持つ別のコマンドだからという理由で、ローカルのマニュアルで構文を確認してください。古いビルドで ip xfrm state を実行してフラグの有無を確かめるのは、まさにこのチェックリストが扱う誤りです。

確認 3：調査に必要なものだけを記録する

アソシエーションの状態、アルゴリズム、セレクタ、タイムスタンプ、方向、該当するカウンタで通常は足ります。アカウント ID、公開アドレス、内部トポロジーは足りないことが多く、診断価値を失わずに伏せられます。

既定で伏せ、求められたら戻します。チケットを読む人はフィールドを一つ追加で頼めますが、貼ってしまった鍵を見なかったことにはできません。

知っておく価値のある中間案として、要約もなお機微になり得ることを挙げておきます。ID、ピアのアドレス、子 SA の名前はあなたのトポロジーを語るもので、組織によってはそれ自体が限定情報です。貼る前に誰が読むのかを決め、公開の課題より適切なアクセス制御のある経路を選んでください。安全なコマンドは安全な宛先と同じではありません。

確認 4：両端で一つの試行を突き合わせる

同じ接続試行についてクライアントとゲートウェイを同時に取得し、説明しているアソシエーションがその試行が生んだものだと確かめてください。以前の試行の古い子 SA を新しい経路のスナップショットと混ぜると、内部的には整合していて完全に誤導的な報告になります。

アソシエーションはトンネルではなく一意の識別子で特定し、失敗の方向を書き留めてください。症状が一方向の通信欠如なら、どちらの方向かを述べ、読者が推測ではなく経路を考えられるよう無害な試験宛先を添えてください。 一方向ではゼロで、もう一方向では増えていくカウンタ は、どんな鍵ダンプよりもはるかによく問題を切り分けます。タイムスタンプは一つのタイムゾーンに揃え、どれかを明記してください。

確認 5：素材がすでに露出してしまった場合

添付を削除しても誰も保持していないことの証明にはならず、公開の貼り付けはすぐにコピーされます。

これをインシデントとして扱い、影響を受けた鍵や資格情報のローテーション、露出がより広い侵害を意味しないかの確認、該当する通知経路の遵守という運用者の交換手順に従ってください。技術的な後始末は簡単な部分で、誰も読んでいないという前提のほうが難しい部分です。

長続きするやり方は、貼る前に埋める小さなひな形で、どちらの端か、どのアソシエーション識別子か、どの方向か、どのカウンタか、何がすでに除外されたかを書きます。 swanctl list-sas のドキュメント には要約のフィールドが書かれており、ほとんどのチケットが実際に必要とするのはそれです。それ以外は必要とする人に求められれば提供できます。診断報告書に含めるべきは証拠であって、アクセス権ではありません。