¿El VPN de Windows no se conecta? Haz coincidir el código con el registro de eventos

El viernes funcionaba. El lunes el mismo cliente de Windows responde con un cuadro de diálogo que dice que el intento de conexión ha fallado, y la frase de debajo es una que ya has visto para una docena de problemas sin relación. Ese cuadro de diálogo es el final de una cadena, no su principio. Windows oculta la etapa en la que el intento murió realmente, y dos pequeñas pruebas la nombran: el código numérico de resultado y un evento RasClient de ese mismo minuto. Este es el orden que uso — fija el intento, lee el código, extrae el evento y luego cambia exactamente una capa.

El texto del diálogo es el último paso, no la causa

La frase que lees se elige después de que el intento ya se haya desenrollado. "La conexión fue terminada por el equipo remoto antes de que se estableciera la conexión" aparece cuando un servidor cuelga a mitad de la negociación, cuando IPsec falló antes de que tu nombre de usuario se enviara siquiera, y cuando una directiva rechazó el túnel de plano. Tres propietarios distintos, una frase. Trata la redacción como una clase de síntoma y no dejes que dirija nada hasta que el código esté de acuerdo con ella.

Lo que aún puedes fijar es el intento mismo. Anota el nombre de la conexión, el tipo de túnel guardado en el perfil — PPTP, L2TP/IPsec, SSTP o IKEv2 —, la hora hasta el segundo y el código. Si no estás seguro de qué protocolo se ejecutó realmente, abre %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk y lee la entrada en lugar de confiar en la memoria; un perfil reutilizado para un protocolo nuevo conserva su antiguo nombre para mostrar.

Lee el número antes de leer las palabras

Los códigos caen en tres etapas, y la etapa importa más que la redacción exacta: un intercambio de autenticación al que se llegó y se rechazó, un servidor que nunca respondió, o una negociación que se derrumbó después de que el enlace subiera. 691 es el primer tipo — la comprobación de credenciales se ejecutó y falló, ya fuera por una contraseña incorrecta, una cuenta bloqueada o caducada, o un protocolo de autenticación que el servidor no acepta. 812 también es un rechazo, pero con credenciales válidas: una directiva del servidor de acceso remoto decidió en tu contra. Microsoft mantiene la lista de códigos de error de conexión de marcado y VPN canónica, y vale la pena leer tu número allí antes de buscar el texto del mensaje.

809 es la clase opuesta: no volvió nada. Eso es un problema de ruta — TCP 443 filtrado para SSTP, GRE bloqueado para PPTP, UDP 500 y 4500 o ESP descartados para el paso de IPsec. Una contraseña nueva no puede arreglarlo y un certificado nuevo tampoco. 720 significa que el enlace subió y que PPP nunca terminó de negociar, lo que apunta a una discrepancia de protocolo o a un servidor que no pudo asignar una dirección. 789, o 13801 en IKEv2, es identidad dentro de IPsec: un certificado cuyo sujeto no coincide con el nombre que marcas, una cadena no confiable, o una clave precompartida que difiere entre los dos extremos.

Extrae el evento RasClient de ese mismo minuto

En el Visor de eventos, Windows Logs > Application filtrado por origen RasClient es el primer lugar donde mirar. El artículo de Microsoft sobre el error 720 apunta al evento 20227 de ese registro. El mismo proveedor emite otros identificadores para otros resultados, así que lee el mensaje y el código de resultado incrustado en lugar de tratar el ID como el diagnóstico; un diálogo genérico más un 20227 que lleva 720 ya es una historia mucho más estrecha.

Desde PowerShell, sin hacer clic por la GUI:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

Un resultado vacío es informativo. Normalmente significa que el marcado nunca llegó lo bastante lejos como para que RAS registrara algo, o que el software que falló no es el cliente nativo en absoluto — los clientes de terceros guardan su propio diagnóstico y a menudo no escriben nada en el registro Application. Comprueba el registro del proveedor antes de concluir que el registro de eventos está roto.

Construye una línea de tiempo en lugar de un montón de eventos

Los bucles de reintento fabrican ruido. Cinco reconexiones automáticas dejan un grupo de eventos, y la tentación es leerlos como una sola secuencia con una sola causa. Son cinco intentos separados, y solo algunos llegaron a un servidor. Toma una ventana de dos o tres minutos, un nombre de conexión, y lista cada evento con su propio código antes de interpretar nada.

Luego pregunta dónde se detuvo el intento. Cuando la puerta de enlace o el backend de autenticación no guarda ningún registro para esa marca de tiempo, el cliente nunca llegó a él, y estás ante un problema de accesibilidad. Cuando el backend muestra una petición y un rechazo, la decisión se tomó allí, y se aplica la clase de credenciales o de directiva. Compara los relojes antes de comparar las horas: los clientes informan de la hora local, muchas puertas de enlace registran en UTC, y un desfase hará que una pareja perfectamente correlacionada parezca no relacionada.

Para una captura repetible, marca desde la línea de comandos y deja que imprima el resultado:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

La consola muestra el número que la GUI esconde tras un texto amable, y ejecutarlo dos veces te dice si el código es estable o intermitente.

Qué te dice cada etapa que cambies

Nombrar la etapa solo es útil si reduce el conjunto de cambios a una capa:

• 691 — autenticación: el método EAP que ofrece el cliente frente al que acepta el servidor, el estado de la cuenta, la caducidad de la contraseña, el permiso de marcado.
• 812 — directiva del servidor: la directiva de acceso remoto o la regla NPS que coincide con este usuario y esta ventana de tiempo.
• 809 — accesibilidad: reglas de firewall en la ruta, NAT y paso de protocolo, el puerto que necesita el tipo de túnel elegido.
• 720 — negociación PPP: discrepancia de protocolo de autenticación, asignación de dirección, un ajuste PPP del lado del servidor.
• 789 / 13801 — identidad IPsec: sujeto del certificado frente al nombre que marcas, cadena de confianza, clave precompartida.

Cambia una de esas cosas, vuelve a probar el mismo perfil y anota el código nuevo. Un código distinto después de un cambio es progreso, no contradicción: has movido el fallo a una etapa posterior, y así es como se ve arreglar un apretón de manos de varias etapas. Lo que no deberías hacer es alterar el firewall, el certificado y la contraseña en una sola sesión y luego dar el mérito al que llegó el último.

Comparte las pruebas, no el entorno

Los mensajes de evento son más ricos de lo que parecen. Llevan el nombre de la conexión, la cuenta, a menudo el nombre o la dirección interna de la puerta de enlace, y a veces una huella de certificado. Guarda el original donde corresponde, y construye una copia redactada aparte para cualquier otra persona; reescribir la línea de tiempo de memoria pierde exactamente los detalles que la hacen útil.

Un traspaso que se llega a trabajar necesita cinco campos: el código, la etapa a la que pertenece, el cliente y el tipo de túnel, la marca de tiempo con su zona horaria, y si la puerta de enlace vio la petición siquiera. Todo lo demás es opcional. Con esos cinco, la siguiente persona puede distinguir una discusión de credenciales de una de enrutamiento sin repetir la investigación.

Antes de cerrar nada, reproduce el intento con el mismo perfil y confirma dónde cae ahora el código. Un éxito lo termina; un fallo distinto significa que la etapa original está arreglada y tienes la siguiente en la mano.