PPTP conecta e depois trava atrás do Linux NAT: o auxiliar GRE

Alguém encaminha a 1723, o cliente chega ao servidor, a autenticação começa e então tudo para sem erro. A conclusão natural é senha errada, então a senha é digitada de novo três vezes. O encaminhamento estava bem e as credenciais estavam bem. O que quebrou é um segundo protocolo que o encaminhamento nunca cobriu, e um padrão do kernel que parou de ajudar com ele em silêncio.

O encaminhamento nunca foi o problema

Uma regra de encaminhamento de porta descreve tráfego TCP ou UDP. Não consegue descrever uma carga que troca para outro protocolo IP no meio de uma sessão, e o PPTP faz exatamente isso.

É por isso que a conexão parece saudável até o momento em que trava. A parte que uma regra de porta pode governar teve sucesso, e a parte que não pode governar é a parte que falhou.

TCP para controle, GRE para dados

A chamada é negociada sobre TCP 1723. Uma vez no ar, a carga passa para GRE, protocolo IP 47, que não carrega nenhum número de porta. Uma regra que se baseia em portas não tem o que comparar.

O que o GRE carrega é um identificador de chamada no cabeçalho, e o tradutor NAT precisa reescrever esse campo de forma consistente nos dois sentidos, ou as duas metades da sessão deixam de concordar. Uma direção reescrita e a outra não produz uma sessão que autentica e depois descarta cada pacote de dados. Essa é exatamente a forma do sintoma: sucesso, e depois silêncio.

GRE puro sem PPTP não precisa dessa reescrita, por isso um túnel GRE simples pode funcionar através de um roteador que falha para um cliente PPTP no mesmo caminho.

Quatro módulos e um sysctl que os desligou

Dois módulos cuidam do enquadramento, nf_conntrack_proto_gre e nf_nat_proto_gre. Mais dois cuidam do identificador de chamada, nf_conntrack_pptp e nf_nat_pptp. Carregar o último deles puxa os demais por dependências, então a lista de módulos deveria mostrar os quatro.

Instruções antigas usam um prefixo ip_ da era 2.6. Esses comandos podem parecer que executam sem carregar nada, então verifique a lista carregada em vez do status de saída.

Tê-los carregados não basta mais. Desde o Linux 4.7 o sysctl net.netfilter.nf_conntrack_helper vale 0 por padrão, o que desativa a atribuição automática de auxiliares para novos fluxos. Um roteador pode ter todos os módulos e ainda assim não traduzir nada. Verifique o valor efetivo antes de olhar a lista de módulos novamente.

Ou reative a atribuição automática globalmente, ou anexe o auxiliar aos fluxos que precisam dele e deixe todo o resto em paz:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

A segunda opção é a preferível. Ela limita o comportamento ao tráfego PPTP em vez de reativar a atribuição automática em todo o roteador.

Abrir um protocolo que não tem portas

Uma regra de firewall que permite a 1723 não diz nada sobre o protocolo 47. No firewalld, permita o protocolo na zona virada para o cliente. No iptables simples, aceite o protocolo gre na cadeia de entrada.

Depois capture dos dois lados. Pacotes que saem do cliente sem respostas chegando significam que o caminho de volta está filtrado, e isso é uma falha diferente de uma credencial rejeitada.

Depois de conectar, o limite de tamanho

O GRE insere um cabeçalho, e o PPP dentro dele acrescenta mais, então um link que funciona informa uma MTU bem abaixo de 1500. Respostas pequenas carregam e as grandes travam, o que parece um segundo problema não relacionado que aparece no momento em que o primeiro é resolvido.

Leia a MTU no adaptador PPP do cliente e concilie-a com o cálculo do próprio roteador em vez de baixar os números até algo funcionar. Pacotes de tamanho cheio que saem sem nada voltar apontam para esse limite, e não para a tradução.

Reparar o caminho devolve o usuário ao trabalho, e isso não faz do PPTP uma boa escolha. MS-CHAPv2 e RC4 estão obsoletos há muito tempo, então trate o carregamento dos módulos como uma correção temporária e planeje a migração para um protocolo mantido.