Servidor PPTP detrás de un router doméstico: arregla primero el 1723 y el GRE

PPTP detrás de un router doméstico falla de dos maneras no relacionadas, y confundirlas cuesta una tarde entera. Un fallo es un hueco en el reenvío: el router deja pasar TCP 1723 y descarta el protocolo IP 47, así que el cliente se queda colgado en el error 619. El otro es un problema de tamaño: el túnel sube, se autentica y luego se congela cuando tiene que cruzar un paquete de tamaño completo. Averiguar cuál de los dos tienes es el primer paso real; el resto compara qué puede expresar tu router, no qué marca es mejor.

Dos transportes, y solo uno tiene puerto

PPTP se divide en dos transportes: una conexión de control en TCP 1723 y tramas PPP envueltas en GRE mejorado, que es el protocolo IP 47. GRE no tiene número de puerto, así que una regla escrita como reenvío del puerto 1723 no puede cubrirlo, por mucho que la interfaz web nombre el campo. Un router doméstico suele ofrecer una casilla llamada paso PPTP en lugar de una regla de protocolo, y esa casilla hace dos trabajos: permite el protocolo 47 a través del cortafuegos y enseña al NAT a seguir el flujo GRE. En un router Linux esos trabajos son módulos separados y reglas separadas, y por eso un paso a medio configurar sigue produciendo un canal de control operativo. Averigua qué mitad está presente antes de cambiar nada.

El cortafuegos del propio servidor también debe permitir el protocolo 47 desde la dirección del router. Un cortafuegos del host que solo acepta 1723/tcp reproduce el error 619 desde dentro de la LAN, lo que hace que un reenvío roto y una regla de host rota parezcan idénticos.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Si faltan los módulos, cárgalos con sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre y haz que la carga sea permanente, porque un reinicio que olvida el ayudante convierte un túnel operativo en el error 619 otra vez. La regla de reenvío solo necesita aceptar el protocolo 47 hacia la dirección del servidor, no toda la LAN. La definición de RFC 2637 separa los caminos de control y de datos, y por eso ninguna pantalla de reenvío de puerto describe PPTP por completo.

Casilla de paso o una regla de protocolo explícita

Una casilla de paso que solo abre el cortafuegos está más cerca de lo correcto que un ALG que reescribe identificadores de llamada. La mitad del cortafuegos es previsible, ya que o se acepta el protocolo 47 o se descarta, y los contadores dicen cuál. La mitad de la reescritura es donde los fabricantes difieren, porque los identificadores de llamada de PPTP son por túnel y un NAT que los edita tiene que seguir cada llamada que toca. Cuando un cliente conecta y dos no, el ALG es el primer sospechoso.

Una regla de NAT de destino para el 1723 también tiene un problema de propiedad. Si una regla vieja sigue enviando el 1723 a un host que dejó de ejecutar el servidor, los paquetes caen en un puerto cerrado y el propio servicio PPTP del router deja de responder, lo que se lee como un fallo del cortafuegos pero en realidad es un destino obsoleto. Lee la regla y su destino antes de añadir una segunda. En routers que terminan PPTP ellos mismos, la regla WAN compite con el servicio integrado, así que elige un solo propietario para el 1723 y el protocolo 47.

Dos clientes detrás del mismo NAT son el caso que separa un reenvío simple de uno ingenioso. Reenviar el protocolo 47 sin reescribir los identificadores de llamada suele comportarse mejor que un ayudante que intenta arreglarlos.

Mide el túnel antes de culpar al router

PPTP reduce la carga útil, y esa reducción es aritmética, no misterio. Cada paquete del túnel lleva una cabecera IP exterior, una cabecera GRE mejorada, una cabecera PPP y, con cifrado, una cabecera MPPE. Cuando el camino no puede llevar la trama resultante, los paquetes pequeños pasan, el inicio de sesión se completa y la sesión se detiene la primera vez que una transferencia de archivos o un saludo TLS envía un paquete de tamaño completo.

Calcula el número en lugar de adivinarlo. El GRE mejorado cuesta 8 bytes, PPP cuesta 4, MPPE cuesta 4 y la cabecera IP exterior cuesta 20, así que el túnel se come 36 bytes antes de cualquier carga. En una WAN PPPoE que termina en 1492, el PPP MTU más grande que cabe es 1492 menos 36, es decir 1456. Fija mtu y mru en ese valor en las opciones PPP y vuelve a probar con un ping sin fragmentación.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

El ping mide el camino, no el túnel: 1464 bytes de carga más 28 bytes de cabeceras IP e ICMP llenan exactamente una trama de 1492 bytes. Si ese ping falla, baja el número hasta que pase y resta 36 del resultado. Un MTU de túnel puesto por encima del límite del camino produce el congelamiento sin una sola línea de registro que mencione el tamaño.

PPTP, L2TP/IPsec u OpenVPN en el mismo router

El mismo router puede llevar cualquiera de los tres túneles habituales, y la diferencia es qué tiene que expresar. PPTP necesita dos reglas en dos capas distintas. L2TP sobre IPsec necesita UDP 500 y 4500 para el intercambio de claves y, salvo que NAT-T lo lleve, el protocolo 50 para la carga. OpenVPN necesita un solo puerto UDP y ningún ayudante.

La columna de L2TP no es automáticamente más amable que la de GRE. ESP es el protocolo IP 50 y tampoco tiene puerto, así que un router que tiene problemas con el protocolo 47 puede tenerlos con el protocolo 50 por el mismo motivo. NAT-T existe para envolver ESP dentro de UDP 4500, y cuando ambos extremos lo admiten la regla del protocolo 50 se vuelve innecesaria. Eso es una propiedad de los extremos, no de la casilla PPTP del router. Confirma qué encapsulación negoció realmente el cliente antes de escribir reglas para ambos.

OpenVPN es la opción con menos piezas móviles en el lado del router. Un puerto UDP, un reenvío, ningún ayudante de seguimiento de conexiones y ninguna reescritura de identificadores de llamada. El intercambio es un cliente que hay que instalar en lugar de un marcador integrado, y a menudo es la única razón por la que PPTP sigue en la conversación.

Qué reparar y qué sustituir

Arreglar el reenvío y el MTU te da un túnel que funciona, no uno que debas conservar. La autenticación MSCHAPv2 de PPTP es atacable desde hace años, y un túnel operativo mueve credenciales que pueden recuperarse sin conexión. Si el dispositivo remoto puede ejecutar L2TP/IPsec u OpenVPN, trata la reparación como una medida temporal con fecha.

La decisión se reduce a qué admite el extremo lejano y cuánto tiene que durar el arreglo. Un aparato antiguo que solo habla PPTP recibe la reparación; todo lo que pueda instalar un cliente se migra.

Antes de cerrar el tique, confirma que el cliente sobrevive a una transferencia grande y no solo a un inicio de sesión, y que el router sigue manteniendo su regla del protocolo 47 tras un reinicio. Un túnel que pasa una copia de archivo y muere tras la siguiente actualización de firmware nunca estuvo terminado.