PPTP en Docker se autentica pero no transporta tráfico

El cliente se autentica, PPP negocia una dirección y entonces nada se mueve. El ping falla, el navegador falla y el contenedor parece conectado todo el tiempo. Ese patrón no es un problema de la tabla de rutas, porque los problemas de enrutamiento suelen romper también la conexión de control. Es la ruta de la carga, y en PPTP la carga es un protocolo distinto del que acaba de funcionar.

Cinco comprobaciones, en el orden que ahorra más tiempo.

Comprobación 1: separe el canal de control de la carga

PPTP se autentica sobre TCP 1723 y luego lleva la carga PPP dentro de GRE, protocolo IP 47. GRE no es TCP ni UDP, así que cada regla que reenvía el puerto de control no dice nada sobre él. Un NAT o cortafuegos que deja pasar el 1723 puede descartar el protocolo 47 sin quejarse, y la sesión queda a medio construir de una forma que parece un éxito.

Si el inicio de sesión funciona y no vuelve ningún paquete, suponga GRE primero y demuéstrelo después.

Comprobación 2: confirme el asistente en el núcleo del anfitrión

El seguimiento de conexiones no puede enlazar una conexión de control TCP con un flujo GRE sin un asistente. El módulo es nf_conntrack_pptp, vive en el núcleo del anfitrión, y cargarlo dentro de la imagen del contenedor no logra nada porque los módulos son comunes a todo el anfitrión. lsmod | grep nf_conntrack_pptp en el anfitrión Docker es la comprobación. Si falta, modprobe nf_conntrack_pptp lo carga para el núcleo en ejecución y no dice nada sobre el próximo arranque, así que añádalo también a la configuración del anfitrión.

Un módulo que desaparece al reiniciar se convierte en el mismo tique el mes que viene.

Comprobación 3: lea la política del núcleo que lo desactiva

Incluso con el módulo presente, los núcleos desde 4.7 ponen net.netfilter.nf_conntrack_helper en 0 por defecto, lo que desactiva la asignación automática de asistentes para cada protocolo. Ese valor por defecto es la razón por la que un módulo instalado correctamente sigue sin hacer nada: el código está ahí y la política dice que no se use. sysctl net.netfilter.nf_conntrack_helper informa del valor actual, y ponerlo en 1 en tiempo de ejecución vuelve a dejar disponible el asistente. Persista el valor mediante la configuración sysctl del anfitrión si el diseño lo permite.

La asignación automática permite que el tráfico cree expectativas de forma implícita, y por eso mismo cambió el valor por defecto. Limítela al anfitrión de confianza o use una regla explícita dirigida al asistente.

Comprobación 4: mire la ruta del contenedor por separado

Un asistente cargado no crea una ruta. El contenedor necesita un camino hacia el servidor PPTP, y el reenvío del anfitrión debe permitir GRE en ambas direcciones: iptables -L FORWARD -v -n muestra si se acepta el protocolo 47 y si los contadores se mueven. Las reglas masquerade de Docker traducen TCP y UDP, no el protocolo 47, así que un contenedor en puente puede necesitar una aceptación explícita de forward y, en algunos anfitriones, su propia regla de traducción. Confirme también que el contenedor tiene el soporte de dispositivos PPP que espera su imagen.

Lea los contadores en lugar del texto de la regla. Una regla que existe y no coincide con nada es decoración.

Comprobación 5: demuestre que GRE se sigue, luego decida sobre PPTP

Con el cliente en marcha, lea la tabla de seguimiento. Una entrada de control PPTP establecida más una entrada GRE relacionada significa que el asistente enlaza los flujos y que el fallo restante está en otro sitio. Una entrada de control sin entrada GRE significa que la carga se descarta o no se sigue, lo que le devuelve a las comprobaciones 2 y 3.

El propio PPTP es legado y MS-CHAPv2 es débil. Si el servidor también ofrece L2TP/IPsec, IKEv2 o WireGuard, pasar a uno de ellos elimina toda esta clase de problemas.

Donde PPTP tiene que quedarse, ejecutar el cliente en el anfitrión en lugar de dentro de un contenedor elimina una capa de NAT y filtrado, que suele ser la decisión más barata.