PPTP se conecta y luego se cuelga tras Linux NAT: el ayudante GRE

Alguien reenvía el 1723, el cliente llega al servidor, empieza la autenticación y entonces todo se detiene sin un error. La conclusión natural es una contraseña incorrecta, así que la contraseña se vuelve a escribir tres veces. El reenvío estaba bien y las credenciales estaban bien. Lo que se rompió es un segundo protocolo que el reenvío nunca cubrió, y un valor predeterminado del núcleo que dejó de ayudar con él en silencio.

El reenvío nunca fue el problema

Una regla de reenvío de puertos describe tráfico TCP o UDP. No puede describir una carga útil que cambia a otro protocolo IP a mitad de una sesión, y PPTP hace exactamente eso.

Por eso la conexión parece sana hasta el momento en que se cuelga. La parte que una regla de puerto puede gobernar tuvo éxito, y la parte que no puede gobernar es la parte que falló.

TCP para el control, GRE para los datos

La llamada se negocia sobre TCP 1723. Una vez establecida, la carga útil pasa a GRE, protocolo IP 47, que no lleva ningún número de puerto. Una regla que se basa en puertos no tiene con qué coincidir.

Lo que GRE sí lleva es un identificador de llamada en su cabecera, y el traductor NAT tiene que reescribir ese campo de forma coherente en ambas direcciones o las dos mitades de la sesión dejan de coincidir. Una dirección reescrita y la otra no produce una sesión que se autentica y luego descarta cada paquete de datos. Esa es exactamente la forma del síntoma: éxito, y luego silencio.

GRE desnudo sin PPTP no necesita esa reescritura, por eso un túnel GRE simple puede funcionar a través de un router que falla para un cliente PPTP en la misma ruta.

Cuatro módulos y un sysctl que los apagó

Dos módulos se encargan del entramado, nf_conntrack_proto_gre y nf_nat_proto_gre. Otros dos se encargan del identificador de llamada, nf_conntrack_pptp y nf_nat_pptp. Cargar el último de ellos arrastra al resto por dependencias, así que el listado de módulos debería mostrar los cuatro.

Las instrucciones antiguas usan un prefijo ip_ de la era 2.6. Esos comandos pueden parecer que se ejecutan mientras no cargan nada, así que revise la lista cargada en lugar del estado de salida.

Tenerlos cargados ya no basta. Desde Linux 4.7 el sysctl net.netfilter.nf_conntrack_helper vale 0 por defecto, lo que desactiva la asignación automática de ayudantes para los flujos nuevos. Un router puede tener todos los módulos y aun así no traducir nada. Compruebe el valor efectivo antes de volver a mirar la lista de módulos.

O bien vuelva a activar la asignación automática de forma global, o bien enlace el ayudante a los flujos que lo necesitan y deje todo lo demás en paz:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

La segunda opción es la preferible. Limita el comportamiento al tráfico PPTP en lugar de reactivar la asignación automática en todo el router.

Abrir un protocolo que no tiene puertos

Una regla de cortafuegos que permite el 1723 no dice nada sobre el protocolo 47. En firewalld, permita el protocolo en la zona que mira al cliente. En iptables simple, acepte el protocolo gre en la cadena de entrada.

Luego capture en ambos lados. Los paquetes que salen del cliente sin que lleguen respuestas significan que la ruta de vuelta está filtrada, y eso es un fallo distinto de una credencial rechazada.

Después de conectar, el límite de tamaño

GRE inserta una cabecera, y PPP dentro añade más, así que un enlace que funciona informa de una MTU bastante por debajo de 1500. Las respuestas pequeñas cargan y las grandes se atascan, lo que parece un segundo problema no relacionado que aparece justo cuando se resuelve el primero.

Lea la MTU en el adaptador PPP del cliente y concíliuela con el cálculo propio del router en lugar de bajar los números hasta que algo funcione. Los paquetes de tamaño completo que salen sin que vuelva nada apuntan a ese límite y no a la traducción.

Reparar la ruta devuelve al usuario al trabajo, y no hace de PPTP una buena elección. MS-CHAPv2 y RC4 están desaconsejados desde hace mucho, así que trate la carga del módulo como una corrección temporal y planifique el paso a un protocolo mantenido.