Los fallos de escritura GRE en pptpd no son un problema de contraseña

Fallo de escritura GRE en el registro, y el primer instinto es restablecer la contraseña del usuario. Ese instinto casi siempre es erróneo. Estos mensajes describen la ruta de datos, no la comprobación de credenciales: el cliente puede haberse autenticado correctamente y luego haberse atascado en la etapa en la que se registra en la red. Dos mensajes distintos apuntan a dos fallos distintos, y ninguno se resuelve con una contraseña nueva.

Dos mensajes, dos fallos distintos

Un fallo de lectura significa que los paquetes GRE nunca llegan al demonio o se descartan a la entrada. La conexión de control puede parecer perfectamente sana mientras nada cruza la ruta de datos. La autenticación es lo único que funcionó de forma demostrable.

Un fallo de escritura suele significar que la sesión negoció algo que el núcleo o el cliente no pueden usar. El canal de control se completó, y las opciones acordadas durante ese intercambio no coinciden con lo que los extremos pueden hacer realmente. Es un desacuerdo de configuración, no un evento de autenticación.

Lea cuál de los dos aparece antes de cambiar nada. Le llevan a capas distintas, y tratarlos como un solo síntoma es la razón por la que el mismo servidor se parchea dos veces por motivos no relacionados. La línea del registro es el único diagnóstico gratuito que obtiene.

El protocolo 47 no es el puerto 47

PPTP usa TCP 1723 para establecer la llamada y GRE para transportar la carga útil. GRE es el protocolo IP 47, no un número de puerto, así que una regla de cortafuegos que abre el puerto 47 no permite nada útil.

Un enrutador en la ruta necesita una función de paso de PPTP o un permiso explícito de GRE. Sin ello, el saludo TCP se completa y el túnel nunca transporta un paquete, lo que produce exactamente el fallo de lectura anterior. Las reglas del puerto 47 en un cortafuegos son la tarde más desperdiciada de este protocolo.

Observe ambas direcciones a la vez en el servidor en lugar de adivinar qué lado descarta el tráfico: tcpdump -ni any port 1723 or proto gre.

Si 1723 muestra el establecimiento de la llamada mientras GRE permanece en silencio, el bloqueo está por encima del host. Si GRE llega y el demonio sigue fallando, el problema es local y las opciones son el siguiente lugar donde mirar.

Permita GRE donde el host reenvía de verdad

Insertar una regla forward para GRE es una prueba razonable en un host que reenvía tráfico de túnel, y no es una política. Una regla de prueba que acepta todo de un protocolo es un diagnóstico, no un diseño. Déjela el tiempo suficiente para aprender algo y luego sustitúyala por una regla limitada.

Añada una regla input para los paquetes dirigidos al propio servidor, porque la cadena forward no los ve. Después observe los contadores de la regla antes y después de un intento de conexión, lo que le dice si los paquetes llegan siquiera.

Haga persistente la regla mediante el servicio de cortafuegos de la distribución en lugar de volver a ejecutarla tras cada reinicio. En un host nftables, haga coincidir ip protocol gre tanto en la cadena input como en la forward.

Confirme que el módulo ppp_generic también está cargado y compruebe si el seguimiento de conexiones descarta la dirección de retorno. Ambos producen fallos que parecen un problema de cortafuegos y no lo son. Un módulo del núcleo ausente parece exactamente un protocolo bloqueado hasta que lo comprueba.

Ajuste las opciones al cliente que realmente tiene

La corrección del otro informe está en /etc/ppp/pptpd-options, donde la receta rechaza PAP, CHAP y MSCHAP, comenta las líneas require correspondientes y mantiene MPPE con estado. Esa receta se escribió para una mezcla de clientes, y copiarla a ciegas rompe el caso habitual. Lea las líneas de rechazo como una afirmación sobre qué clientes tenía el autor, no como una recomendación.

Un cliente de Windows normalmente necesita MS-CHAPv2 con MPPE-128. Mantenga esos requisitos y elimine solo las opciones que el cliente realmente no puede negociar.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Desactivar el cifrado para que una conexión funcione es una degradación, no una reparación. Pruebe esa variante en un enlace de laboratorio y luego restablezca el cifrado antes de que el servicio se enfrente a clientes reales. La conexión que funciona de forma insegura es peor que la que falla con honestidad.

Lea el número de error del cliente

El código numérico del cliente estrecha la etapa más rápido que el registro del servidor. Léalo antes de leer cualquier otra cosa. 691 significa que se rechazaron las credenciales, 721 significa que el servidor nunca respondió y 619 significa que la conexión se cortó. Dos minutos con el número ahorran una hora con la configuración.

Compare ese código con el registro del servidor antes de editar nada y vuelva a probar con el mismo cliente tras cada cambio. De lo contrario, un segundo fallo se esconde detrás del primero y la corrección parece ineficaz.

Cuando el inicio de sesión tiene éxito y no se mueve tráfico, GRE sigue siendo el sospechoso. Ese es el momento de volver a la captura en lugar del almacén de credenciales.