LCP terminado por el par en PPTP: active MPPE primero

El enlace se autentica, el cliente informa que está conectado y, un segundo después, el registro se cierra con LCP terminado por el par. Esa línea viene de la negociación PPP dentro del túnel GRE, así que el transporte ya funcionaba y los dos extremos no coincidían en las opciones del enlace. Las contraseñas y las direcciones del servidor suelen ser inocentes aquí. La política de cifrado es lo primero que hay que comparar y, en Linux, el archivo de par de pppd es el primer lugar donde mirar.

Qué dice el fallo de LCP sobre la etapa PPP

PPTP envuelve PPP dentro de GRE: la conexión de control TCP 1723 prepara la llamada, GRE lleva la carga y luego LCP negocia opciones como el protocolo de autenticación, la compresión y MPPE. El par termina LCP cuando una opción obligatoria no es aceptable por su parte. Un registro en el que el intercambio CHAP o MSCHAPv2 se completa y LCP termina justo después es un rechazo de política, no un fallo de accesibilidad. Si el túnel no llega nunca a la negociación, revise pppd y su complemento antes de leer la línea de LCP.

Hay dos condiciones previas fáciles de pasar por alto. El binario pppd debe existir y el complemento PPTP indicado en el archivo de par debe estar instalado; un paquete ausente termina la llamada antes de que se discuta cualquier opción.

Active MPPE en el lado que lo exige

La decisión real es qué extremo posee la política de cifrado. Un cliente puede ofrecer MPPE, exigirlo o rechazarlo, y el servidor hace la misma elección. Cuando ambos lo exigen, el enlace sube; cuando uno lo exige y el otro lo rechaza, LCP termina.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Cargue el módulo con modprobe ppp_mppe antes de marcar, porque require-mppe-128 falla sin él. En Windows el control equivalente es la pestaña de seguridad de la entrada VPN, donde hay que indicar al cliente que exija cifrado en lugar de aceptar lo que ofrezca el servidor. Si el servidor sigue terminando LCP, pregunte a su operador si MPPE es obligatorio, opcional o está desactivado, ya que un cliente no puede negociar una protección que el servidor rechaza. Desactivar el cifrado para que el mensaje desaparezca es la dirección equivocada: elimina la única protección que tiene este protocolo.

Guarde el archivo de par que funciona antes de editarlo. Una línea require-mppe mal escrita reproduce el mismo fallo genérico de LCP y lo devuelve al principio.

Lea el registro propio de pppd en lugar del applet

Los applets de escritorio muestran la desconexión y ocultan el motivo, así que lea el relato del demonio sobre un intento. En los sistemas con systemd el mensaje acaba en el journal; las configuraciones más antiguas escriben en los archivos de registro tradicionales.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Busque en una ventana alrededor de una sola llamada en lugar de un día entero de reconexiones, para que la opción rechazada sea fácil de ver. pppd suele nombrar la opción y la respuesta del par, lo que le dice si debe cambiar su propia propuesta o pedir al lado del servidor que relaje su requisito. Mantenga los intentos con marca de tiempo, porque comparar dos registros solo sirve cuando sabe qué líneas pertenecen a qué llamada. Cuando no aparece ningún intercambio LCP, la avería está más arriba en la cadena y MPPE no es el sospechoso.

Mantenga la corrección entre reconexiones: nombres de hooks y MTU

Una vez que el enlace se mantiene, dos detalles deciden si sobrevive a una reconexión. Los hooks viven en /etc/ppp/ip-up.d y /etc/network/if-up.d, y run-parts procesa ambos directorios, con un filtro de nombres de archivo que rechaza todo lo que contenga un punto. Por eso se omite un script llamado set-pptp.sh, mientras que set-pptp se ejecuta. Compruebe el nombre antes de depurar el contenido del script y, después, fije la MTU más pequeña desde dentro de ese hook para que cada nueva interfaz ppp la herede sin un comando manual.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Para terminar una sesión a propósito, apunte al pid registrado por pppd en lugar de hacer coincidir nombres de procesos, porque matar todo lo que contenga ppp también derriba enlaces no relacionados. PPTP está obsoleto y MS-CHAPv2 es débil, así que trate estas comprobaciones como mantenimiento de un enlace que debe seguir funcionando, no como un motivo para desplegar PPTP en ningún sitio nuevo.