Mac の VPN 証明書:ゲートウェイが見るのはどのアカウントか

プロファイルにはあなたの名前が表示され、証明書の表示ラベルは別のことを言い、ゲートウェイのログには三つ目の識別子が記録されます。どれも嘘をついてはいませんが、それこそが問題です。三つの異なるフィールドが、一つの問いに答えているかのように読まれているのです。接続は資格情報、IKEv2 識別子、アカウントを提示し、ゲートウェイはそのどれが何を許可するかを決めます。

一つの接続に三つの身元

表示されるプロファイル名は人間のためのラベルです。接続を選ぶだけで、それ以上ではありません。証明書は資格情報であり、何かを証明できるかどうかは、クライアントが対応する秘密鍵を持っているかどうかで決まります。アカウント欄は主体についての主張であり、サーバーはそれを別のローカルな身元にマッピングしてかまいません。

認証が失敗したら、三つのうちどれに関するエラーなのかを尋ねてください。拒否された資格情報、未知の識別子、無効化されたアカウントはそれぞれ異なるメッセージを出します。それらを一つの「証明書の問題」として扱うと、間違ったコンソールへ送られます。

ネイティブのフィールドを役割ごとに読む

管理されたネイティブの IKEv2 構成では、Apple のペイロード参照が値を分離し、認証方法がどの組み合わせを必要とするかを決めます:

証明書と EAP ログインは、同じ接続の中で異なる役割を持てます。一方がそうだからという理由だけで、すべてのフィールドに同じ文字列を強制しないでください。また、一方を変えれば他方が上書きされるとも考えないでください。サードパーティの VPN アプリはまったく別のモデルを示すことがありますから、ネイティブのフィールド名を持ち込むのではなく、そのアプリの文書化された身元の選択を使ってください。

サーバー証明書はクライアントの身元ではない

ゲートウェイを検証する証明書は信頼のアンカーです。期待したサーバーに到達したことを証明します。クライアントの身元は別のオブジェクトです。接続する側が名乗るとおりの相手であることを証明する秘密鍵へのアクセスを含みます。表示アカウントを改名しても、一方を他方に変換することはできません。

ここで善意の修正が誤ります。ゲートウェイの CA 証明書をクライアントのストアに取り込んでも、クライアント認証には何の効果もありません。その項目にユーザー名を付けても、ユーザーの身元にはなりません。二つのオブジェクトはプロファイルの別の場所にあり、別の問いに答えます。

主体からゲートウェイのマッピングまでを追う

資格情報が何のために発行されたのかを確認してください。このユーザーか、このデバイスか、共有の役割か。Mac のログインアカウントが自動的にその主体になるわけではなく、別のマシンからコピーした証明書は、発行先のマシンの身元を保持します。

次にラベルではなく実際の資格情報を比較します。発行者、シリアル番号、フィンガープリントがあれば、あなたと管理者は同じオブジェクトについて話していると確認できます。表示名は編集可能で重複も多く、インシデントの最中には最悪の識別子になります。

最後の手順はゲートウェイ側です。その所有者に、一つの接続を提示された識別子と、それらを消費したアカウントマッピング規則に対応づけてもらってください。クライアント側のラベルではサーバーが何を決めたかは分かりません。証明書を無効化されたアカウントにマッピングする規則は、クライアント側のフィールドがすべて正しく見えていても失敗します。

不整合を所有する層を修復する

プロファイルが誤った資格情報を指しているなら、その参照または選択を修正します。資格情報が別の主体のものであるなら、ラベルを編集するのではなく発行者の再登録を経由します。ゲートウェイが有効な資格情報を誤ったアカウントに結びつけているなら、ポリシーの所有者がマッピングを直す必要があります。これらは三つの異なる変更であり、承認者も三人異なります。

更新にも同じ注意が必要です。証明書の差し替え、表示ラベルの改名、人物をアカウントシステム間で移すことは、必ずしも同じ形でマッピングに影響するわけではありません。三つのうちどれを変えたかを記録してください。次の障害はクライアント側からは同一に見え、ゲートウェイのログでは異なって見えるからです。

サポートが必要とする最小限の公開識別子だけを共有してください。秘密鍵や完全な身元バンドルは、診断がどれほど楽になっても、そのやり取りに含めるものではありません。