strongSwanのtrapモード：IPsecトンネルがトラフィックを待つ理由

ステータス出力にCHILD SAが現れず、トンネルは死んだように見え、その後に遠隔サブネットへのpingで上がる。オンデマンドIPsec構成ではこの順序が設計であり、故障ではない。trapポリシーはセレクターをインストールして待ち、それに一致する最初のパケットがIKEとCHILD SAのネゴシエーションを開始する。

混乱の一部は用語にある。「up」は二つの異なる状態に使われる。 設定はロードされ、カーネルポリシーは存在するが、データアソシエーションは存在しない。アクティブなSAだけを数える監視は、誰もトラフィックを送らない限り、健全なサイトをダウンと報告する。

待機中のオンデマンドトンネルには表示できるCHILD SAがない

trapエントリ自体は何も認証しない。選択したトラフィックのポリシーをカーネルに保持させ、パケットがそのポリシーを必要とするときにacquisitionを起こすよう求める。デーモンはacquisitionを受け取り、child定義と照合し、そこからネゴシエーションする。その時点まで表示できるIKE SAもないため、両方のリストが同時に空になり得る。

この順序がログを読みやすくする。まずacquisition、次にIKE_SA_INITとIKE_AUTH、そしてCHILD SA。ログがacquisitionの直後で終わるなら、トリガーは機能した。ネゴシエーションが失敗しており、次の問いは資格情報、提案、到達性についてであり、trapについてではない。

Linuxカーネルバックエンドなら、どのSAも存在する前にポリシーを確認できる。実行するのは ip xfrm policy。方向outで接続を指すテンプレートを持つセレクターを探す。そのエントリがオンデマンド状態であり、その存在が最初に確認すべきことだ。

start_actionは何かが待つかどうかを決める

各childの swanctl.conf には start_action. start は設定のロード時に開始し、trap はポリシーをインストールして待ち、none は開始を他の何かに任せる。待つのは trap だけが上記の「pingで上がる」挙動を生む。

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

二つのトラフィックセレクターが何を対象とみなすかを定義する。これらのプレフィックス外のホストからのパケットはtrapを発火させず、通常どおりルーティングされる。トリガーを敏感にするためにセレクターを広げると、トンネルが保護すると称する範囲も広がるので、実際に暗号化したいトラフィックから導くこと。

swanctl.confリファレンス には受け入れられる値が、SAが存在した後の動作を決める個別のcloseとDPDアクションとともに列挙されている。

トリガーが発火したかどうかを確かめる

まず swanctl --list-conns で、childが意図したアクションでロードされていることを確認する。次に local_ts 内のホストから remote_ts 内のアドレスへパケットを一つ送り、swanctl --list-sas を監視する。出力が変わらなければ、acquisitionはデーモンに届いていない。

静かなtrapのよくある理由は二つ。パケットがポリシーに到達する前にsource-NATされ、local_ts にもう一致しないか、構文や資格情報のエラーで接続が一度もロードされていないかだ。セレクターに触れる前に swanctl --load-all を再実行して出力を読む。ロードに失敗した接続はポリシーをインストールしないので、トラフィックが発火させるものは何もない。

方向も重要だ。送信トラフィック用にインストールされたtrapは受信パケットでは開始しない。遠隔側がトンネルを上げるべきなら、遠隔側に独自のtrapが必要か、こちら側に start.

最初のパケットを待つことが常に正しい取引とは限らない

対話的なセッションはセットアップのコストを感じる。最初のリクエストはIKE交換とCHILDネゴシエーションの費用を払い、期限の短いクライアントはSAが存在する前に諦めることがある。先制的な start はその最初のパケットの遅延を取り除く。ただし、来ないかもしれないトラフィックのためにトンネルを上げたままにする。

三つの事実が選択を決める。経路がどれくらい頻繁に使われるか、最初のリクエストに厳しい期限があるか、起動時にピアへ到達できるか。たまのバッチトラフィックと、起動時にオフラインかもしれないピアは、どちらも trap を支持する。遅延に敏感なクライアントと常に到達可能なピアは start を支持する。両側が開始できるなら、二重のネゴシエーションを避けるためにどちらがトリガーを持つか合意すること。

インストール済みのポリシーも漏えいを防ぐ保証ではない。要件がfail-closedなら、ファイアウォールがSAのないトラフィックを落とす必要があり、そのルールはchild定義の外にある。

次の議論を終わらせる三行を記録する

セレクター、起動時のアクション、そしてSAなしでポリシーが存在することを示すコマンド出力を書き留める。その三行が、次に誰かがトンネルをダウンと報告したときに「オンデマンドで待機中」と「ロードされていない」を分ける。記録には一分かかる。それがなければ同じ調査がゼロから始まる。

本当にセレクター内にあるホストから試すこと。ルーター自身からのpingは別の経路を通ることが多く、背後のサブネットを保護するポリシーについて何も証明しない。