El PPTP a Docker s'autentica però no transporta trànsit

El client s'autentica, el PPP negocia una adreça i llavors res no es mou. El ping falla, el navegador falla i el contenidor sembla connectat tot el temps. Aquest patró no és un problema de taula d'encaminament, perquè els problemes d'encaminament normalment també trenquen la connexió de control. És el camí de la càrrega, i al PPTP la càrrega és un protocol diferent del que acaba de tenir èxit.

Cinc comprovacions, en l'ordre que estalvia més temps.

Comprovació 1: separeu el canal de control de la càrrega

El PPTP s'autentica sobre TCP 1723 i després porta la càrrega PPP dins de GRE, protocol IP 47. GRE no és ni TCP ni UDP, així que cada regla que reenvia el port de control no en diu res. Un NAT o tallafoc que deixa passar el 1723 pot deixar caure el protocol 47 sense queixar-se, i la sessió queda mig construïda d'una manera que sembla un èxit.

Si l'inici de sessió funciona i no torna cap paquet, assumiu GRE primer i demostreu-ho després.

Comprovació 2: confirmeu l'ajudant al nucli de l'amfitrió

El seguiment de connexions no pot enllaçar una connexió de control TCP amb un flux GRE sense un ajudant. El mòdul és nf_conntrack_pptp, viu al nucli de l'amfitrió, i carregar-lo dins de la imatge del contenidor no aconsegueix res perquè els mòduls són comuns a tot l'amfitrió. lsmod | grep nf_conntrack_pptp a l'amfitrió Docker és la comprovació. Si falta, modprobe nf_conntrack_pptp el carrega per al nucli en execució i no diu res sobre el proper arrencament, així que afegiu-lo també a la configuració de l'amfitrió.

Un mòdul que desapareix en reiniciar es converteix en el mateix tiquet el mes que ve.

Comprovació 3: llegiu la política del nucli que el desactiva

Fins i tot amb el mòdul present, els nuclis des del 4.7 posen net.netfilter.nf_conntrack_helper a 0 per defecte, cosa que desactiva l'assignació automàtica d'ajudants per a cada protocol. Aquest valor per defecte és la raó per la qual un mòdul instal·lat correctament encara no fa res: el codi hi és i la política diu que no s'utilitzi. sysctl net.netfilter.nf_conntrack_helper informa del valor actual, i posar-lo a 1 en temps d'execució torna a fer disponible l'ajudant. Persistiu el valor mitjançant la configuració sysctl de l'amfitrió si el disseny ho permet.

L'assignació automàtica permet que el trànsit creï expectatives implícitament, i per això mateix va canviar el valor per defecte. Limiteu-la a l'amfitrió de confiança o feu servir una regla explícita dirigida a l'ajudant.

Comprovació 4: mireu el camí del contenidor a part

Un ajudant carregat no crea cap ruta. El contenidor necessita un camí cap al servidor PPTP, i el reenviament de l'amfitrió ha de permetre GRE en totes dues direccions: iptables -L FORWARD -v -n mostra si s'accepta el protocol 47 i si els comptadors es mouen. Les regles masquerade de Docker tradueixen TCP i UDP, no el protocol 47, així que un contenidor en pont pot necessitar una acceptació explícita de forward i, en alguns amfitrions, la seva pròpia regla de traducció. Confirmeu també que el contenidor té el suport de dispositius PPP que la seva imatge espera.

Llegiu els comptadors en lloc del text de la regla. Una regla que existeix i no coincideix amb res és decoració.

Comprovació 5: demostreu que GRE es segueix, després decidiu sobre PPTP

Amb el client en marxa, llegiu la taula de seguiment. Una entrada de control PPTP establerta més una entrada GRE relacionada volen dir que l'ajudant enllaça els fluxos i que la falla restant és en un altre lloc. Una entrada de control sense entrada GRE vol dir que la càrrega es descarta o no es segueix, cosa que us torna a les comprovacions 2 i 3.

El PPTP mateix és llegat i MS-CHAPv2 és feble. Si el servidor també ofereix L2TP/IPsec, IKEv2 o WireGuard, passar a un d'ells elimina tota aquesta classe de problemes.

On el PPTP ha de quedar-se, executar el client a l'amfitrió en lloc de dins d'un contenidor elimina una capa de NAT i filtratge, que sovint és la decisió més barata.