El error 789 en una conexión L2TP de Windows significa que el túnel murió dentro del intercambio de seguridad IPsec, lo que ocurre mucho antes de que Windows envíe una contraseña de usuario a cualquier parte. Reintentar la contraseña, o restablecerla en el directorio, no puede hacer avanzar esa etapa. Lo que sí la hace avanzar es reconstruir la conexión desde PowerShell con la propuesta que la puerta de enlace ofrece realmente, porque el asistente de Configuración elige las transformaciones IPsec en silencio y nunca le muestra qué eligió. Este es el manual para eso: cree el perfil, fije la propuesta y luego use una tabla de etapas para que el siguiente código le diga algo.

Cree el perfil sin el asistente

Add-VpnConnection escribe una entrada nativa de la libreta de teléfonos, así que el resultado es el mismo objeto que la aplicación Configuración editará después. Ejecútelo desde una sesión elevada cuando la conexión deba existir para cada cuenta de la máquina, o desde el contexto de usuario cuando deba permanecer privada:

Add-VpnConnection -Name "Contoso L2TP" `
  -ServerAddress 203.0.113.10 `
  -TunnelType L2tp `
  -EncryptionLevel Required `
  -AuthenticationMethod MSChapv2 `
  -RememberCredential -Force

Haga coincidir -AuthenticationMethod con lo que ofrece la puerta de enlace. MSChapv2, EAP y PAP no son intercambiables, y un perfil que exige un método que el servidor no aceptará falla antes de que se consulte cualquier registro de usuario. Mantenga -EncryptionLevel Required para cualquier cosa real; Optional permite que Windows acepte un túnel sin cifrar si el par ofrece uno, lo que es un atajo de laboratorio y no una configuración para enviar.

Si pasa -L2tpPsk, esa clave precompartida se escribe en el perfil del disco, desde donde cualquiera que pueda leer el perfil en esa máquina puede recuperarla. Use un certificado para autenticar al par cuando la puerta de enlace lo admita, y cuando una PSK sea inevitable, manténgala fuera del repositorio y del historial del shell en lugar de pegarla en cada ejecución de aprovisionamiento.

Fije la propuesta en lugar de aceptar los valores predeterminados

Windows rellena las transformaciones IPsec por sí mismo, y por eso dos máquinas con una conexión aparentemente idéntica pueden fallar de forma distinta contra la misma puerta de enlace. Set-VpnConnectionIPsecConfiguration es la forma admitida de fijarlas:

Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso L2TP" `
  -AuthenticationTransformConstants SHA256128 `
  -CipherTransformConstants AES128 `
  -EncryptionMethod AES128 `
  -IntegrityCheckMethod SHA256 `
  -DHGroup Group14 `
  -PfsGroup None `
  -PassThru -Force

Ese conjunto es una disposición L2TP/IPsec habitual, no una respuesta universal. Cada parámetro acepta una lista fija de valores, y una combinación que la plataforma no puede asignar vuelve como un error del cmdlet en lugar de un perfil debilitado en silencio. Trate ese error como una afirmación sobre los valores, no sobre sus permisos.

Copie la propuesta de la documentación de la puerta de enlace o de sus ajustes activos de fase 1 y fase 2, y cambie un campo cada vez solo mientras la puerta de enlace registra las transformaciones que rechaza. Recorrer cinco campos produce una conexión que funciona por accidente y un registro que no explica nada a la siguiente persona.

Lea un fallo por etapa, no por el texto del error

789 pertenece a una familia de códigos que en el diálogo del cliente parecen todos iguales. Sitúe el código frente a la etapa a la que pertenece antes de volver a tocar el perfil:

What you seeStage that failedCheck first
Nothing happens, then a timeoutNo IKE response at allServer address, UDP 500 and 4500 reachability, NAT traversal on the gateway
Error 789IKE security exchangeProposal, pre-shared key, certificate trust and client clock
Error 691 or a repeated password promptUser authenticationAccount state, domain, RADIUS or NPS policy
Tunnel up, some hosts unreachableRouting or DNS after PPPSplit-tunnel routes, pushed DNS, remote subnet mask

