ネイティブ Windows IKEv2 に PSK 欄がまったくない理由

ゲートウェイの文書には事前共有キーをクライアントに入れると書かれていますが、Windows のプロファイルにはその欄がありません。この欠落は、パスワード欄にキーを打ち込んで回避する類の不具合ではありません。プロトコルができることと、特定の実装が提供するものとの違いです。

プロトコルの能力はクライアントの対応ではない

IKEv2 の仕様には共有キー認証が含まれるため、ゲートウェイをそれ向けに構成することは正当です。一方、ネイティブの Windows リモート アクセス プロファイルは証明書と EAP の仕組みを記述しており、プロトコルの能力がクライアントに一度もなかった欄、パラメーター、レジストリ値を作り出すわけではありません。

人はたいてい VPN 接続を追加するための PowerShell リファレンス にたどり着き、そこには L2TP の方式向けに L2tpPsk が示されています。このパラメーターは L2TP に属するもので、一般的な IKEv2 の秘密ではありません。アルゴリズム選択の設定は保護パラメーターを選ぶもので、三つ目の無関係な話です。Windows Server のルーティング役割も同じオブジェクトではありません。サーバー インターフェイスにはデスクトップ クライアント プロファイルにない構成制御があり得ますし、サーバー設定をワークステーション プロファイルにコピーしてもその能力は再現されません。

証明書、EAP、L2TP のどれかを選ぶ

ゲートウェイの運用者が証明書認証を受け入れるなら、それがたいてい最もきれいな行き先であり、クライアントが証明書を提示し、ゲートウェイが信頼された発行者に対して検証し、誰かがコピーできる共有の秘密がプロファイルに残りません。登録、信頼の連鎖、証明書を認可の判断に対応づけるゲートウェイ構成が必要です。

ユーザー資格情報を使う EAP はこのクライアントで対応しているもう一つの経路で、判断を ID プロバイダーへ移します。EAP 方式、サーバー証明書、その証明書に対するクライアントの信頼がすべて揃わなければならないため、独自の依存関係も持ち込みます。なじみのある欄を得るためだけに L2TP/IPsec に切り替えると、プロトコル スタックが変わります。文書化された理由のある対応策として選ぶなら許容できますが、キーを打ち込む欄を探していたせいで起きたのなら悪い結果です。

ゲートウェイが何を受け入れるか確認する

運用者には、製品が一般に対応している方式ではなく、リモート アクセス サービスが今日提供している認証方式を尋ねてください。PSK 専用で構成された IKEv2 サービスは、クライアントが証明書を好むという理由では受け入れません。

Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfter

プロファイルの認証方式と証明書ストアを合わせて読んでください。使える証明書が後ろにない EAP 設定のプロファイルは、サーバーの問題のように見える形で失敗します。

答えが PSK しかないというものであれば、正直な選択肢はそれを支える承認済みクライアントか、ゲートウェイの認証設計の変更です。どちらも場当たり的な回避策ではなく、そう装うと、構成した本人しか再現できない接続が生まれます。

決定と秘密を記録する

選んだ方式、信頼の基点、それに対応する ID、変更を承認した人を書き留めてください。その記録こそインシデントレビューに必要なものであり、次の技術者が同じ行き止まりを再発見するのを防ぐものでもあります。

メモでは、設定画面がどれもパスワードと呼んでいても、アカウントのパスワード、秘密鍵のパスフレーズ、ゲートウェイの事前共有キーを三つの別物として分けておいてください。混同するとキーがチケットに残ります。出来上がったプロファイルは、新しい接続と非公開リソースへのアプリケーション要求一回で試してください。到達できるサービスがないのにトンネルだけ成功したのは部分的な結果であり、リソースも動くまでは完成と呼ぶべきではありません。