Por qué PPP CHAP por sí solo no puede cumplir un requisito de MPPE

Un perfil PPTP que insiste en el cifrado suele fallar en el mismo punto: PPP acuerda un intercambio de autenticación que nunca produce el material de clave que MPPE necesita. El túnel parece medio vivo, la contraseña se acepta y el enlace cae antes de que lo cruce ningún tráfico. Recurrir al desplegable de CHAP hasta que algo conecta oculta el defecto real, que es un contrato entre el método de autenticación y la política de protección. Las comprobaciones siguientes están ordenadas para que cada una descarte una causa más barata que la siguiente.

Dos negociaciones corren dentro de una conexión PPTP

PPTP transporta una sesión PPP normal dentro de un túnel GRE, y ambas negocian por separado. La capa exterior decide cómo se encapsulan los paquetes y qué canal de control existe; la sesión PPP interior decide quién es el par y qué protección va encima. Por tanto, una petición de contraseña solo demuestra algo sobre la capa interior, y un handshake exterior completado no demuestra nada sobre ninguna de las dos. Los perfiles fallan aquí porque la gente depura el túnel mientras el desacuerdo está dentro de PPP.

CHAP simple es el intercambio de desafío y respuesta de la RFC 1994, construido sobre un secreto compartido y nada más. MS-CHAPv2 es un intercambio distinto con mensajes distintos y una salida distinta, estandarizado en la RFC 2759. La palabra compartida de los dos nombres es lo único que tienen en común en el cable. Ninguno de los nombres dice qué produce el intercambio, que es la única parte que importa.

Por eso una opción etiquetada simplemente CHAP es ambigua en un perfil antiguo. Cuando el servidor quiere MS-CHAPv2 y el cliente ofrece CHAP simple, el control de enlace todavía puede completarse y una contraseña todavía puede aceptarse. El fallo llega más tarde, cuando el servidor intenta derivar claves de protección de un intercambio que no produjo ninguna.

Empareje el método requerido con las claves que puede producir

Las claves MPPE no son una propiedad de PPP en general. Para la familia Microsoft CHAP la derivación se especifica en la RFC 3079, y toma como entrada la salida de un intercambio MS-CHAP en lugar de un secreto compartido. Los métodos EAP llegan al mismo punto por otra vía, con el servidor de autenticación devolviendo las claves como atributos MS-MPPE-Recv-Key y MS-MPPE-Send-Key. CHAP simple no aparece en ninguno de los dos caminos, y esa es toda la razón de que exista el desajuste.

Una configuración que exige MPPE mientras rechaza todos los métodos capaces de aportar claves es internamente contradictoria. pppd resuelve esa contradicción rechazando el enlace, no inventando claves, así que el resultado visible es una sesión que se autentica y luego termina durante la fase de red. Reintentar el cliente no lo cambiará mientras el servidor rechace los únicos métodos que derivan algo.

La regla que se sigue es corta: si el perfil exige MPPE, el método debe ser una variante de MS-CHAP o un método EAP cuyas claves devuelva el servidor. Rechazar solo MS-CHAPv2 no lo impone, porque MS-CHAPv1 también deriva claves y sigue disponible salvo que se rechace por separado; rechazar ambos deja CHAP simple y PAP, que no derivan nada y hacen el requisito insatisfacible. Nombre el método aceptado explícitamente en lugar de enumerar los que no le gustan. Abandonar el requisito de cifrado para que un cliente conecte es una degradación, no una reparación.

Lea las opciones del servidor antes de editar un cliente

La mayoría de estos desajustes son visibles en el servidor en dos archivos, y leerlos cuesta menos que reconstruir un cliente. En un extremo PPTP de Linux los ajustes relevantes viven en el archivo de opciones de pppd que pptpd pasa. Ejecútelo en el servidor, no desde una pantalla de estado del cliente. Empiece por las líneas que exigen, rechazan o nombran un modo de protección:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

Lea la salida como un contrato y no como una lista de indicadores. Una línea que exige MPPE mientras rechaza las dos variantes de MS-CHAP no la puede satisfacer ningún cliente, y un requisito ausente para un método MS-CHAP deja la puerta abierta a intercambios que no dan claves. Luego compruebe quién puede autenticarse siquiera, lo que decide el archivo de secretos:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

Anote tres valores antes de cambiar nada: el protocolo exterior, el método de autenticación que exige el servidor y si la protección es obligatoria u opcional. Esos tres determinan cada decisión posterior, y adivinarlos desde un diálogo de cliente es como un perfil acaba medio configurado. Mantenga el archivo abierto mientras trabaja, porque la sección siguiente necesita los mismos tres valores.

Localice el fallo por fase de PPP

PPP informa de los fallos por fases, y la fase dice qué cláusula del contrato se rompió. Un enlace que nunca sale del control de enlace tiene un problema de encapsulación o de negociación, mientras que uno que se autentica y luego muere suele tener un problema de política o de clave. Un enlace que se mantiene arriba y no transporta nada ha pasado al enrutamiento, que es otra investigación.

El diario guarda las líneas de fase, y son más útiles que un nivel de depuración más alto. Pida los procesos PPP y los mensajes de protección, y luego lea el resultado de autenticación antes que nada. Las últimas líneas suelen nombrar la cláusula que rechazó:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

En esa salida, busque primero el resultado de autenticación y luego una queja de que la protección era necesaria pero no se negoció. El segundo mensaje es la firma de la contradicción anterior, y ninguna cantidad de reintentos lo borra mientras el servidor rechace el único método que puede producir claves. Merece la pena nombrar dos trampas: subir el nivel de depuración sin leer las líneas de fase produce ruido, y capturar material de desafío o contraseñas convierte una tarea de configuración en una fuga de credenciales. Registre esa fase antes de cambiar cualquier opción.

Planifique la salida antes de apagar el extremo antiguo

MPPE es un mecanismo histórico de protección de enlace, y su presencia no hace de PPTP una opción sensata para un despliegue nuevo. La guía actual de Microsoft ya desaconseja PPTP y L2TP/IPsec con clave precompartida para nuevos despliegues de acceso remoto. Mantener vivo un extremo heredado es una decisión sobre un servicio existente, no una plantilla para el siguiente.

Cuando el extremo tenga que quedarse, escriba el contrato: protocolo exterior, método de autenticación requerido, protección obligatoria y la versión de cliente que lo negocia. Cuando pueda irse, elija la identidad de puerta de enlace del sustituto, su autenticación de cliente y dónde vivirán las credenciales antes de tocar el perfil antiguo. Después planifique rutas, DNS y los recursos a los que cada usuario está autorizado. Valide el cliente previsto contra los requisitos del propietario y no contra una conexión que funciona.

Un rechazo deliberado debe seguir siendo un rechazo, porque volver a un modo sin protección para que una prueba pase convierte un fallo de política en una exposición. El estado final es un contrato soportado y documentado, no el conjunto más pequeño de cambios que hace que una conexión antigua tenga éxito. Deje el perfil antiguo en su sitio, sin usar y documentado, hasta que el sustituto pase las mismas comprobaciones.