PPTP in Docker si autentica ma non trasporta traffico

Il client si autentica, PPP negozia un indirizzo e poi nulla si muove. Il ping fallisce, il browser fallisce e il container sembra connesso tutto il tempo. Questo schema non è un problema di tabella di routing, perché i problemi di routing di solito rompono anche la connessione di controllo. È il percorso del carico, e in PPTP il carico è un protocollo diverso da quello appena riuscito.

Cinque verifiche, nell'ordine che fa risparmiare più tempo.

Verifica 1: separa il canale di controllo dal carico

PPTP si autentica su TCP 1723 e poi trasporta il carico PPP dentro GRE, protocollo IP 47. GRE non è né TCP né UDP, quindi ogni regola che inoltra la porta di controllo non dice nulla al riguardo. Un NAT o un firewall che lascia passare 1723 può scartare il protocollo 47 senza lamentarsi, e la sessione resta a metà costruita in un modo che sembra un successo.

Se l'accesso funziona e nessun pacchetto torna indietro, supponi GRE prima e dimostralo dopo.

Verifica 2: conferma l'assistente nel kernel dell'host

Il tracciamento delle connessioni non può collegare una connessione di controllo TCP a un flusso GRE senza un assistente. Il modulo è nf_conntrack_pptp, vive nel kernel dell'host, e caricarlo nell'immagine del container non ottiene nulla perché i moduli valgono per tutto l'host. lsmod | grep nf_conntrack_pptp sull'host Docker è la verifica. Se manca, modprobe nf_conntrack_pptp lo carica per il kernel in esecuzione e non dice nulla sul prossimo avvio, quindi aggiungilo anche alla configurazione dell'host.

Un modulo che scompare al riavvio diventa lo stesso ticket il mese prossimo.

Verifica 3: leggi la policy del kernel che lo disattiva

Anche con il modulo presente, i kernel dal 4.7 impostano net.netfilter.nf_conntrack_helper a 0 per impostazione predefinita, il che disattiva l'assegnazione automatica degli assistenti per ogni protocollo. Questo valore predefinito è il motivo per cui un modulo installato correttamente non fa comunque nulla: il codice c'è e la policy dice di non usarlo. sysctl net.netfilter.nf_conntrack_helper riporta il valore corrente, e impostarlo a 1 in fase di esecuzione rende di nuovo disponibile l'assistente. Mantieni il valore tramite la configurazione sysctl dell'host se il progetto lo consente.

L'assegnazione automatica lascia che il traffico crei aspettative in modo implicito, ed è esattamente per questo che il valore predefinito è cambiato. Limitarla all'host fidato o usare una regola esplicita rivolta all'assistente.

Verifica 4: esamina il percorso del container separatamente

Un assistente caricato non crea una rotta. Il container ha bisogno di un percorso verso il server PPTP, e l'inoltro sull'host deve consentire GRE in entrambe le direzioni: iptables -L FORWARD -v -n mostra se il protocollo 47 è accettato e se i contatori si muovono. Le regole masquerade di Docker traducono TCP e UDP, non il protocollo 47, quindi un container in bridge può aver bisogno di un'accettazione forward esplicita e, su alcuni host, di una propria regola di traduzione. Verifica anche che il container abbia il supporto per dispositivi PPP che la sua immagine si aspetta.

Leggi i contatori invece del testo della regola. Una regola che esiste e non corrisponde a nulla è decorazione.

Verifica 5: dimostra che GRE è tracciato, poi decidi su PPTP

Con il client in esecuzione, leggi la tabella di tracciamento. Una voce di controllo PPTP stabilita più una voce GRE correlata significano che l'assistente collega i flussi e che il guasto rimanente è altrove. Una voce di controllo senza voce GRE significa che il carico viene scartato o non tracciato, il che ti riporta alle verifiche 2 e 3.

PPTP stesso è legacy e MS-CHAPv2 è debole. Se il server offre anche L2TP/IPsec, IKEv2 o WireGuard, passare a uno di questi elimina tutta questa classe di problemi.

Dove PPTP deve restare, eseguire il client sull'host invece che dentro un container elimina uno strato di NAT e filtraggio, che spesso è la decisione meno costosa.