iOS IKEv2 と strongSwan でプロポーザル未選択になったときのリスト修正

iPhone はトンネルを張り、ゲートウェイは何も返さず、端末には一般的な失敗だけが表示される。strongSwan のログはもっと具体的で、no proposal chosen と出る。このメッセージは、受け入れ可能な暗号スイートの 二つのリストが一度も重ならず、認証が始まる前に交換が終わったことを意味する。突き合わせの問題であり、修正はリストを交差させることだ。

ゲートウェイがポリシーを宣言する場所

strongSwan は設定ファイルにポリシーを書き、末尾の感嘆符がその読み方を決める。記号がある場合、リストは網羅的で、その項目だけが受け入れられ、それ以外は通らない。記号がない場合、同じ行は優先順位になり、デーモンは意図しないものを選ぶことがある。何かを翻訳する前に、同じクライアントに対して挙動が違うのだから、どちらの形式が配備されているかを確認する。正確な行を記号込みで記録し、それに照らしてテストする。

より広いリストを提示するクライアントでも、両側に一つでも共通の組み合わせがあれば、固定されたゲートウェイに接続できる。できないのは、固定された集合の外でのネゴシエーションだ。

だからこそ別の VPN アプリからコピーしたプロファイルが動いて、自分のものが動かないことがある：そのアプリは別のリストを積んでいたのだ。

名前は一致させるべきで、改善してはいけない

strongSwan の値を iOS に移すときに引っかかる翻訳が二つある。IKE プロポーザルで SHA1 と書かれた完全性アルゴリズムは切り詰めた形で運ばれ、iOS はそれを.SHA96と呼ぶ。modp1024 と書かれた Diffie-Hellman グループはグループ 2 で、iOS はそれを.group2と呼ぶ。SHA-256 やグループ 14 に置き換えても、古い組み合わせしか受け付けないゲートウェイとはネゴシエーションできない。クライアントは同じアルゴリズムを記述する必要があり、より強いものを書くのではない。

NEVPNProtocolIKEv2でこれらの値を明示的に設定する。既定値は置き換えるプロファイルより広いか狭いことがあり、違いはハンドシェイクが失敗したときにだけ表れる。

子プロポーザルはより遅く、より静かに失敗する

子のセキュリティアソシエーションも IKE と同様に設定する。IKE のパラメータだけが揃うと、トンネルは認証を通過したうえで通信を運ばなくなり、これは拒否よりもはるかに静かな失敗だ。子の暗号化、完全性、グループ、ライフタイムを同じ手順で設定する。クライアントのライフタイムは、より長く主張すると別の原因から同じ no proposal chosen になるのだから、ゲートウェイの値以下に保つ。そこの不一致はログ上の IKE の不一致とまったく同じに見える。

設定を見ている間に、プロファイルが証明書で認証するのか共有シークレットで認証するのかを確認する。プロポーザルの拒否と認証の拒否は別の行に出るので、間違った方を直すと丸一日を失う。変更のたびに新しい接続でテストするが、キャッシュされた状態がどのパラメータを動かしたかを隠すのだから、一度に一つの変数だけ動かす。

レガシースイートは必要な間だけ残す

SHA-1 を 1024 ビットのグループと固定するのは橋であり、目的地ではない。どちらも非推奨で、新しいクライアントはあっさり拒否することがあり、つまりこちらの変更なしに次の端末でプロファイルが失敗する。固定は一時的なものとして扱い、記録にもそう書く。

strongSwan が自分のものなら、現代的プロポーザルを追加し、レガシーの項目を古い端末のために残したまま両端を上へネゴシエーションさせる。デーモンの状態出力を読み、各接続が実際にどのスイートを使ったかを確認する。現代的な組み合わせが確認できたら、クライアント側の固定を外す。トンネルが張れただけでは、引退させたいスイートで張れることもあるのだから、証拠にならない。strongSwan の IKEv2 ドキュメントにはプロポーザルの構文と strict マーカーが書かれている。