IKE の MAC 不一致は共有鍵の検証が失敗したことを意味する

Cloud VPN のログに共有鍵の試行とそれに続く MAC mismatched が表示されると、まずアドレスの問題を探しがちです。この分岐では MAC はメッセージ認証コードであり、ネゴシエートされた鍵による交換全体に対して計算された値です。ピアは自分の計算と受信した値を比較し、それらは一致しませんでした。ネットワークカードは関与せず、インターフェース設定もその比較を変えません。

実際にこれを生む条件は二つあります。両端のシークレットが同じ値でないか、シークレットを選択するための ID が対応していないかで、どちらかを判断するには単一のトンネルではなくペアを読みます。

この段階が証明すること

検証は、両側が初期パラメーターを交換して自身を識別した後に実行されます。ローカルとリモートの ID に対する候補の共有鍵を選択して受信した認証データを検証しようとし、どれも検証できない場合に診断が出力されます。これは認証についての強い主張ですが、原因については弱い主張であり、どちらの側が誤っているかを示しません。

以前の成功はこの検証には引き継がれません。完了した IKE_SA_INIT や、期待値を返した NAT 検出ペイロードは、ピアが通信できることを証明します。シークレットを共有しているかどうかは何も証明しません。

二つの設定ミス、一つのメッセージ

一つ目は実際のシークレットの不一致で、通常はプロビジョニングの事故、つまり生成された値を一方のコンソールに入力してもう一方で打ち直した、片側に末尾の文字が残った、貼り付けとともに引用符が入った、といったものです。二つ目は ID の不一致で、シークレットは正しいもののピアが提示する ID が別のエントリを選択するため、正しいシークレットが試されません。どちらも同じ行を出すので、推測には半日かかります。

シークレットに触れる前に、トンネル、ピアのエンドポイント、時間枠、リモート設定を一致させてペアを比較してください。冗長なトンネルが二つあれば異なるシークレットを持つことがあり、目の前の画面が失敗したものとは限りません。

NAT 検出は別の段階

NAT 検出はパケットがどのように書き換えられるかを問うもので、ピアが誰かではありません。NAT 背後のカスタマーゲートウェイは設定された ID がピアの期待するものであれば正しく認証され、NAT の問題は認証比較の失敗ではなくプロポーザルやポートの不一致として現れます。

あるベンダーリリースについての古い記述を現在の展開に持ち込まないでください。お使いのリリースで NAT トラバーサルが何を要求するかはそのリリース自身のドキュメントに属し、MAC mismatch という語句はその賛否の証拠にはなりません。

画面ではなくペアから判断する

シークレットを伏せた状態で両方の設定を並べて読み、三つの質問をします。各側の ID は、相手が期待するものと文字単位で完全に一致していますか。両端は同じ IKE バージョンと同じ認証方式を使っていますか。失敗しているトンネルは、読んでいる設定に対応していますか。いずれかに「いいえ」があれば、シークレットに触れずに修理方法が決まります。

三つすべてがきれいなら、その周りを編集するのではなく、承認されたワークフローでシークレットを交換してください。

ピアが認証した後

認証が成功すると、次の障害面は子セキュリティアソシエーションのプロポーザルとトラフィックセレクターです。すでに受け入れられたシークレットをローテーションしても子の障害は直らず、停止が長引きます。子の状態を読み、次に両側のセレクターと保護範囲を読み、Cloud VPN のトラブルシューティングのガイダンスを、実際に失敗した段階に合わせてください。

両端の新しいログを関連付ける同じペアと同じ時間枠について行います。片側だけではもう片側の入力なしに判断を下すことになり、それがそもそもこのメッセージを生んだ曖昧さです。

結論してはいけないこと

このメッセージを MAC アドレスを変更する要求として読まず、助けを求めるときに共有シークレットを公開しないでください。鍵を含む抜粋はログを残すのではなく鍵を削除する必要があり、ルーティングの障害とも決めつけないでください。互いに到達できないピアは認証比較をまったく生成しないからであり、ある製品ファミリーの文書化された制限をすべての IPsec 実装に一般化しないでください。

失敗したペア、変更前後のトンネル状態、二つの条件のどちらを変更したかを記録してください。その記録が次の発生を五分間の確認に変えます。