Erro PPTP 800 contra 812 e quedas após um minuto

Três mensagens de erro de um mesmo cliente PPTP costumam descrever três falhas diferentes. O erro 800 significa que o túnel nunca se formou, o erro 812 significa que o servidor recusou o método de autenticação, e uma queda após um minuto é um temporizador de keepalive que decide que um par saudável desapareceu. Cada etapa falha por sua própria razão, então cada uma precisa da sua própria verificação.

O erro 800 significa que o túnel nunca se formou

O Windows gera o erro 800 quando não consegue construir o túnel de modo algum, e o texto sobre servidor inalcançável ou parâmetros de segurança inadequados é um resumo, não um diagnóstico. O PPTP precisa de duas coisas separadas da rede antes de qualquer credencial ser examinada. O TCP 1723 transporta o canal de controle, e o protocolo IP 47, GRE, transporta a carga encapsulada.

Teste esse caminho externo de fora da sua própria LAN, porque uma conexão que funciona no escritório não prova nada sobre a borda:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Se o 1723 responde e a captura fica vazia enquanto o cliente tenta conectar, o caminho está descartando o protocolo 47. Um roteador com o 1723 encaminhado mas o passthrough PPTP desligado produz exatamente esse padrão: o aperto de mão TCP se completa, depois os pacotes GRE desaparecem, então a falha parece um problema de credenciais embora nenhuma tentativa de login tenha sido feita.

Aponte o encaminhamento para o endereço LAN atual do servidor, ative o passthrough PPTP onde o roteador o oferece e tente novamente do mesmo ponto externo. Quando o GRE é filtrado mais acima e você não pode mudar isso, SSTP sobre TCP 443 ou L2TP/IPsec sobre UDP 500 e 4500 tem mais chance do que qualquer mudança que você possa fazer no lado do Windows.

O erro 812 é o servidor recusando seu método de autenticação

O erro 812 volta depois que o túnel está no ar, por isso parece um problema de senha. O servidor recusa o método de autenticação negociado para a conexão, não necessariamente a senha em si. No cliente, abra a entrada VPN, vá à aba de segurança, defina o tipo como Point-to-Point Tunneling Protocol, escolha a lista explícita de protocolos e marque Microsoft CHAP versão 2.

Você pode ler o ajuste atual sem clicar pela caixa de diálogo:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Um servidor que exige MS-CHAP v2 recusa um cliente deixado em PAP ou em um tipo automático que negocia algo mais fraco, e o erro chega antes de qualquer senha de usuário ser avaliada. O formato da conta é a outra metade da mesma recusa. Num caso, o Windows enviou uma identidade de conta Microsoft na forma MicrosoftAccount\[email protected] enquanto o servidor queria uma conta local ou de domínio. Digitar SERVERNAME\username disse ao Windows qual repositório de contas consultar e eliminou o erro. Digite o nome à mão em vez de deixar uma credencial salva repetir um formato anterior.

As quedas após um minuto são uma decisão de keepalive

Quando o túnel conecta, passa um pouco de tráfego e depois desconecta, olhe o comportamento de eco LCP do servidor antes de mexer no cliente. O daemon pede periodicamente ao par que confirme que ainda está lá. Se chegarem poucas respostas dentro do orçamento configurado, a sessão é derrubada mesmo que o usuário ainda tenha um link funcional.

Num servidor Linux pptpd esses valores ficam em /etc/ppp/options.pptpd, e o reparo habitual é ampliar o orçamento em vez de encurtar o intervalo:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Trinta falhas num intervalo de cinco segundos perdoam uma breve parada em vez de declarar o par desaparecido. Reduzir a contagem para um ou dois transforma o jitter normal num caminho traduzido em desconexão mais ou menos a cada minuto. Se o seu servidor é Windows RRAS em vez de pptpd, veja o tempo limite da sessão PPP e a política de desconexão por inatividade. Esses ficam noutro lugar, e editar um arquivo pppd que não existe não vai mudar nada.

Sub-redes sobrepostas quebram o caminho de dados

Um túnel PPTP pode autenticar de forma limpa e ainda assim não alcançar nada quando os dois lados usam a mesma faixa privada, por exemplo 192.168.1.0/24 no escritório e em casa. O cliente não consegue dizer a qual host um determinado endereço se refere, e algumas pilhas recusam instalar a rota de todo em vez de escolher uma.

Trate isso como um defeito de projeto e renumere um lado, ou dê ao cliente uma faixa de acesso traduzida de propósito. Depurar o cliente PPTP não conserta um espaço de endereços que existe duas vezes, e o sintoma vai continuar parecendo uma queda aleatória.

Comece pela etapa que falhou: GRE para o 800, o método e a string de conta para o 812, ajustes de eco para um túnel que morre segundo o horário.