DPD 応答は IKE ピアが生きていることを示すのであって、データが流れていることを示すのではない
ライブネス応答、パディング通知、絞り込まれたセレクターは、それぞれ別のことを述べています。停止の原因を一つに決めつける前に、別々に読んでください。
IPsec のログには、その手前のアプリケーションが止まっている最中でもライブネス応答が現れることがあり、両方の事実が同時に成り立つことがあります。DPD 応答は、その時点でピアの IKE 処理が応答したことを示すものであり、子 SA が問題のパケットを運んでいるかどうかについては何も語りません。障害の近くにある警告をすべてその原因とみなすことが、セレクターの問題をプロトコルのバグと誤診する原因になります。とくに混同されやすい観察が三つあり、それらは三つの異なる問いに答えます。タイムスタンプで読む前に、関連と目的で読んでください。
各観察が何を証明するか
表は、各観察が何を確定するのかと、何を単に伴っているだけなのかを分けています。
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
三つのどれも、それ自体がエラーではありません。それぞれは、いま調査しているフローのそばにあって初めて意味を持ち、特定のフローに結び付けられない行は証拠ではなく文脈です。
ライブネスはデータの健全性ではない
DPD は INFORMATIONAL 交換として動作し、IKE デーモン間の制御プレーンの会話です。応答はピアの IKE プロセスに到達でき、応答する用意があることを証明し、タイムアウトはそうでないことを証明します。どちらの結果も子 SA、セレクター、転送経路、アプリケーションの応答を試すものではないため、停止した転送のそばの健全な DPD は矛盾ではなく一貫した状況です。
だからこそ、ログの先頭でどれほど安心させて見えても、ライブネスの行はデータプレーンのチケットで最も役に立たない部分です。
パディング通知はパディングについての言明である
TFC パディングは、このログで最も読み違えられる行です。トラフィックフロー秘匿のためのパディングがその子 SA では受け入れられない、という意味であり、ESP 保護の拒否ではなく任意のパディング機能についての言明です。障害の近くで見つかるのはたいてい冗長さの偶然であり、パディングをオンにしてもオフにしてもセレクターの網羅性は変わりません。
「IKEv2 仕様」は通知とセレクター交渉の両方を定義しており、実装の警告ラベルがどちらの場合もプロトコルの意味を置き換えることはありません。
絞り込みはより静かで、重要である可能性が高い
応答側は提示されたセレクターの一部だけを受け入れることがあり、受け入れた集合は複数のエントリーに分けて表示されます。一方はポート指定付きで、もう一方は全ポートを対象にします。最初のポート指定付きの行だけを読むと受け入れた範囲を過小評価し、広い行だけを読むと過大評価します。表示された提案とインストール済みのポリシーを比較してください。提案はピアが述べた内容であり、ポリシーはカーネルが照合する内容だからです。両者が食い違うと、トンネルはあるのに通信は通らないという、よくある断続的な不具合になります。ピアを比較するときはローカルとリモートの視点を入れ替えてください。各側のローカルは相手側のリモートだからです。
ポート制限付きのホスト固有エントリーは二度読む価値があります。ICMP や二番目のポートを除外しつつ、ゲートウェイへの ping は通したままにするのは、まさにそうしたエントリーだからです。
失敗しているフローについて一つの記録を作る
保護の判断時点で見える送信元、宛先、アドレスファミリー、プロトコル、ポートを、意図的な変換も含めて記録します。これらはセレクターと一致しなければならない値であり、チケットが三番目の担当者に渡ったときに記憶から打ち直される値でもあります。
次に、子 SA とその方向別カウンターを特定します。swanctl --list-sas は strongSwan ホストで関連の概要を表示し、ip -s xfrm state はカウンターを表示します。アイドル状態のときではなく、新しく許可された要求の後に読んでください。送信側の増加がなければ選択かローカル経路を示し、対応する受信のない送信はピア、その転送、またはその応答を示します。
完了したアプリケーションのやり取りはどちらのカウンターよりも優先されるため、テストはトンネルのインジケーターではなくアプリケーションで終えるべきです。
その後に修正を選ぶ
その記録が存在して初めて、選ぶべき修正が生まれます。受け入れられたセレクター、ルート、フィルタリング、ピアの実装、あるいは今回示した境界のいずれかです。ピアをリセットすると複数の状態が一度に変わり、どれが誤りだったのかを説明しないまま通信が回復することが多いため、障害は再発します。カーネルの状態ダンプもチケットから外してください。鍵を含むことがあり、助けを必要とする人には簡潔な要約で十分です。
記録が最初の仮説と矛盾するときは、記録を信じて仮説を書き直してください。その習慣は、ここで論じたどの単一のログ行よりも価値があります。