L2TP/IPsec falha quando o serviço IKEEXT está desativado

Um portátil chega a um gateway IKEv2 mas falha contra um de L2TP/IPsec, e o erro surge antes de ser enviado qualquer nome de utilizador. O perfil é normalmente o primeiro suspeito e normalmente o errado. O Windows executa a troca de chaves IPsec num serviço, e enquanto esse serviço está desativado o cliente incorporado não tem pilha com que negociar. Confirme o serviço antes de tocar num único campo do perfil e depois descubra o que o desativou.

O serviço por detrás da falha

IKE and AuthIP IPsec Keying Modules, apresentado como IKEEXT na lista de serviços, realiza a troca de chaves e mantém os sockets UDP 500 e 4500 no Windows. Desative-o e tanto o L2TP/IPsec como o IKEv2 perdem o seu negociador, enquanto o PPTP e o SSTP podem continuar a funcionar porque não dependem dele. Essa divisão explica que um utilizador relata que um tipo de VPN funciona e outro está morto na mesma máquina. O serviço faz parte do sistema operativo, pelo que nenhuma definição de perfil o pode substituir.

Libertar essas duas portas é o efeito secundário que produz maus conselhos. Uma ferramenta ou uma publicação de fórum repara que 500 e 4500 estão ocupados, para o serviço para os libertar e, ao fazê-lo, remove silenciosamente o IPsec do anfitrião. Os dois efeitos são uma única ação, pelo que qualquer guia que recomende limpar as portas descreve uma troca e não uma reparação.

Repor o serviço sem adivinhar

Faça duas perguntas ao gestor de serviços: qual é o tipo de arranque e qual é o estado atual. A primeira diz-lhe se o serviço regressa após um reinício; a segunda diz-lhe se está a correr agora. Execute ambas as consultas numa linha de comandos elevada para que a mesma shell possa alterar a definição depois.

sc qc ikeext
sc query ikeext

Um tipo de arranque Disabled explica todo o sintoma, e a solução é repô-lo em Automatic e iniciá-lo. Na consola de Serviços a entrada aparece com o nome a apresentar, IKE and AuthIP IPsec Keying Modules, pelo que procurar IKEEXT nessa lista não encontra nada. Reinicie se o serviço tiver sido iniciado depois de já ter corrido uma ligação falhada, porque uma pilha inicializada nessa ordem pode falhar de formas que parecem não ter relação.

sc config ikeext start= auto
net start ikeext

O que o volta a desligar

Algumas suites de VPN de terceiros incluem a sua própria implementação de IPsec e desativam o IKEEXT durante a instalação, após o que o cliente Windows deixa de funcionar. Remover o outro produto restaurou o L2TP/IPsec em máquinas onde as edições do perfil não conseguiam nada, e o mesmo fez reinstalá-lo sem o componente em conflito. O serviço foi desativado na instalação, não foi alterado pelo utilizador.

As políticas de grupo também podem fixar o tipo de arranque; nesse caso, uma alteração local é revertida na atualização seguinte e o administrador responsável pela política tem de a alterar. Registe o tipo de arranque antes de um reinício, depois de um reinício e depois de o outro produto ser atualizado, com a data de cada vez. Um valor que regressa sempre a Disabled identifica o seu dono pelo padrão, não por adivinhação.

Leia a fase e depois o registo

Com o serviço a correr, a fase da falha decide onde olhar a seguir. Um bloqueio durante o IKE significa normalmente que o UDP 500 ou 4500 nunca chegou ao servidor, ou que o servidor está atrás de NAT sem a definição de encapsulamento correspondente. Chegar ao pedido de credenciais e falhar aí é um problema de autenticação PPP, não de IPsec. Um túnel que sobe e não alcança nada é uma falha de encaminhamento ou de túnel dividido, e apenas a primeira dessas três vive no perfil da VPN.

Os perfis com certificado acrescentam uma fase própria. O cliente tem de confiar na autoridade emissora e o certificado tem de nomear o servidor que está a ser validado; quando qualquer das duas condições falha, a caixa de diálogo continua a comunicar um erro de negociação inicial, pelo que o registo de eventos é onde aparece o motivo real. Leia a entrada do registo antes de editar o perfil, porque a caixa de diálogo comprime vários falhas distintas numa só frase. Um certificado expirado produz a mesma caixa de diálogo que um serviço desativado, e é por isso que a entrada do registo importa.

Registe a fase que falhou, o texto do erro e o carimbo de data e hora de cada tentativa. Esses três campos separam um problema de alcance de um problema de autenticação e de um problema de encaminhamento, e tornam a alteração seguinte uma decisão em vez de um palpite.

O que uma reparação local não pode provar

Restaurar o serviço corrige a metade do caminho que está no portátil. Um serviço a funcionar prova apenas a metade local: o extremo remoto tem de continuar a aceitar a proposta escolhida, as credenciais fornecidas e o endereço de origem de onde o pacote chega. Nada do que se faça no portátil compensa uma firewall que descarta o UDP 500 antes de este chegar ao par. Um estado de serviço bem-sucedido é uma condição prévia, não uma prova de que o túnel vá subir.

Desativar o IKEEXT para libertar as portas só é defensável se aceitar que as VPN IPsec do Windows deixam de funcionar. Resolve um conflito de portas removendo a funcionalidade que precisava da porta, o que raramente é a troca que o utilizador pretendia. Antes de alterar seja o que for, confirme que o serviço existe, está em Automatic e a correr, que não está instalada uma segunda pilha IPsec e que a chave pré-partilhada ou a cadeia de certificados corresponde ao gateway.

• O IKEEXT existe, está em Automatic e a correr antes de o cliente ligar.
• Nada mais ocupa o UDP 500 ou 4500.
• Não resta uma segunda pilha IPsec de um cliente antigo.
• A chave ou a cadeia de certificados corresponde à configuração do gateway.
• A fase que falhou foi registada antes de o perfil ser editado.