Por que o Windows IKEv2 nativo non ten ningún campo de PSK

A documentación da pasarela di que a clave precompartida se introduce no cliente, pero o perfil de Windows non ten ningún campo para ela. Esa lagoa non é un erro que se evite escribindo a clave na caixa de contrasinal. É a diferenza entre o que pode facer un protocolo e o que ofrece unha implementación concreta.

A capacidade do protocolo non é compatibilidade do cliente

A especificación de IKEv2 inclúe a autenticación con clave compartida, así que unha pasarela pode configurarse lexitimamente para iso. O perfil nativo de acceso remoto de Windows documenta en cambio disposicións con certificados e EAP, e a capacidade do protocolo non crea ningún campo, parámetro nin valor de rexistro que o cliente nunca tivese.

Normalmente a xente acaba en referencia de PowerShell para engadir unha conexión VPN, onde se mostra L2tpPsk para a disposición L2TP. Ese parámetro pertence a L2TP e non é un segredo xeral de IKEv2. Os axustes de selección de algoritmos elixen parámetros de protección, que é unha terceira cousa sen relación. O rol de encamiñamento de Windows Server tampouco é o mesmo obxecto. Unha interface de servidor pode ter controis de configuración que un perfil de cliente de escritorio non ten, e copiar un axuste de servidor a un perfil de estación de traballo non reproduce a capacidade.

Escolla entre certificado, EAP ou L2TP

Se o operador da pasarela acepta a autenticación por certificado, adoita ser o destino máis limpo: o cliente presenta un certificado, a pasarela valídao contra un emisor de confianza e non queda ningún segredo compartido nun perfil para que alguén o copie. Require inscrición, unha cadea de confianza e unha configuración da pasarela que vincule o certificado a unha decisión de autorización.

EAP cunha credencial de usuario é a outra vía admitida neste cliente, e traslada a decisión a un provedor de identidade. Tamén introduce as súas propias dependencias, porque o método EAP, o certificado do servidor e a confianza do cliente nese certificado deben encaixar. Cambiar a L2TP/IPsec só para obter un campo familiar cambia a pila de protocolos. Iso é aceptable cando é unha opción admitida cun motivo documentado, e é un mal resultado cando ocorre porque alguén buscaba unha caixa onde escribir unha clave.

Comprobe que aceptará a pasarela

Pregunte ao operador que métodos de autenticación ofrece hoxe o servizo de acceso remoto, non cales admite o produto en xeral. Un servizo configurado para IKEv2 só con PSK non aceptará un certificado porque o cliente prefira un.

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

Lea o método de autenticación do perfil e o almacén de certificados á vez. Un perfil configurado con EAP sen ningún certificado utilizábel detrás falla dun xeito que parece un problema do servidor.

Se a resposta é que só hai PSK, as opcións honestas son un cliente aprobado que o admita ou un cambio no deseño de autenticación da pasarela. Ningunha é unha solución local, e finxir o contrario produce unha conexión que só pode reproducir quen a configurou.

Rexistre a decisión e os segredos

Anote o método elixido, a áncora de confianza, a identidade que lle corresponde e a persoa que aprobou o cambio. Ese rexistro é o que necesita unha revisión de incidentes e tamén o que impide que o seguinte enxeñeiro volva percorrer o mesmo calexón sen saída.

Manteña os segredos separados nas súas notas: un contrasinal de conta, unha frase de paso de clave privada e unha clave precompartida de pasarela son tres cousas distintas, mesmo cando unha pantalla de axustes as chama todas contrasinal. Confundilas é como unha clave acaba nun ticket. Probe o perfil resultante cunha conexión nova e unha petición de aplicación a un recurso privado. Un túnel correcto sen ningún servizo accesible é un resultado parcial, e o perfil non debe describirse como terminado ata que o recurso tamén funcione.