Passthrough de PPTP em falta: corrija o erro 807 do Windows VPN

Encaminhar o TCP 1723 abre muitas vezes a primeira parte do PPTP e deixa o resto quebrado, por isso o Windows continua a devolver o erro 807 na tentativa. O próximo impulso é acrescentar uma regra para a porta 47, e é precisamente esse passo que desperdiça uma tarde: o GRE é um número de protocolo no cabeçalho IP, não uma porta que uma tabela de encaminhamento possa corresponder. Enquanto o router não deixar passar o protocolo 47 e o ligar à mesma chamada, o túnel não pode começar. As secções abaixo separam os dois canais e depois testam-nos um de cada vez.

Uma tabela de portas não tem linha para um número de protocolo

O PPTP usa duas conversas que falham de formas diferentes. A do TCP 1723 inicia a chamada, transmite a informação da ligação e fecha-a quando o utilizador se desliga. O lado da carga útil corre dentro do GRE, que o cabeçalho IP marca com o número de protocolo 47, e dentro desse túnel o PPP negocia a ligação enquanto o MS-CHAPv2 verifica as credenciais.

Como o GRE não transporta cabeçalho de transporte, não expõe portas, por isso uma regra escrita para portas não tem nada a corresponder. Um router que encaminha o 1723 cria um mapeamento para essa sessão TCP e fica por aí. O firmware que trata da segunda metade chama à função passthrough de PPTP ou PPTP ALG, e alguns firmwares não oferecem nenhuma das duas e nunca mencionam a lacuna. A etiqueta da caixa de verificação importa menos do que saber se o protocolo 47 é reconhecido ou não.

O que o Windows relata quando o caminho de dados morre

O erro 807 diz que a ligação não pôde ser concluída, o que na prática significa que a chamada chegou ao servidor e o canal de dados não subiu. É um veredicto sobre o transporte, não sobre a conta. O erro 691 é o que aponta para as credenciais ou para uma incompatibilidade do protocolo de autenticação, por isso manda-o para outro sítio completamente diferente.

Trabalhe o transporte antes de tocar na palavra-passe. Mudar as credenciais para perseguir o 807 deixa a falha real no lugar e torna a tentativa seguinte mais difícil de ler.

Porque é que um segundo cliente quebra um túnel que funciona

Sem portas que os distingam, um dispositivo NAT não consegue separar dois clientes PPTP como separa duas sessões HTTPS. Por isso muitos equipamentos domésticos permitem apenas uma chamada PPTP e seguem-na pelo endereço de origem. Um portátil que funcionava sozinho deixa de concluir assim que uma segunda máquina marca, e do lado do cliente a falha parece aleatória. Esse padrão pertence ao firmware, e nenhuma alteração de perfil o vai mudar.

Observe a tabela de ligações enquanto os dois clientes marcam. Se só o primeiro anfitrião detém alguma vez um mapeamento, o router chegou ao limite do que suporta e nenhuma definição do cliente o vai mover.

Prove qual metade está a falhar

Confirme que o TCP 1723 chega antes de alterar seja o que for no router, porque essa resposta decide qual metade está a testar. Execute estes comandos a partir do cliente Windows contra o seu próprio nome de servidor. O primeiro imprime se a porta respondeu, e o segundo marca sem diálogo, o que torna comparáveis as tentativas repetidas.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Um resultado verdadeiro no teste da porta significa que o canal de controlo está aberto e que o GRE é o suspeito restante. Um resultado falso significa que o encaminhamento, um filtro ou a passagem estão quebrados, e nenhuma alteração no GRE o vai salvar. O lado dos dados tem de ser vigiado onde é visível, no servidor ou no router.

tcpdump -ni any proto 47

O equivalente no Wireshark é o filtro de visualização ip proto 47, que é mais fácil de entregar a alguém que não está à vontade numa linha de comandos. Um GRE que chega sem que nada saia em resposta significa que o caminho de regresso precisa de correção.

O que realmente corrige o erro

Onde o router expõe a definição, ative o passthrough de PPTP ou permita explicitamente o protocolo 47 em firmware que aceite regras. No RouterOS a regra de encaminhamento corresponde ao protocolo diretamente, algo que um encaminhamento baseado em portas nunca poderia fazer. O firmware de consumo costuma esconder a mesma decisão atrás de uma caixa de verificação, às vezes nas definições de segurança e não no encaminhamento de portas. Se não existir esse controlo, nada no cliente o compensa.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Substituir o PPTP é a outra opção e muitas vezes a mais barata. Um router que termina ele próprio a VPN evita o NAT duplo para clientes de entrada, e um protocolo que um NAT baseado em portas já trata não precisa de passthrough nenhum: OpenVPN sobre UDP, SSTP sobre TCP 443 ou L2TP/IPsec com NAT-T que envolve o ESP em UDP 4500. O PPTP também depende do MS-CHAPv2, cujas fraquezas documentadas o tornam uma má escolha para uma implementação nova mesmo depois de o erro desaparecer.

Anote qual regra fez a diferença, porque o mesmo local vai encontrar o mesmo limite quando o segundo utilizador pedir acesso. Uma correção ao nível do protocolo pertence às notas de rede, onde o próximo técnico vai olhar.