Falhas de escrita GRE no pptpd não são problema de senha

Falha de escrita GRE no log, e o primeiro instinto é redefinir a senha do usuário. Esse instinto está quase sempre errado. Essas mensagens descrevem o caminho dos dados, não a verificação de credenciais: o cliente pode ter se autenticado com sucesso e depois travado no estágio em que se registra na rede. Duas mensagens diferentes apontam para duas falhas diferentes, e nenhuma se resolve com uma nova senha.

Duas mensagens, duas falhas diferentes

Uma falha de leitura significa que os pacotes GRE nunca chegam ao daemon ou são descartados na entrada. A conexão de controle pode parecer perfeitamente saudável enquanto nada atravessa o caminho dos dados. A autenticação é a única coisa que comprovadamente funcionou.

Uma falha de escrita geralmente significa que a sessão negociou algo que o kernel ou o cliente não conseguem usar. O canal de controle foi concluído, e as opções acordadas nessa troca não correspondem ao que os endpoints realmente podem fazer. É uma divergência de configuração, não um evento de autenticação.

Leia qual das duas aparece antes de mudar qualquer coisa. Elas levam a camadas diferentes, e tratá-las como um único sintoma é a razão pela qual o mesmo servidor é corrigido duas vezes por motivos não relacionados. A linha de log é o único diagnóstico gratuito que você obtém.

O protocolo 47 não é a porta 47

O PPTP usa TCP 1723 para estabelecer a chamada e GRE para transportar a carga útil. GRE é o protocolo IP 47, não um número de porta, então uma regra de firewall que abre a porta 47 não permite nada útil.

Um roteador no caminho precisa de um recurso de passthrough PPTP ou de uma permissão GRE explícita. Sem isso, o handshake TCP termina e o túnel nunca transporta um pacote, o que produz exatamente a falha de leitura acima. Regras da porta 47 em um firewall são a tarde mais desperdiçada deste protocolo.

Observe os dois sentidos ao mesmo tempo no servidor em vez de adivinhar qual lado descarta o tráfego: tcpdump -ni any port 1723 or proto gre.

Se 1723 mostra o estabelecimento da chamada enquanto GRE permanece silencioso, o bloqueio está acima do host. Se GRE chega e o daemon ainda falha, o problema é local e as opções são o próximo lugar a examinar.

Permita GRE onde o host realmente encaminha

Inserir uma regra forward para GRE é um teste razoável em um host que encaminha tráfego de túnel, e não é uma política. Uma regra de teste que aceita tudo de um protocolo é um diagnóstico, não um projeto. Deixe-a por tempo suficiente para aprender algo e depois substitua-a por uma regra limitada.

Adicione uma regra input para os pacotes endereçados ao próprio servidor, porque a cadeia forward não os vê. Depois observe os contadores da regra antes e depois de uma tentativa de conexão, o que lhe diz se os pacotes chegam.

Torne a regra persistente pelo serviço de firewall da distribuição em vez de executá-la novamente após cada reinicialização. Em um host nftables, faça ip protocol gre coincidir tanto na cadeia input quanto na forward.

Confirme que o módulo ppp_generic também está carregado e verifique se o rastreamento de conexões descarta o sentido de retorno. Ambos produzem falhas que parecem um problema de firewall e não são. Um módulo de kernel ausente parece exatamente um protocolo bloqueado até você verificar.

Ajuste as opções ao cliente que você realmente tem

A correção do outro relatório está em /etc/ppp/pptpd-options, onde a receita recusa PAP, CHAP e MSCHAP, comenta as linhas require correspondentes e mantém MPPE com estado. Essa receita foi escrita para uma mistura de clientes, e copiá-la às cegas quebra o caso comum. Leia as linhas de recusa como uma afirmação sobre quais clientes o autor tinha, não como uma recomendação.

Um cliente Windows normalmente precisa de MS-CHAPv2 com MPPE-128. Mantenha esses requisitos e remova apenas as opções que o cliente realmente não consegue negociar.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Desativar a criptografia para que uma conexão funcione é uma degradação, não um reparo. Teste essa variante em um link de laboratório e depois restaure a criptografia antes que o serviço enfrente clientes reais. A conexão que funciona de forma insegura é pior que a que falha com honestidade.

Leia o número de erro do cliente

O código numérico do cliente estreita o estágio mais rápido que o log do servidor. Leia-o antes de ler qualquer outra coisa. 691 significa que as credenciais foram recusadas, 721 significa que o servidor nunca respondeu e 619 significa que a conexão caiu. Dois minutos com o número economizam uma hora com a configuração.

Compare esse código com o log do servidor antes de editar qualquer coisa, e teste novamente com o mesmo cliente após cada alteração. Caso contrário, uma segunda falha se esconde atrás da primeira e a correção parece ineficaz.

Quando o login tem sucesso e nenhum tráfego se move, GRE continua sendo o suspeito. Esse é o momento de voltar à captura em vez do armazenamento de credenciais.