IPsec の子 SA は稼働中、しかしパケットカウンタはゼロのまま

トンネルを立ち上げ、リキーのタイマーはカウントダウンを続け、両方向ともまだゼロパケットを示しています。この二つの数字は、ピアがトンネルを拒否したことを意味しません。アイドル状態のカウンタを持つインストール済みの CHILD SA は、まだ何も一致していない関連の正常な状態です。やるべきことは、パケットが一致すべきだったと証明し、そのうえでセレクタが示す経路から外れた地点を見つけることです。一度だけ、順序どおりに行い、実行の間で要求を同一に保ってください。

ゼロカウンタが実際に証明するもの

CHILD SA はセレクタの組に その範囲に入る通信を暗号化する鍵と SPI を加えたものです。インストールとは、両ピアがその範囲と派生した鍵に合意したというだけの意味で、カーネルはパケットが一つも届かなくても何時間も保持します。したがって問いは常にトンネルの有無ではなく、テストのパケットが両ピアの合意した範囲に入ったかどうかです。入らなければカウンタはゼロのままで、関連は寿命の終わりに未使用のまま失効します。

この区別は、最初に何を調べるかを変えます。拒否された提案、認証の失敗、死にかけた IKE SA はいずれもログや SA 一覧に現れ、静かなゼロとしては現れません。きれいに交渉してからアイドルのままのトンネルは、むしろ一致、ルーティング、テスト通信の発生元を指します。

送る前に説明できるフローを送る

保護されたサブネット内の宛先を選び、それへの新しい接続を開いてください。一時間前に読み込んだページはキャッシュから返されることがあり、キャッシュされた応答はトンネルに触れません。次に、要求がまだ仮説のうちに四つの値を書き留めます。アプリケーションが束縛する送信元アドレス、宛先、アドレスファミリ、そして監視している子の名前またはセレクタの組です。その記録が、平坦なカウンタを検証可能な主張に変えます。

送信元アドレスは人が飛ばしがちな値で、テストを最も頻繁に壊すのもこれです。有線アドレス、Wi-Fi アドレス、トンネルアドレスを持つノート PC は、ルート検索に応じてそのどれでも束縛でき、合意した範囲に入るのは一つだけかもしれません。ping -I 10.1.0.5 10.2.0.9 や curl --interface 10.1.0.5 のように送信元を固定できる道具を使い、パケットが黙って別のアドレスを選ばないようにしてください。固定した実行でカウンタが動き、固定しない実行で動かなければ、見つけたのは IPsec の問題ではなくルーティングの問題です。

どの数字を読み、どこに住んでいるか

Linux では ip -s xfrm state が各関連を、バイト合計とパケット合計がその SA だけに属する lifetime current: 行とともに出力し、続いてリプレイとエラーのカウンタ用の stats: 行が来ます。strongSwan のピアでは swanctl --list-sas がインストール済みの子ごとに in 行と out 行を一つずつ示し、どちらもバイト数とパケット数で終わります。古い stroke 系の道具は同じ組を bytes_i と bytes_o と呼びます。二つの方向は別々に読み、平坦なままの方向こそが所見です。足し合わせると、探している非対称がちょうど隠れます。

どちらの表示も関連ごとなので、リキーは新しい SPI の組をインストールし、何も壊れないまま基準線はゼロに戻ります。リキーのタイマーが発火する前に監視している SPI を記録してください。そうしないと新しい SA を古い数字と比べることになります。外向きが増えて内向きが平坦なら、セレクタは一致し、応答は戻ってこなかったので、調査はピアの転送とそのポリシーへ移ります。strongSwan の IKEv2 設定ドキュメント は子 SA のライフサイクルと、その数字の背後にあるリキーのタイミングを扱っています。

観測点はパケットの発生元とは別の変数です。ハードウェアオフロードは関連のカウンタを増やしても、インターフェース上のソフトウェアキャプチャには何も映りません。オフロードされたパケットはキャプチャが座るフックを飛ばすからで、内向きも同じように食い違います。両者が一致しないときは、何かが一致したかはカウンタで、パケットがどんな姿だったかはキャプチャで答えてください。

ルート、セレクタ、そしてパケットが生まれた場所

三つを並べて比べます。カーネルが宛先に対して選ぶルート、通信をトンネルへ導くポリシー、子が交渉したセレクタの組です。ip route get 10.2.0.9 from 10.1.0.5 はカーネルが使うインターフェースと送信元を示し、それは多くの場合あなたが想定した組ではありません。ip xfrm policy はローカルにインストールされたテンプレートとセレクタを示し、swanctl --list-sas はピアが何に合意したかを示します。パケットを物理インターフェースから出してしまう検索はポリシーにまったく届かないので、カウンタは動きません。

不一致にはいくつかの形があり、カウンタからは同じに見えます。IPv4 セレクタの外にある IPv6 宛先、誤ったサブネットの送信元アドレス、子より狭いポリシーは、いずれも同じゼロを生みます。まず最も狭い原因を直してください。数字を動かすためだけにセレクタを広げるのは、トンネルが守るものを変えてしまいます。

次にパケットの発生元があります。ゲートウェイが自分自身の運用者に仕掛ける罠です。ゲートウェイ自身が生成する通信は出力ポリシーと照合され、クライアントのために転送するパケットは転送ポリシーと照合されるので、そのマシンからの ping はどのクライアントも通らない経路で成功しえます。

一つの可逆な変更と、レビューに耐える報告

要素を一つだけ変え、同一の要求を繰り返し、同じカウンタを読みます。ファイアウォールの規則をすべて消す、あるいはセレクタをすべて一度に置き換えると、数字は動いても、理由を教えてくれた証拠は壊れます。二度目の実行でもゼロなら、午後を無駄にせず仮説を一つ消したことになります。

所見は他の人が再現できる形で書きます。子の名前、受け入れた範囲、固定した送信元、試した宛先、ゼロのままだった方向、読んでいた SPI です。その一文が、誰も使わなかった関連と、通信を受け取って拒否した遠隔アプリケーションを分けます。カウンタが動かなかったときは変更を戻し、記録は残してください。次の人はあなたが止まった場所から始めます。このすべてのためにトンネルを作り直す必要はなく、設定に触れる前に一致を確認する意味はそこにあります。