O PPTP en Docker autentícase pero non transporta tráfico

O cliente autentícase, PPP negocia un enderezo e entón nada se move. O ping falla, o navegador falla e o contedor parece conectado todo o tempo. Ese patrón non é un problema da táboa de rutas, porque os problemas de enrutamento adoitan romper tamén a conexión de control. É o camiño da carga, e en PPTP a carga é un protocolo distinto do que acaba de funcionar.

Cinco comprobacións, na orde que aforra máis tempo.

Comprobación 1: separe a canle de control da carga

PPTP autentícase sobre TCP 1723 e despois leva a carga PPP dentro de GRE, protocolo IP 47. GRE non é TCP nin UDP, así que cada regra que reenvía o porto de control non di nada sobre el. Un NAT ou cortalumes que deixa pasar o 1723 pode descartar o protocolo 47 sen queixarse, e a sesión queda a medio construír dun xeito que parece un éxito.

Se o inicio de sesión funciona e non volve ningún paquete, supoña GRE primeiro e demóstreo despois.

Comprobación 2: confirme o asistente no núcleo do anfitrión

O seguimento de conexións non pode ligar unha conexión de control TCP cun fluxo GRE sen un asistente. O módulo é nf_conntrack_pptp, vive no núcleo do anfitrión, e cargalo dentro da imaxe do contedor non logra nada porque os módulos son comúns a todo o anfitrión. lsmod | grep nf_conntrack_pptp no anfitrión Docker é a comprobación. Se falta, modprobe nf_conntrack_pptp cárgao para o núcleo en execución e non di nada sobre o próximo arranque, así que engádeo tamén á configuración do anfitrión.

Un módulo que desaparece ao reiniciar convértese no mesmo tícket o mes que vén.

Comprobación 3: lea a política do núcleo que o desactiva

Mesmo co módulo presente, os núcleos desde 4.7 poñen net.netfilter.nf_conntrack_helper en 0 por defecto, o que desactiva a asignación automática de asistentes para cada protocolo. Ese valor por defecto é a razón pola que un módulo instalado correctamente segue sen facer nada: o código está aí e a política di que non se use. sysctl net.netfilter.nf_conntrack_helper informa do valor actual, e poñelo en 1 en tempo de execución volve deixar dispoñible o asistente. Persista o valor mediante a configuración sysctl do anfitrión se o deseño o permite.

A asignación automática permite que o tráfico cree expectativas de forma implícita, e por iso mesmo cambiou o valor por defecto. Limíteo ao anfitrión de confianza ou use unha regra explícita dirixida ao asistente.

Comprobación 4: mire o camiño do contedor por separado

Un asistente cargado non crea unha ruta. O contedor necesita un camiño cara ao servidor PPTP, e o reenvío do anfitrión debe permitir GRE en ambas as direccións: iptables -L FORWARD -v -n mostra se se acepta o protocolo 47 e se os contadores se moven. As regras masquerade de Docker traducen TCP e UDP, non o protocolo 47, así que un contedor en ponte pode necesitar unha aceptación explícita de forward e, nalgúns anfitrións, a súa propia regra de tradución. Confirme tamén que o contedor ten o soporte de dispositivos PPP que espera a súa imaxe.

Lea os contadores en lugar do texto da regra. Unha regra que existe e non coincide con nada é decoración.

Comprobación 5: demostre que GRE se segue, logo decida sobre PPTP

Co cliente en marcha, lea a táboa de seguimento. Unha entrada de control PPTP establecida máis unha entrada GRE relacionada significan que o asistente liga os fluxos e que o fallo restante está noutro sitio. Unha entrada de control sen entrada GRE significa que a carga se descarta ou non se segue, o que o devolve ás comprobacións 2 e 3.

O propio PPTP é legado e MS-CHAPv2 é feble. Se o servidor tamén ofrece L2TP/IPsec, IKEv2 ou WireGuard, pasar a un deles elimina toda esta clase de problemas.

Onde o PPTP ten que quedar, executar o cliente no anfitrión en lugar de dentro dun contedor elimina unha capa de NAT e filtrado, que adoita ser a decisión máis barata.