Pourquoi le Windows IKEv2 natif n’a aucun champ PSK

La documentation de la passerelle indique que la clé prédéfinie se saisit dans le client, mais le profil Windows n’a aucun champ pour cela. Cette lacune n’est pas un défaut à contourner en tapant la clé dans le champ du mot de passe. C’est la différence entre ce qu’un protocole peut faire et ce qu’une implémentation particulière offre.

La capacité du protocole n’est pas la prise en charge par le client

La spécification IKEv2 inclut l’authentification par clé partagée, une passerelle peut donc légitimement être configurée pour cela. Le profil d’accès distant natif de Windows documente plutôt des dispositifs à certificats et EAP, et la capacité du protocole ne crée pas de champ, de paramètre ou de valeur de registre que le client n’a jamais eu.

Les gens aboutissent généralement sur référence PowerShell pour ajouter une connexion VPN, qui expose L2tpPsk pour le dispositif L2TP. Ce paramètre appartient à L2TP et n’est pas un secret IKEv2 général. Les réglages de sélection d’algorithme choisissent des paramètres de protection, ce qui est une troisième chose sans rapport. Le rôle de routage de Windows Server n’est pas le même objet non plus. Une interface serveur peut avoir des contrôles de configuration qu’un profil client de bureau n’a pas, et copier un réglage serveur dans un profil de poste de travail ne reproduit pas la capacité.

Choisir entre certificat, EAP ou L2TP

Si l’opérateur de la passerelle accepte l’authentification par certificat, c’est généralement la destination la plus propre : le client présente un certificat, la passerelle le valide auprès d’un émetteur de confiance et aucun secret partagé ne reste dans un profil pour que quelqu’un le copie. Cela exige une inscription, une chaîne de confiance et une configuration de passerelle qui associe le certificat à une décision d’autorisation.

EAP avec un identifiant utilisateur est l’autre voie prise en charge sur ce client, et elle déplace la décision vers un fournisseur d’identité. Elle introduit aussi ses propres dépendances, car la méthode EAP, le certificat du serveur et la confiance du client dans ce certificat doivent tous s’aligner. Passer à L2TP/IPsec uniquement pour obtenir un champ familier change la pile de protocoles. C’est acceptable quand il s’agit d’un choix pris en charge avec une raison documentée, et c’est un mauvais résultat quand cela arrive parce que quelqu’un cherchait une case où saisir une clé.

Vérifier ce que la passerelle acceptera

Demandez à l’opérateur quelles méthodes d’authentification le service d’accès distant propose aujourd’hui, et non lesquelles le produit prend en charge en général. Un service configuré pour IKEv2 en PSK uniquement n’acceptera pas un certificat parce que le client en préfère un.

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

Lisez la méthode d’authentification du profil et le magasin de certificats ensemble. Un profil réglé sur EAP sans certificat utilisable derrière échoue d’une manière qui ressemble à un problème de serveur.

Si la réponse est que seul PSK est disponible, les options honnêtes sont un client approuvé qui le prend en charge ou une modification de la conception d’authentification de la passerelle. Ni l’un ni l’autre n’est un contournement local, et prétendre le contraire produit une connexion que seule la personne qui l’a configurée peut reproduire.

Consigner la décision et les secrets

Notez la méthode retenue, l’ancre de confiance, l’identité qui y correspond et la personne qui a approuvé le changement. Cette trace est ce dont un bilan d’incident a besoin, et c’est aussi ce qui empêche l’ingénieur suivant de redécouvrir la même impasse.

Gardez les secrets séparés dans vos notes : un mot de passe de compte, une phrase secrète de clé privée et une clé prédéfinie de passerelle sont trois choses différentes, même lorsqu’un écran de réglages les nomme toutes mot de passe. Les confondre est la façon dont une clé finit dans un ticket. Testez le profil obtenu avec une connexion neuve et une requête applicative vers une ressource privée. Un tunnel réussi sans service joignable est un résultat partiel, et le profil ne doit pas être décrit comme terminé tant que la ressource ne fonctionne pas aussi.