Por que o Windows IKEv2 nativo não tem nenhum campo de PSK

A documentação do gateway diz que a chave pré-compartilhada vai no cliente, mas o perfil do Windows não tem campo para ela. Essa lacuna não é um bug que se contorna digitando a chave na caixa de senha. É a diferença entre o que um protocolo pode fazer e o que uma implementação específica oferece.

A capacidade do protocolo não é suporte do cliente

A especificação do IKEv2 inclui autenticação com chave compartilhada, então um gateway pode ser configurado legitimamente para isso. O perfil nativo de acesso remoto do Windows documenta, em vez disso, arranjos com certificados e EAP, e a capacidade do protocolo não cria campo, parâmetro ou valor de registro que o cliente nunca teve.

As pessoas costumam parar em referência do PowerShell para adicionar uma conexão VPN, que expõe L2tpPsk para o arranjo L2TP. Esse parâmetro pertence ao L2TP e não é um segredo geral do IKEv2. As configurações de seleção de algoritmo escolhem parâmetros de proteção, o que é uma terceira coisa sem relação. O papel de roteamento do Windows Server também não é o mesmo objeto. Uma interface de servidor pode ter controles de configuração que um perfil de cliente desktop não tem, e copiar uma configuração de servidor para um perfil de estação de trabalho não reproduz a capacidade.

Escolha entre certificado, EAP ou L2TP

Se o operador do gateway aceitar autenticação por certificado, esse costuma ser o destino mais limpo: o cliente apresenta um certificado, o gateway o valida junto a um emissor confiável e nenhum segredo compartilhado fica em um perfil para alguém copiar. Isso exige inscrição, uma cadeia confiável e uma configuração de gateway que associe o certificado a uma decisão de autorização.

EAP com uma credencial de usuário é o outro caminho suportado neste cliente, e transfere a decisão para um provedor de identidade. Também introduz dependências próprias, porque o método EAP, o certificado do servidor e a confiança do cliente nesse certificado precisam estar alinhados. Mudar para L2TP/IPsec só para obter um campo familiar altera a pilha de protocolos. Isso é aceitável quando é uma escolha suportada com um motivo documentado, e é um resultado ruim quando acontece porque alguém procurava uma caixa para digitar uma chave.

Verifique o que o gateway aceitará

Pergunte ao operador quais métodos de autenticação o serviço de acesso remoto oferece hoje, não quais o produto suporta em geral. Um serviço configurado para IKEv2 apenas com PSK não aceitará um certificado porque o cliente prefira um.

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

Leia o método de autenticação do perfil e o repositório de certificados em conjunto. Um perfil definido para EAP sem certificado utilizável por trás falha de um modo que parece um problema do servidor.

Se a resposta for que só há PSK disponível, as opções honestas são um cliente aprovado que o suporte ou uma mudança no desenho de autenticação do gateway. Nenhuma delas é uma solução local, e fingir o contrário produz uma conexão que só quem a configurou consegue reproduzir.

Registre a decisão e os segredos

Anote o método escolhido, a âncora de confiança, a identidade correspondente e a pessoa que aprovou a mudança. Esse registro é o que uma revisão de incidente precisa, e é também o que impede o próximo engenheiro de redescobrir o mesmo beco sem saída.

Mantenha os segredos separados nas suas notas: uma senha de conta, uma frase secreta de chave privada e uma chave pré-compartilhada de gateway são três coisas diferentes, mesmo quando uma tela de configurações chama todas de senha. Confundi-las é como uma chave acaba em um ticket. Teste o perfil resultante com uma conexão nova e uma requisição de aplicação a um recurso privado. Um túnel bem-sucedido sem serviço acessível é um resultado parcial, e o perfil não deve ser descrito como concluído até que o recurso também funcione.