PPTP no Docker autentica mas não transporta tráfego

O cliente autentica, o PPP negocia um endereço e depois nada se move. O ping falha, o navegador falha e o contentor parece ligado o tempo todo. Esse padrão não é um problema de tabela de rotas, porque os problemas de encaminhamento normalmente quebram também a ligação de controlo. É o caminho da carga, e no PPTP a carga é um protocolo diferente do que acabou de funcionar.

Cinco verificações, na ordem que poupa mais tempo.

Verificação 1: separe o canal de controlo da carga

O PPTP autentica sobre TCP 1723 e depois transporta a carga PPP dentro de GRE, protocolo IP 47. GRE não é TCP nem UDP, por isso cada regra que encaminha a porta de controlo não diz nada sobre ele. Um NAT ou firewall que deixa passar o 1723 pode descartar o protocolo 47 sem se queixar, e a sessão fica meio construída de uma forma que parece um sucesso.

Se o início de sessão funciona e não volta nenhum pacote, assuma GRE primeiro e prove-o depois.

Verificação 2: confirme o assistente no kernel do anfitrião

O rastreio de ligações não consegue associar uma ligação de controlo TCP a um fluxo GRE sem um assistente. O módulo é nf_conntrack_pptp, vive no kernel do anfitrião, e carregá-lo dentro da imagem do contentor não consegue nada porque os módulos são comuns a todo o anfitrião. lsmod | grep nf_conntrack_pptp no anfitrião Docker é a verificação. Se faltar, modprobe nf_conntrack_pptp carrega-o para o kernel em execução e não diz nada sobre o próximo arranque, por isso acrescente-o também à configuração do anfitrião.

Um módulo que desaparece no reinício torna-se o mesmo ticket no mês seguinte.

Verificação 3: leia a política do kernel que o desativa

Mesmo com o módulo presente, os kernels desde 4.7 colocam net.netfilter.nf_conntrack_helper em 0 por omissão, o que desativa a atribuição automática de assistentes para cada protocolo. Esse valor por omissão é a razão pela qual um módulo instalado corretamente continua a não fazer nada: o código está lá e a política diz para não o usar. sysctl net.netfilter.nf_conntrack_helper informa o valor atual, e colocá-lo em 1 em tempo de execução torna o assistente novamente disponível. Persista o valor através da configuração sysctl do anfitrião se o desenho o permitir.

A atribuição automática permite que o tráfego crie expectativas de forma implícita, e é exatamente por isso que o valor por omissão mudou. Limite-a ao anfitrião de confiança ou use uma regra explícita dirigida ao assistente.

Verificação 4: veja o caminho do contentor em separado

Um assistente carregado não cria uma rota. O contentor precisa de um caminho para o servidor PPTP, e o encaminhamento no anfitrião tem de permitir GRE nos dois sentidos: iptables -L FORWARD -v -n mostra se o protocolo 47 é aceite e se os contadores se movem. As regras masquerade do Docker traduzem TCP e UDP, não o protocolo 47, por isso um contentor em ponte pode precisar de uma aceitação forward explícita e, em alguns anfitriões, da sua própria regra de tradução. Confirme também que o contentor tem o suporte de dispositivos PPP que a sua imagem espera.

Leia os contadores em vez do texto da regra. Uma regra que existe e não corresponde a nada é decoração.

Verificação 5: prove que GRE é rastreado, depois decida sobre PPTP

Com o cliente a correr, leia a tabela de rastreio. Uma entrada de controlo PPTP estabelecida mais uma entrada GRE relacionada significam que o assistente liga os fluxos e que a falha restante está noutro lugar. Uma entrada de controlo sem entrada GRE significa que a carga é descartada ou não é rastreada, o que o devolve às verificações 2 e 3.

O próprio PPTP é legado e o MS-CHAPv2 é fraco. Se o servidor também oferece L2TP/IPsec, IKEv2 ou WireGuard, passar para um deles elimina toda esta classe de problemas.

Onde o PPTP tem de ficar, executar o cliente no anfitrião em vez de dentro de um contentor elimina uma camada de NAT e filtragem, que muitas vezes é a decisão mais barata.