Las dos funciones de las credenciales importan aquí. Una clave precompartida o un certificado autentica a los pares entre sí, mientras que MSChapv2 o EAP le autentica a usted dentro del túnel. Restablecer una contraseña de usuario no puede arreglar la primera, un nuevo secreto compartido no puede arreglar la segunda, y cambiar ambas a la vez destruye la evidencia de cuál estaba mal.

En la ruta del certificado, compruebe el reloj del cliente, la cadena de confianza y la identidad que espera la puerta de enlace antes de plantearse relajar la validación. Desactivar la validación convierte un 789 visible en un túnel que se conecta confiando en el par equivocado, y nada en el cliente le dirá que eso ha ocurrido. lista de errores de acceso remoto de Microsoft es la referencia para los propios códigos, y separa los fallos de la capa de seguridad de los fallos de inicio de sesión.

Verifique desde ambos extremos antes de darlo por arreglado

Vuelva a leer el perfil, pero no espere la propuesta en la salida. Get-VpnConnection informa del nombre, la dirección del servidor, el tipo de túnel, el nivel de cifrado y el método de autenticación, y no sabe nada de las transformaciones, así que la lectura confirma que la entrada existe y apunta al host correcto:

Get-VpnConnection -Name "Contoso L2TP" |
  Select-Object Name, ServerAddress, TunnelType, EncryptionLevel, AuthenticationMethod

Marque desde la línea de comandos para obtener un número en lugar de un diálogo: rasdial "Contoso L2TP" devuelve el mismo código de fallo que devolvería la interfaz, y rasdial "Contoso L2TP" /disconnect lo borra entre intentos. Luego lea el lado de la puerta de enlace para ese mismo intento. Un ipsec statusall de strongSwan o un registro IKE del router indica qué propuesta llegó y cuál se rechazó, y comparar eso con los valores del cmdlet es el único paso que demuestra de verdad que ambos extremos se pusieron de acuerdo.

Una conexión correcta no es la línea de meta. Abra la aplicación que le importa al usuario, porque las rutas, el DNS empujado y los ajustes de túnel dividido fallan después de que el túnel está levantado y no producen ningún diálogo de error.

Automatícelo y vuelva atrás limpiamente

La instalación desatendida es la razón para escribir un script de esto, y el paso de marcado es donde se filtran las credenciales. rasdial las toma en su línea de comandos, donde otros usuarios locales y la mayoría de los recopiladores de registros pueden leerlas:

subprocess.run(["rasdial", "Contoso L2TP"], check=True)

Prefiera una credencial limitada a la cuenta que ejecuta el trabajo, o deje que el perfil la guarde con -RememberCredential, en lugar de pasar una contraseña como argumento en una tarea programada. Los propios comandos de aprovisionamiento son seguros de repetir con -Force, pero superpondrán encantados una propuesta antigua, así que una reejecución solo ayuda si el script lleva los valores actuales.

Los perfiles persisten entre reinicios y sobreviven a la configuración de puerta de enlace para la que se crearon. Cuando la propuesta de la puerta de enlace se mueve, elimine la entrada y vuelva a crearla en lugar de apilar un segundo conjunto de valores: Remove-VpnConnection -Name "Contoso L2TP" -Force, y luego repita los dos cmdlets con el conjunto nuevo.

Cierre el bucle con cuatro comprobaciones que viven junto al script: Get-VpnConnection muestra el tipo de túnel y el nivel de cifrado esperados; la puerta de enlace registra una fase 1 y una fase 2 completadas para la dirección de su cliente; rasdial devuelve éxito y la aplicación se abre; y la propuesta registrada en el script coincide con la configuración actual de la puerta de enlace. Cuando llegue el siguiente 789, esa comparación tarda minutos en lugar de una tarde.

Artículos relacionados