iOS が strongSwan トンネルを拒否したら: IKE 提案を比較する

証明書にもアドレスにも、昨年 strongSwan に接続できていた iPhone が今年失敗する理由は書かれていない。アドレス、事前共有鍵、クライアント ID のどれも変わっていなくてよい。動いたのは、端末内蔵クライアントが交渉に応じる変換の一覧であり、その一覧がサーバ側と重ならなくなった時点で、誰かの ID が調べられる前に交換は終わる。

決め手になるログ行

その接続のログを上げ、結果を決める二つの項目 —— 端末が提示したものとサーバが選んだもの —— を探す。選択された提案なしにログが終わり、一致するものがなかったと記録されていれば、認証は一度も試されていない。新しい証明書も新しいパスワードも、どちらも後の段階で消費されるのだから、その地点では何も変えない。どちらも、ID が調べられる前に決まった結果には影響できない。

何かを編集する前に、二つの失敗の型を切り分ける。変換を編集しても拒否された資格情報は救えないし、資格情報を直しても拒否された変換は救えない。選択された提案を名指しするログ項目が、どちらの型かを教えてくれる。その項目がなければ、推測していることになる。

選択された行は、親しみやすいラベルではなく変換セットで提案を名指しする。暗号化・整合性・グループの各フィールドを比較するその行の値と端末が送った一覧を突き合わせ、どれか一つのフィールドの食い違いでも失うと心得る。

端末側で何が変わったか

ある iOS のリリースが、クライアントの使えるアルゴリズムを削った。弱い整合性ハッシュ、小さい Diffie-Hellman グループ、旧来の選択肢を先に並べた提案は受け入れられなくなった。

ここでは長い一覧ほど安全ではない。選択は端末の受け入れ集合と独自の優先順に従うので、広いカタログを広告するサーバでも、現代的な項目が選ばれなければ交渉に負ける。現代的な項目を先頭にした短い一覧を選ぶ。旧来の選択肢から始まる長い一覧は、避けたい失敗をちょうど招き寄せる。受け入れ集合はクライアントの更新のたびに動く外部の制約なので、昨日動いた設定は昨日についての証拠にすぎない。

それでも交渉できる一組

現在の端末なら現代的な組み合わせ一つで足り、交渉できる一組は次のとおりだ。

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

ike 行は鍵交換が進む間に使う暗号化・整合性・Diffie-Hellman グループを持つ。esp 行は、グループが適用前に決まっているため、データ経路だけを扱う。接続を再読み込みするかデーモンを再起動し、そのうえで端末を再接続する。そのグループ値は、運用するすべてのクライアントがまだ受け入れる場合にだけ残し、古いピア一台がもっと必要だからといって全員向けに提案を広げない。

直す場所は三つ、ふつう一つは閉じている

• すべてのピアに現代的な提案を一つ。 クライアントがすべて現在の端末とデスクトップなら正しい。旧い変換を交渉でかわすのではなく削除する。
• Apple クライアント用に二つ目の接続定義を置く。 古いピア一台を生かしたまま、端末に受け入れる提案を与える。接続ブロックがもう一つ増え、例外が見えるようになる。
• クライアントを変える。 手を出せることはまれで、管理システムやアプリがプロファイルを配る場合は触れる提案エディタもなく、内蔵クライアントもそれを公開していない。

管理外の機器を更新できないなら二つ目を選ぶ。古いピアを退役させ、方針を一つにまとめたいなら一つ目を選ぶ。

どちらにせよ選択は設定に見える形で残る。そこが要点で、古い変換へ落とす黙ったフォールバックは、レビューがそれを表に出すことが決してないぶん、明示的なブロックより悪い。

証明してから記録する

再接続してサーバで三つの事実を別々に確かめる。提案が選ばれたこと、接続が確立として見えること、クライアントがアドレスを受け取ったことだ。遠隔アドレスのない確立済みハンドシェイクはプールかトラフィックセレクタを指すので別の変更に属し、二つをまとめて扱うと解決済みの交渉が未解決に見える。

受け入れられた変換セット、いつ変えたか、どのクライアントのビルドで確認したかを書き残す。次の更新で要件はまた動きうるし、効いた値は新しい値の隣に真っ先に置いておきたいものだ。