接続に成功しただけでは、両端が受け入れ可能な値の組み合わせを見つけたことしか分かりません。管理された Mac の IKEv2 プロファイルにはセキュリティアソシエーションの辞書が二つ含まれ、ゲートウェイは独自の提案リストを持ち、接続は両側が許容する共通部分で成立します。以下の確認を順番に行い、別の暗号を追加して効果を見るのではなく、両端が食い違う箇所で止めてください。各手順はプロファイルの異なる層を除外します。

値を編集する前に両方の辞書を確認する

VPN ペイロードの IKEv2 設定では、IKESecurityAssociationParameters が IKE アソシエーションを、ChildSecurityAssociationParameters が Child SA を記述します。Apple のスキーマは、二つ目の辞書がない場合に IKE パラメータが Child SA にも適用されると述べています。この継承は便利であり、まさにそうやってプロファイルには誰も意識的に選んでいない値が残ります。

<key>IKESecurityAssociationParameters</key>
<dict>
  <key>EncryptionAlgorithm</key><string>AES-256</string>
  <key>IntegrityAlgorithm</key><string>SHA-256</string>
  <key>DiffieHellmanGroup</key><integer>14</integer>
  <key>LifeTimeInMinutes</key><integer>1440</integer>
</dict>

値が一致していても、両方の行を配備記録に書いてください。そうすればレビュー担当者は、Child SA が偶然継承されたのではなく検討されたことを確認でき、後で一方の行を変更しても他方が黙って変わることはありません。

文字列をコピーする前に各キーの意味を確認する

四つのキーは他の製品の提案文字列と互換ではありません。アルゴリズム名は実装固有なので、strongSwan の提案を Apple のフィールドに貼り付けるのではなく、各側の文書化された構文で選択したスイートを翻訳してください。

KeyHoldsCommon mistake
EncryptionAlgorithmCipher for that associationAssuming an AEAD name also sets integrity
IntegrityAlgorithmIntegrity for the chosen suiteLeaving it set for an AEAD suite that does not use one
DiffieHellmanGroupNumeric group identifierReading the number as key size in bits
LifeTimeInMinutesAssociation lifetimeSetting it shorter than the gateway's renewal margin

「最も大きいグループ番号を使う」は選択方法ではありません。グループ識別子は異なる構成を指し、番号が大きいからといって同じものの強い版というわけではありません。スイートは全体として有効か無効かであるため、ゲートウェイの所有者に組み合わせ全体を承認してもらってください。承認された暗号と承認されていないグループの組み合わせは承認されていない提案であり、失敗するか、どちらも文書化していない何かに黙ってフォールバックします。

古いアルゴリズムを廃止するバージョン制限を確認する

Apple のペイロードスキーマは、DES、3DES、SHA1-96、SHA1-160、および Diffie-Hellman グループ 1、2、5 を 26 より前の macOS バージョンに限定しています。古い配備から引き継いだプロファイルには、そうした値がまだ含まれ、古いゲートウェイにまだ接続できる場合があり、まさにそうした場合に動作する構成が廃止日を隠します。

プロファイルを構築する前に、サポート対象の Mac バージョンとゲートウェイが維持する提案ポリシーを入手してください。次に共通部分を選び、残りの選択肢を除外した理由を記録します。「ゲートウェイは旧クライアント向けにグループ 2 をまだ提供している」という注記は、履歴のない暗号リストより価値があります。その注記がなければ、次のレビュー担当者は意図的な例外と見落としを区別できません。

認証は独立した行で確認する

提案について合意しても、誤ったサーバー ID は直りません。ゲートウェイの ID、証明書への信頼、ユーザーまたはデバイスの資格情報は別々の判断であり、アルゴリズムが完全に一致していてもそれぞれが失敗し得ます。証明書の署名アルゴリズムを変更することは、IKE 暗号化アルゴリズムを選択することと同じ行為ではありませんが、どちらも同じレビューに現れます。

想定されるサーバー ID を、記録内で提案の隣に置いてください。証明書の変更後に接続が失敗したとき、その組が次に担当する人に、ネゴシエーションと信頼の判断のどちらが先に動いたかを伝えます。

一つのリビジョンを配備し、何がネゴシエートされたかを検査する

組織がサポートする配布ワークフローを使用し、プロファイル識別子、リビジョン、対象の Mac バージョン、対応するゲートウェイポリシーを記録します。接続できないデバイスには文書化された復旧手順を提供し、所有権を誰も確認できない同名の 二つ目のプロファイルを作らないでください。

受け入れ時に、承認された診断ツールを使ってインストール済みの構成とネゴシエートされた IKE および Child アソシエーションを検査し、その後で制御された更新を強制してください。最初の接続は初期ネゴシエーションが機能したことしか示さず、寿命の不一致は通常、配備が承認されてずっと後の最初の鍵交換で現れます。

承認されたスイートをリビジョン記録と一緒に保管してください。そうすれば次回の macOS 更新やゲートウェイ変更のときに、今日たまたま接続できるだけのプロファイルではなく、比較できる基準があります。

関連記事