複数のクライアントに合う IKEv2 設定を計画する

一つのデスクトップで動くプロファイルは、一つのクライアントに対する成功したテストです。それはクロスプラットフォーム展開ではなく、そう扱うとよくあるサポートの型、つまり Windows は接続し、スマートフォンは ID 検査で失敗し、管理されたノート PC はスリープから復帰するたびに再接続する、という型が生まれます。違いは現実のものでほとんど予測できるため、計画はスクリーンショットではなくマトリクスであるべきです。

まず ID 契約を決める

アルゴリズムを論じる前に、サーバーの ID、証明書への信頼、クライアント認証の方式を文書化します。この三つがクライアントがそもそも認証できるかを決め、プラットフォームごとに表現が異なる部分でもあります。

各プラットフォームが期待する識別子をどう名付け、サブジェクト代替名をどう扱うかを確認します。一つのクライアントでサーバー名を受け入れるプロファイルが、別のクライアントでは同じ証明書を拒否することがあり、その理由は識別子のフィールドが別の値から埋められることです。

次に暗号学的な共通部分を選ぶ

対応する各クライアントが提示できる提案を比較し、ゲートウェイも許可する現代的な共通部分を選びます。古い端末を一つつなぐために過大な旧式リストを有効にしないでください。そのリストは、後に続く全員にとってゲートウェイの既定値になるからです。旧式の選択肢がなぜ残っているかを書き留め、それが必要な端末を誰も名指しできないなら、それは要件ではありません。

計画では IKE と CHILD の設定を分けておきます。 IKE 交換に受け入れられる提案が、保護されたトラフィックにも自動的に受け入れられるわけではなく、両者は別々にネゴシエートされます。ある層で提案を受け入れるゲートウェイが、別の層では拒否することがあり、ログには最初の層が成功したように見える失敗が残ります。

検証済みの手順で資格情報を配布し、ユーザーパスワード、共有シークレット、クライアントの秘密鍵をそれぞれのフィールドに保ちます。似た名前のボックスでの試行錯誤が、動くテストを再現できないテストに変える道です。

定常状態ではなくライフサイクルを試す

クライアントごとに、初回認証、想定するアプリケーション、DNS 解決、アドレスファミリーの網羅を試します。その後、後からしか現れない部分、つまり更新、スリープ、通常のネットワーク変更を練習します。

MOBIKE の対応と再認証の挙動は、たった今測った定常状態の結果と異なることがあります。その時点のイベントとアソシエーションの状態を記録し、インターフェースが最終的に接続して見えるかどうかだけでは足りません。

VPN が使えない間に直接トラフィックが何をしてよいかを定義します。これはクライアントが再接続するかどうかとは別のポリシー判断であり、ほとんどの配備は前者を無視して後者に答えます。答えをプロファイル名の隣の配備メモに書きます。障害の最中に誰かがそれを必要とし、再構成する時間はないからです。

一つのプラットフォームが同意しないときはサーバー ID の検査を使う

プロファイルがあるプラットフォームで動き、別のプラットフォームがその名前を拒否するときは、クライアントが実際に送った識別子と証明書が持つ識別子を比べます。この比較は、暗号リストを変えるより速く、ほとんどの事例を解決します。

検証済みのマトリクスを、設定の出所と更新手順とともに保管します。古いクライアントのサポートが終わったら、次回の監査に見つけられるようゲートウェイに弱い互換設定を隠したままにするのではなく、その例外を意図的に削除します。strongSwan の IKEv2 ドキュメントは、交換がどのように設定されるかの有用な参考資料です。