Por qué el Windows IKEv2 nativo no tiene ningún campo de PSK
El protocolo admite claves compartidas, mientras que el cliente integrado expone certificados y EAP. Elija un método que implementen ambos extremos, no una solución local.
La documentación de la puerta de enlace dice que la clave precompartida se introduce en el cliente, pero el perfil de Windows no tiene ningún campo para ella. Esa laguna no es un error que se evite escribiendo la clave en el cuadro de contraseña. Es la diferencia entre lo que puede hacer un protocolo y lo que ofrece una implementación concreta.
La capacidad del protocolo no es compatibilidad del cliente
La especificación de IKEv2 incluye la autenticación con clave compartida, así que una puerta de enlace puede configurarse legítimamente para ello. El perfil nativo de acceso remoto de Windows documenta en cambio disposiciones con certificados y EAP, y la capacidad del protocolo no crea ningún campo, parámetro ni valor de registro que el cliente nunca haya tenido.
Normalmente la gente acaba en referencia de PowerShell para añadir una conexión VPN, donde se muestra L2tpPsk para la disposición L2TP. Ese parámetro pertenece a L2TP y no es un secreto general de IKEv2. Los ajustes de selección de algoritmos eligen parámetros de protección, que es una tercera cosa sin relación. El rol de enrutamiento de Windows Server tampoco es el mismo objeto. Una interfaz de servidor puede tener controles de configuración que un perfil de cliente de escritorio no tiene, y copiar un ajuste de servidor a un perfil de estación de trabajo no reproduce la capacidad.
Elija entre certificado, EAP o L2TP
Si el operador de la puerta de enlace acepta la autenticación por certificado, suele ser el destino más limpio: el cliente presenta un certificado, la puerta de enlace lo valida contra un emisor de confianza y no queda ningún secreto compartido en un perfil para que alguien lo copie. Requiere inscripción, una cadena de confianza y una configuración de la puerta de enlace que asocie el certificado a una decisión de autorización.
EAP con una credencial de usuario es la otra vía admitida en este cliente, y traslada la decisión a un proveedor de identidad. También introduce sus propias dependencias, porque el método EAP, el certificado del servidor y la confianza del cliente en ese certificado deben encajar. Cambiar a L2TP/IPsec solo para obtener un campo familiar cambia la pila de protocolos. Eso es aceptable cuando es una opción admitida con un motivo documentado, y es un mal resultado cuando ocurre porque alguien buscaba una casilla donde escribir una clave.
Compruebe qué aceptará la puerta de enlace
Pregunte al operador qué métodos de autenticación ofrece hoy el servicio de acceso remoto, no cuáles admite el producto en general. Un servicio configurado para IKEv2 solo con PSK no aceptará un certificado porque el cliente prefiera uno.
Get-VpnConnection -Name "Corp IKEv2" | Format-List AuthenticationMethod, TunnelType, EncryptionLevel, ServerValidation
Get-ChildItem Cert:\CurrentUser\My | Select-Object Subject, NotAfterLea el método de autenticación del perfil y el almacén de certificados a la vez. Un perfil configurado con EAP sin ningún certificado utilizable detrás falla de una forma que parece un problema del servidor.
Si la respuesta es que solo hay PSK, las opciones honestas son un cliente aprobado que lo admita o un cambio en el diseño de autenticación de la puerta de enlace. Ninguna es una solución local, y fingir lo contrario produce una conexión que solo puede reproducir quien la configuró.
Registre la decisión y los secretos
Anote el método elegido, el ancla de confianza, la identidad que le corresponde y la persona que aprobó el cambio. Ese registro es lo que necesita una revisión de incidentes y también lo que impide que el siguiente ingeniero vuelva a recorrer el mismo callejón sin salida.
Mantenga los secretos separados en sus notas: una contraseña de cuenta, una frase de paso de clave privada y una clave precompartida de puerta de enlace son tres cosas distintas, incluso cuando una pantalla de ajustes las llama todas contraseña. Confundirlas es como una clave acaba en un ticket. Pruebe el perfil resultante con una conexión nueva y una petición de aplicación a un recurso privado. Un túnel correcto sin ningún servicio accesible es un resultado parcial, y el perfil no debe describirse como terminado hasta que el recurso también funcione.