Error PPTP 800 frente a 812 y cortes después de un minuto

Tres mensajes de error de un mismo cliente PPTP suelen describir tres fallos distintos. El error 800 significa que el túnel nunca llegó a formarse, el error 812 significa que el servidor rechazó el método de autenticación, y un corte después de un minuto es un temporizador de keepalive que decide que un par sano se ha ido. Cada etapa falla por su propia razón, así que cada una necesita su propia comprobación.

El error 800 significa que el túnel nunca llegó a formarse

Windows genera el error 800 cuando no puede construir el túnel en absoluto, y el texto sobre un servidor inalcanzable o parámetros de seguridad inadecuados es un resumen y no un diagnóstico. PPTP necesita dos cosas separadas de la red antes de que se examine cualquier credencial. TCP 1723 transporta el canal de control, y el protocolo IP 47, GRE, transporta la carga encapsulada.

Prueba esa ruta exterior desde fuera de tu propia LAN, porque una conexión que funciona dentro de la oficina no demuestra nada sobre el borde:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Si el 1723 responde y la captura queda vacía mientras el cliente intenta conectarse, la ruta está descartando el protocolo 47. Un router con el 1723 reenviado pero el paso PPTP desactivado produce exactamente ese patrón: el apretón de manos TCP se completa, luego los paquetes GRE desaparecen, así que el fallo parece un problema de credenciales aunque no se haya intentado ningún inicio de sesión.

Dirige el reenvío a la dirección LAN actual del servidor, activa el paso PPTP donde el router lo ofrezca y vuelve a intentarlo desde el mismo punto exterior. Cuando el GRE se filtra aguas arriba y no puedes cambiarlo, SSTP sobre TCP 443 o L2TP/IPsec sobre UDP 500 y 4500 tiene mejores posibilidades que cualquier cambio que puedas hacer en el lado de Windows.

El error 812 es el servidor rechazando tu método de autenticación

El error 812 vuelve después de que el túnel está levantado, por eso se siente como un problema de contraseña. El servidor rechaza el método de autenticación negociado para la conexión, no necesariamente la contraseña en sí. En el cliente, abre la entrada VPN, ve a la pestaña de seguridad, pon el tipo en Point-to-Point Tunneling Protocol, elige la lista explícita de protocolos y marca Microsoft CHAP versión 2.

Puedes leer el ajuste actual sin pasar por el diálogo:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Un servidor que exige MS-CHAP v2 rechaza a un cliente dejado en PAP o en un tipo automático que negocia algo más débil, y el error llega antes de que se evalúe cualquier contraseña de usuario. El formato de la cuenta es la otra mitad del mismo rechazo. En un caso, Windows envió una identidad de cuenta de Microsoft con la forma MicrosoftAccount\[email protected] mientras el servidor quería una cuenta local o de dominio. Escribir SERVERNAME\username le dijo a Windows qué almacén de cuentas consultar y borró el error. Introduce el nombre a mano en lugar de dejar que una credencial guardada reproduzca un formato anterior.

Los cortes después de un minuto son una decisión de keepalive

Cuando el túnel se conecta, pasa algo de tráfico y luego se desconecta, mira el comportamiento de eco LCP del servidor antes de tocar el cliente. El demonio pide periódicamente al par que confirme que sigue ahí. Si llegan muy pocas respuestas dentro del presupuesto configurado, la sesión se derriba aunque el usuario todavía tenga un enlace funcional.

En un servidor Linux pptpd esos valores viven en /etc/ppp/options.pptpd, y la reparación habitual es ampliar el presupuesto en lugar de acortar el intervalo:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Treinta fallos con un intervalo de cinco segundos perdonan un parón breve en lugar de declarar que el par se ha ido. Reducir la cuenta a uno o dos convierte el jitter normal en una ruta traducida en una desconexión aproximadamente cada minuto. Si tu servidor es Windows RRAS en lugar de pptpd, mira en cambio el tiempo de espera de la sesión PPP y la política de desconexión por inactividad. Esos viven en otro sitio, y editar un archivo pppd que no existe no cambiará nada.

Las subredes superpuestas rompen la ruta de datos

Un túnel PPTP puede autenticarse limpiamente y aun así no llegar a nada cuando ambos sitios usan el mismo rango privado, por ejemplo 192.168.1.0/24 en la oficina y en casa. El cliente no puede decir a qué host se refiere una dirección dada, y algunas pilas se niegan a instalar la ruta del todo en lugar de elegir una.

Trátalo como un defecto de diseño y renumera un lado, o entrega al cliente un rango de acceso traducido a propósito. Depurar el cliente PPTP no puede arreglar un espacio de direcciones que existe dos veces, y el síntoma seguirá pareciendo un corte aleatorio.

Empieza por la etapa que falló: GRE para el 800, el método y la cadena de cuenta para el 812, ajustes de eco para un túnel que muere según el horario.