PPTP através de um hotspot: TCP 1723 é só metade

Percorra as verificações em ordem: se a conexão de controle abre, se o GRE sobrevive ao caminho, se o servidor aceita a chamada e se a autenticação termina. Um cliente PPTP precisa tanto de uma sessão TCP em 1723 quanto de um caminho GRE que carregue os dados, e um hotspot pode deixar passar um e descartar o outro. Fazer isso em ordem diz qual fronteira investigar em vez de adivinhar. Os números de erro do Windows não fazem isso por você.

GRE é o protocolo IP 47. Não é a porta 47 do TCP nem do UDP, e essa distinção explica a maior parte da confusão sobre firewalls.

Dois caminhos, uma conexão

A conexão de controle é uma sessão TCP comum para a porta de destino 1723, que a maioria das redes permite sem reclamações. O caminho de dados é GRE, protocolo 47, e um firewall que permite o primeiro pode ignorar completamente o segundo. Essa combinação produz um cliente que parece iniciar e depois não carrega nada, um sintoma bem menos informativo do que uma conexão recusada. Teste os dois caminhos separadamente antes de concluir qualquer coisa sobre a operadora.

A tradução acrescenta seu próprio requisito. Gateways que compartilham portas costumam precisar de um ALG que entenda PPTP para reescrever os identificadores de chamada junto com os endereços, e um sem isso pode estragar a sessão de formas que parecem perda de pacotes. Esse comportamento é comum, mas depende da implementação, então trate qualquer limite de fornecedor como exemplo e não como propriedade de todo hotspot.

O hotspot acrescenta duas fronteiras a mais

O tráfego do cliente geralmente atravessa o NAT de compartilhamento do próprio telefone e depois uma tradução no nível da operadora antes de chegar ao servidor. Uma regra no roteador do escritório não pode consertar um dispositivo intermediário que pertence a outra pessoa, e é por isso que o encaminhamento de portas do lado de casa raramente ajuda. Um cliente de saída também não precisa de uma porta de entrada aberta; as respostas a uma conexão traduzida voltam pelo estado que o gateway criou. Um servidor hospedado atrás de NAT tem um conjunto de requisitos completamente diferente.

Um item de menu rotulado como PPTP passthrough, onde existir, determina como esse dispositivo trata este protocolo. Não é a mesma função que hospedar uma VPN no telefone ou encaminhar cada protocolo sem condições, e ativá-lo não é uma permissão geral para deixar passar GRE.

Leia o 807 como uma interrupção, não como um veredito

O Windows relata o 807 como uma conexão interrompida, o que descreve o resultado e não uma causa. Sua tabela de erros trata o 806 separadamente como a categoria relacionada ao GRE, e essa diferença vale a pena conhecer antes de construir uma teoria. Nenhum dos dois números revela se a operadora filtrou o protocolo 47, se o servidor ficou sem capacidade ou se as credenciais estavam certas. O erro diz que a sessão terminou; o caminho diz onde.

Um teste de navegador que funciona no hotspot prova apenas que um caminho de aplicação comum funciona. Não diz nada sobre GRE.

Isole o estágio que falhou

Mantenha o notebook, o servidor e o perfil fixos, e troque apenas a rede de acesso por outra aprovada. Se o resultado mudar, capture as trocas TCP e GRE nas fronteiras que você controla e encontre o estágio mais inicial que nunca acontece: estabelecimento do controle, preparação da chamada, entrega de dados ou autenticação PPP. Cada um deixa uma assinatura diferente em uma captura. Comparar uma rede que funciona com uma que falha é muito mais informativo do que reler o texto do erro.

Tudo isso diagnostica uma implantação que já existe. Não é argumento para montar um novo serviço PPTP, e o protocolo não se contorna negociando: instalar um cliente diferente não faz um servidor inalterado falar outra coisa.

Para acesso contínuo, combine uma migração suportada com quem possui a VPN. A lista de verificação termina com uma decisão e não com um paliativo.