ipsec.conf か swanctl.conf か。strongSwan のフロントエンドを一つ選ぶ

古いガイドの動作する IKEv1 プロファイルを Ubuntu 24.04 に持ってきても、デーモンがファイルを一度も読んでいないため最初の試行は失敗する。よくある対応は、プロファイルをもう一度編集することだ。本当の問いは、どの strongSwan フロントエンドが導入されていて、稼働中のサービスがどちらを使っているかである。それが分かるまで、編集は存在しないかもしれないローダーに向けられている。

二つのファイル、二つのローダー、一つのデーモン

旧来の starter 構成は ipsec.conf を読み、古い管理連携を通じて接続を charon に渡す。その運用上の入口は ipsec コマンドである。

swanctl 構成は VICI 経由で定義を読み込み、swanctl.conf を読み、swanctl コマンドで動く。systemd にネイティブな charon デーモンがこの方式に統合されている。

両方を同じマシンに導入でき、そこから混乱が始まる。/etc 配下のファイルは、誰かが書いたことしか示さず、稼働中のプロセスが読んだことは示さない。どちらが動くかを見るためにすべての選択肢を導入すると、管理経路が二つあり所有者が不明なホストができる。一方の構成を選び、もう一方を削除するか無効にすること。

導入済みのパッケージと unit を読む

まず読み取り専用で始める。Ubuntu 24.04 のパッケージ名は分かれている：strongswan-starter、strongswan-swanctl、charon-systemd である。パッケージが無いことは有用な情報であり、導入せよという指示ではない。

パッケージと unit を一度に洗い出す：

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

次に有効な unit とその起動コマンドを調べる。unit 名からどのデーモンが設定を持つかが分かり、コマンドラインからどのファイルを読むよう指示されたかが確認できる。有効だが停止中の unit は、いま動作中のものとは別の事情を語る。

有効な unit が strongswan-starter なら、重要なのは ipsec.conf である。swanctl を伴う charon-systemd なら、ipsec.conf は単なる飾りである。

対応する制御経路を使う

フロントエンドごとに接続と関連の見え方が異なる。swanctl --list-conns は読み込まれた定義を、swanctl --list-sas は有効な関連を示す。旧来の経路は ipsec statusall を使う。

両者を混ぜると誤解を招くエラーになる。VICI ソケットの不在や制御要求の拒否は管理経路の問題であり、相手が認証を拒否した証拠ではない。

稼働中のデーモンに属する見え方を読む、そして結果を解釈する。その見え方に接続が無いなら、問題は読み込みであり、交渉ではない。

形式は IKE バージョンではない

旧来のプロファイルは keyexchange=ikev1 で IKEv1 を選ぶ。swanctl の接続はバージョン設定を使い、1 が IKEv1 を選ぶ。これは同じ考えの二つの語彙であり、変換ではない。

相手のアドレス、ローカルとリモートの識別子、資格情報の取得元、提案、child セレクタは、いずれも意図して対応づける必要がある。left/right ブロックを swanctl の構文に貼り付けても、そのどれも行われない。

プロトコルのバージョンだけを変えるのが最も多い半端な移行である。それは読み込まれた後に、バージョンとは無関係の理由で認証に失敗するファイルを生む。IKEv1 自体が RFC 9395 で非推奨であり、今もそれを要求する既存の相手には、文書化された互換性の制約と移行経路を与えるべきで、新しい既定値ではない。

プロファイルに触る前にローダーを確認する

まずローダーの確認を実行し、次に目的の接続を読み込み、次に交渉を評価し、最後に保護された通信経路を評価する。各段階で失敗の現れ方が異なる。

二つの制御経路は読み込みの問いに直接答える：

swanctl --list-conns
ipsec statusall

そのうち片方だけが自分のホストに属する。両方を実行して出力を比べるのは、どちらが嘘をついているかを見つける方法であり、診断手法ではない。

パッケージの所有、設定の読み込み、プロトコルの互換性を三つの別の問いとして扱う。一方のフロントエンドに有効なファイルは、別のデーモンが動いている間、何度も編集され続けることになる。