Windows と strongSwan の暗号：正しいレイヤーを合わせる

両端が AES-128 と言っているのに、トンネルは依然として構築を拒否します。CBC と GCM は、たまたま同じ鍵長を共有している別個の変換であり、一方を提示するクライアントは、もう一方しか受け付けないゲートウェイを満たしません。AES という語は一族を表しており、合意を表しているわけではありません。

第二の軸もあり、混乱を招くエラーを生むのはこちらです。

二つのレイヤー、二つの独立したリスト

IKE はネゴシエーション自体を保護し、子アソシエーションは実際に気にするトラフィックを保護します。Windows は前者を暗号化方式と整合性方式として、後者を暗号変換と認証変換の定数として公開します。これらのフィールドは互いの別名ではなく、一方で有効な値が他方では無意味または誤りである場合があります。この分割を念頭に置いてプロファイルを読めば、混乱の大半は解消します。

実務上の帰結は、まったく問題のない鍵交換ポリシーと、相手が受け付けないデータチャネルポリシーを同時に持つことがあるということです。一方のリストはネゴシエーションを行い、もう一方はパケットを保護します。構成ダイアログでどれほど似て見えても、前者の値を変えても後者には影響しません。

ゲートウェイと比較する前に、両方のリストを書き出してください。記憶から比較すると、一方のフィールドは二度編集され、もう一方は決して編集されません。プロファイルの横でゲートウェイのコンソールを開いたままにします。

提案の横でエラーを読む

失敗した段階が、どちらのリストを調べるべきかを教えてくれます。 最初の鍵交換中の拒否は IKE 提案の問題です、そしてそれは子アソシエーションが存在する前に起こります。保護トラフィックのアソシエーションをネゴシエーションしている最中の失敗は ESP 提案の問題であり、鍵交換はすでに成功しています。クライアントからの一般的なポリシー一致メッセージはどちらの段階も示さないため、ゲートウェイ自身の見解が有用です。

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

受信した提案、構成された提案、選択された提案を比較する その一度の試行について。ここでは三つの異なるリストが重要であり、実際に使われたものを示すのは最後の一つだけです。要約するのではなく、チケットにそのまま引用してください。

CBC と GCM を別々の選択肢として保つ

どちらの一族も受け付けることを意図的に許可されたゲートウェイには、一つではなく二つの提案が必要です。strongSwan ではカンマが選択肢を区切り、ハイフンが単一スイートの構成要素を結びます。両方の一族をハイフンで組み合わせると、二つの受け入れ可能な提案ではなく、一つの不可能な提案になります。

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

最初の選択肢は認証付き暗号化を備え、それでも疑似乱数関数を明示します。整合性が暗号から得られる場合でも鍵導出には一つ必要だからです。二番目の選択肢は、別個の整合性アルゴリズムを用いた従来の暗号化です。どちらも、ロードされた暗号実装が何をサポートするかに左右されます。

ESP 提案は名前を変えた IKE 提案ではない

暗号トークンは両方のリストで同じに見えますが、それ以外はほとんど引き継がれません。ESP 提案には鍵交換の疑似乱数関数がなく、その整合性と前方秘匿性の要件は、IKE 行からコピーするのではなく、相手側の Windows ポリシーに対して論じられます。一方のリストをもう一方へ機械的に翻訳すると、検証は通るが決してネゴシエーションしないものができあがります。

方向を一つ選び、それに留まってください。ゲートウェイが GCM のみのポリシーを保ち、クライアントが完全な互換ポリシーを展開するか、ゲートウェイが両方の一族を受け付け、クライアントが既存のスイートを保つかのどちらかです。セキュリティポリシーが禁じるフォールバックを有効にすることは、どれほど速くエラーが消えても修正にはなりません。

両方のスイートを確認し、次に鍵の再生成を確認する

選択された鍵交換スイートと選択されたトラフィックスイートを別々に確認してください。異なるリストに由来し、独立して成功しうるからです。次に鍵の再生成を起こさせ、それも確認します。機能する最初のハンドシェイクと失敗する鍵の再生成は、部分的にしか受け入れられない提案セットを表します。

その証拠を変更と一緒に保管してください。繰り返す切断には、誰かがタイマーやプラットフォームの不具合を責める前に、独自の失敗交換の記録が必要です。