IPsecトンネルインターフェースの監視：何を読むべきか

ルートベースのIPsec設計では仮想インターフェースが導入され、そのインターフェースは監視に、名前・カウンター・そしてそれに紐づくルートを持つ具体的な対象を与えます。それ自体は健全性の信号ではありません。利用可能なアソシエーションがインストールされていなくてもインターフェースは存在し得ますし、関心のあるトラフィックをそちらへ送るルートがなくてもアソシエーションは健全であり得ます。四つの状態をまとめて読むことが、パケットカウンターを診断に変えます。

順番に確認し、最初に失敗した状態で止めてください。

インターフェースが全体像に加えるもの

ポリシーベースの設計では、選択はIPsecポリシーテーブルにあり、カーネルがトラフィックセレクターに基づいて何を保護するかを決めます。ルートベースの設計はインターフェースとルートを追加するため、tcpdumpとインターフェースのカウンターはセレクターの集合ではなく一つの境界を見ます。これは診断にとっても、peeringのためにインターフェースを必要とするルーティングプロトコルにとっても実際の利点です。

利点は運用的なものであり、暗号的なものではありません。インターフェースは通過するトラフィックを報告しますが、相手側の保護が現在使えるかどうかについては何も語りません。

トンネルを疑う前に四つの状態を読む

インターフェースとルートから始め、次にアソシエーション、次にアプリケーションです。それぞれに独自のコマンドと独自の障害の痕跡があります。ある層で健全な結果は、次の層で健全な結果ではありません。結論を出す前に四つすべてを実行してください。緑の一行だけで決着がつくことはまれです。

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

カウンターが増えているのに対応する状態エントリがないインターフェースは、何も保護していない経路にトラフィックが入っていることを示し、これは単に落ちているトンネルより悪い状態です。インターフェースを選ぶルートのない状態エントリは、暗号が準備済みで未使用であることを意味します。

アプリケーションのテストが最後に来るのは意図的であり、トンネルの向こう側へのpingの成功は、その背後のサービスが接続を受け付けることを証明しません。

内側のカウンターと外側のカウンターを比較する

トンネルインターフェースのカウンターは内側のトラフィックを測り、物理インターフェースのカウンターとキャプチャはカプセル化されたやり取りを示します。両者は、カプセル化がヘッダーを追加し、再送が一部のパケットを複製し、実装の計数が独自の規則に従うため、一対一では一致しません。等しさではなく比率を期待してください。

キャプチャの位置は、どの個人データを集めるかも決めるため、本番トラフィックの完全なキャプチャではなく、狭いフィルターと無害なテストアドレスを使ってください。

内側の計数が増えて外側が増えない場合、欠けているのは通常パケットをトンネルへ送るルートまたはポリシーであり、トンネル自体ではありません。

鍵の更新とフェイルオーバーを通して観察する

同じ四つの状態を見ながら、鍵の更新、死んだピアの検出イベント、リンクのフェイルオーバーを観察してください。決して完了しない鍵の更新の間もインターフェースは存在し続けることがあり、フェイルオーバーは到達できなくなったピアアドレスを指す状態エントリを残すことがあります。

実際に依存しているサービス経路に対して、単一のアップ／ダウンのフラグではなく、アソシエーションの状態を文脈としてアラートを出してください。インターフェース名、ピアアドレス、ルートをアラートのペイロードに残し、対応する人が再構築しなくて済むようにします。

strongSwanは独自のXFRMインターフェースモデルを文書化しており、他のプラットフォームは同等のオブジェクトを別の名前と方法で実装しています。別の実装から前提を持ち込む前に、目の前の機器についてルートベースの比較を読んでください。あるベンダーのカウンターに合う監視テンプレートは、別のベンダーでは静かに誤解を招きます。