L2TP/IPsec falla cando o servizo IKEEXT está desactivado

Un portátil chega a unha pasarela IKEv2 pero falla contra unha de L2TP/IPsec, e o erro aparece antes de que se envíe ningún nome de usuario. O perfil adoita ser o primeiro sospeitoso e adoita ser o equivocado. Windows executa o intercambio de claves IPsec nun servizo, e mentres ese servizo está desactivado o cliente integrado non ten pila coa que negociar. Comprobe o servizo antes de tocar un só campo do perfil e despois averigüe que o desactivou.

O servizo que está detrás do fallo

IKE and AuthIP IPsec Keying Modules, que aparece como IKEEXT na lista de servizos, realiza o intercambio de claves e mantén os sockets UDP 500 e 4500 en Windows. Desactíveo e tanto L2TP/IPsec como IKEv2 perden o seu negociador, mentres que PPTP e SSTP poden seguir funcionando porque non dependen del. Esa división explica que un usuario informe de que un tipo de VPN funciona e outro está morto na mesma máquina. O servizo forma parte do sistema operativo, así que ningunha opción do perfil pode substituílo.

Liberar eses dous portos é o efecto secundario que xera os malos consellos. Unha ferramenta ou unha mensaxe de foro decátase de que 500 e 4500 están ocupados, detén o servizo para liberalos e con iso elimina IPsec do equipo sen avisar. Os dous efectos son unha soa acción, así que calquera guía que recomende despexar os portos describe un intercambio e non unha reparación.

Devolver o servizo ao seu sitio sen adiviñar

Faga dúas preguntas ao xestor de servizos: cal é o tipo de inicio e cal é o estado actual. A primeira indica se o servizo volverá tras un reinicio; a segunda, se se está executando agora. Execute ambas as consultas desde unha consola elevada para que a mesma shell poida cambiar a configuración despois.

sc qc ikeext
sc query ikeext

Un tipo de inicio Disabled explica todo o síntoma, e a solución é volver poñelo en Automatic e iniciar o servizo. Na consola de Servizos a entrada aparece co seu nome para mostrar, IKE and AuthIP IPsec Keying Modules, así que buscar IKEEXT nesa lista non atopa nada. Reinicie se o servizo se iniciou despois de que xa se executara unha conexión fallida, porque unha pila inicializada nesa orde pode fallar de formas que parecen non ter relación.

sc config ikeext start= auto
net start ikeext

Que o volve apagar

Algunhas suites de VPN de terceiros inclúen a súa propia implementación de IPsec e desactivan IKEEXT durante a instalación, tras o cal o cliente de Windows deixa de funcionar. Quitar o outro produto restaurou L2TP/IPsec en máquinas onde as edicións do perfil non lograban nada, e o mesmo fixo reinstalalo sen o compoñente en conflito. O servizo desactivouse na instalación, non o cambiou o usuario.

As directivas de grupo tamén poden fixar o tipo de inicio; nese caso, un cambio local revértese na seguinte actualización e o administrador dono da directiva ten que cambialo. Anote o tipo de inicio antes dun reinicio, despois dun reinicio e despois de que se actualice o outro produto, coa data cada vez. Un valor que volve unha e outra vez a Disabled delata o seu dono polo patrón, non por conxecturas.

Lea a fase e despois o rexistro

Co servizo en marcha, a fase do fallo decide onde mirar despois. Un bloqueo durante IKE adoita significar que UDP 500 ou 4500 nunca chegou ao servidor, ou que o servidor está detrás de NAT sen a configuración de encapsulación correspondente. Chegar ao aviso de credenciais e fallar alí é un problema de autenticación PPP, non de IPsec. Un túnel que se levanta e non alcanza nada é un fallo de encamiñamento ou de túnel dividido, e só o primeiro deses tres vive no perfil da VPN.

Os perfís con certificado engaden unha fase propia. O cliente ten que confiar na autoridade emisora e o certificado ten que nomear o servidor que se valida; cando falla calquera das dúas condicións, o diálogo segue informando dun erro de negociación inicial, así que o rexistro de eventos é onde aparece o motivo real. Lea a entrada do rexistro antes de editar o perfil, porque o diálogo comprime varios fallos distintos nunha soa frase. Un certificado caducado produce o mesmo diálogo que un servizo desactivado, e por iso importa a entrada do rexistro.

Anote a fase que falla, o texto do erro e a marca de tempo de cada intento. Esos tres campos separan un problema de accesibilidade dun de autenticación e dun de encamiñamento, e converten o seguinte cambio nunha decisión en lugar dunha conxectura.

O que unha reparación local non pode demostrar

Restaurar o servizo arranxa a metade do camiño que está no portátil. Un servizo que funciona só demostra a metade local: o extremo remoto aínda ten que aceptar a proposta escollida, as credenciais enviadas e o enderezo de orixe do que chega o paquete. Nada do que se faga no portátil compensa unha devasa que descarta UDP 500 antes de que chegue ao par. Un estado de servizo correcto é unha condición previa, non unha proba de que o túnel vaia levantarse.

Desactivar IKEEXT para liberar os portos só é defendible se acepta que as VPN IPsec de Windows deixan de funcionar. Resolve un conflito de portos eliminando a función que necesitaba o porto, que raramente é o intercambio que o usuario pretendía. Antes de cambiar nada, confirme que o servizo está presente, posto en Automatic e en execución, que non hai unha segunda pila IPsec instalada e que a clave precompartida ou a cadea de certificados coincide coa pasarela.

• IKEEXT está presente, posto en Automatic e en execución antes de que o cliente se conecte.
• Nada máis retén UDP 500 nin 4500.
• Non queda unha segunda pila IPsec dun cliente antigo.
• A clave ou a cadea de certificados coincide coa configuración da pasarela.
• A fase que fallou quedou rexistrada antes de editar o perfil.