LCP encerrado pelo par no PPTP: ative o MPPE primeiro

O link autentica, o cliente relata conectado e, um segundo depois, o log fecha com LCP encerrado pelo par. Essa linha vem da negociação PPP dentro do túnel GRE, então o transporte já funcionava e as duas pontas discordavam sobre as opções do link. Senhas e endereços de servidor costumam ser inocentes aqui. A política de criptografia é a primeira coisa a comparar e, no Linux, o arquivo de par do pppd é o primeiro lugar a olhar.

O que a falha de LCP diz sobre o estágio PPP

O PPTP embrulha o PPP dentro do GRE: a conexão de controle TCP 1723 prepara a chamada, o GRE carrega o payload e então o LCP negocia opções como o protocolo de autenticação, a compressão e o MPPE. O par encerra o LCP quando uma opção obrigatória não é aceitável do seu lado. Um log em que a troca CHAP ou MSCHAPv2 se completa e o LCP termina logo depois é uma rejeição de política, não uma falha de alcance. Se o túnel nunca chega à negociação, inspecione o pppd e seu plugin antes de ler a linha de LCP.

Duas pré-condições passam facilmente despercebidas. O binário pppd precisa existir e o plugin PPTP indicado no arquivo de par precisa estar instalado; um pacote ausente encerra a chamada antes que qualquer opção seja discutida.

Ative o MPPE no lado que o exige

A decisão real é qual extremidade possui a política de criptografia. Um cliente pode oferecer MPPE, exigi-lo ou recusá-lo, e o servidor faz a mesma escolha. Quando ambos o exigem, o link sobe; quando um exige e o outro recusa, o LCP termina.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Carregue o módulo com modprobe ppp_mppe antes de discar, porque require-mppe-128 falha sem ele. No Windows, o controle equivalente é a aba de segurança da entrada VPN, onde o cliente precisa ser instruído a exigir criptografia em vez de aceitar o que o servidor oferecer. Se o servidor ainda encerra o LCP, pergunte ao operador se o MPPE é obrigatório, opcional ou desativado, já que um cliente não pode negociar uma proteção que o servidor recusa. Desligar a criptografia para a mensagem sumir é a direção errada: remove a única proteção que este protocolo tem.

Salve o arquivo de par que funciona antes de editá-lo. Uma linha require-mppe digitada errado reproduz a mesma falha genérica de LCP e o devolve ao início.

Leia o log do próprio pppd em vez do applet

Os applets de desktop mostram a desconexão e escondem o motivo, então leia o relato do daemon sobre uma tentativa. Em sistemas com systemd a mensagem vai para o journal; configurações mais antigas escrevem nos arquivos de log tradicionais.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Procure numa janela em torno de uma única chamada em vez de um dia inteiro de reconexões, para que a opção rejeitada seja fácil de ver. O pppd costuma nomear a opção e a resposta do par, o que diz se você deve mudar sua própria proposta ou pedir ao lado do servidor que relaxe o requisito. Mantenha as tentativas com carimbo de tempo, porque comparar dois logs só é útil quando você sabe quais linhas pertencem a qual chamada. Quando não aparece nenhuma troca de LCP, a falha está mais acima na cadeia e o MPPE não é o suspeito.

Mantenha a correção entre reconexões: nomes de hooks e MTU

Quando o link se mantém, dois detalhes decidem se ele sobrevive a uma reconexão. Os hooks ficam em /etc/ppp/ip-up.d e /etc/network/if-up.d, e o run-parts processa ambos os diretórios, com um filtro de nomes de arquivo que rejeita tudo o que contém um ponto. Por isso um script chamado set-pptp.sh é ignorado, enquanto set-pptp é executado. Verifique o nome antes de depurar o conteúdo do script e, depois, defina a MTU menor de dentro desse hook para que cada nova interface ppp a herde sem um comando manual.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Para encerrar uma sessão de propósito, mire no pid registrado pelo pppd em vez de casar nomes de processos, porque matar tudo o que contém ppp também derruba links não relacionados. O PPTP está obsoleto e o MS-CHAPv2 é fraco, então trate essas verificações como manutenção de um link que precisa continuar funcionando, não como motivo para implantar PPTP em qualquer lugar novo.