O túnel dividido do PPTP não funciona: corrija primeiro o caminho GRE

Observe uma conexão PPTP subir e é fácil acreditar que a parte difícil está pronta: o cliente autentica-se, aparece um adaptador ppp0 ou WAN Miniport e a janela de estado fica verde. Depois o primeiro pedido a um host interno expira e a culpa é do perfil. Na prática há duas camadas independentes a limpar: o transporte externo que leva TCP 1723 e GRE, e a política interna que decide quais destinos usam a interface PPP. Um estado verde só prova que a primeira camada negociou; sobre a segunda não diz nada.

Siga o cliente do perfil até ao socket de controlo

Abra o registo do cliente e encontre o ponto em que contacta o servidor. O PPTP abre primeiro uma ligação TCP à porta 1723 e negoceia os parâmetros do túnel nesse canal. Se este passo falhar, nada depois importa, e o erro costuma indicar o endereço do servidor ou um tempo limite.

Confirme a ligação de controlo na rede antes de tocar em qualquer rota. No cliente ou numa porta espelho, capture TCP 1723 para uma tentativa de ligação:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Um aperto de mão concluído e uma sessão estabelecida significam que o canal de controlo externo funciona. Um SYN que nunca recebe SYN-ACK aponta para uma firewall, um endereço de servidor errado ou um fornecedor que filtra a porta. Um aperto de mão seguido de reinício imediato costuma significar que o servidor rejeitou as credenciais ou o tipo de túnel.

O GRE é um segundo protocolo, não uma porta

O PPTP transporta a carga PPP dentro de GRE melhorado, o protocolo IP 47, que não tem número de porta que um router possa seguir. Por isso uma regra que permite TCP 1723 ainda pode deixar o túnel sem caminho de dados. Os dispositivos NAT com estado precisam de compreender o identificador de chamada dentro do GRE para mapear as respostas, e muitos não o fazem. A especificação do PPTP mantém o canal de controlo e a carga GRE como peças separadas, e o seu plano de testes também deve fazê-lo.

Vigie o protocolo 47 na mesma captura e depois compare o que sai com o que volta:

sudo tcpdump -ni any 'proto gre' -c 20

Pacotes que saem sem respostas, enquanto o TCP 1723 se mantém saudável, são a assinatura clássica de GRE bloqueado. O passthrough de PPTP num router doméstico é uma função desse firmware concreto, por isso uma rede de hotel que funciona não prova nada sobre a seguinte. Se o router não oferece passthrough e não o pode alterar, o problema é a escolha do protocolo, não a tabela de rotas.

Prove que o túnel move um pacote

Quando o GRE flui, a negociação PPP atribui um endereço à interface do cliente. Leia a atribuição em vez de a supor:

ip -4 addr show ppp0

Faça ping ao endereço do par apresentado como destino da ligação ponto a ponto. Uma resposta nesta fase prova que o caminho encapsulado funciona de ponta a ponta e que o servidor responde dentro do túnel. Se o par responde mas os hosts internos não, o transporte externo está bem e a falha mudou-se para dentro.

Faça isto antes de acrescentar qualquer rota dividida. Uma alteração de rota feita com o transporte quebrado cria uma segunda variável e esconde a primeira.

Escreva a política dividida, DNS incluído

O encaminhamento dividido é uma lista de decisões, não uma caixa de verificação. Cada prefixo privado que deve atravessar o túnel precisa de uma rota pela interface PPP, e cada prefixo que deve ficar local tem de estar ausente dela. Uma rota para uma sub-rede de aplicação sem a rota correspondente para o seu resolvedor privado é uma forma comum de criar uma falha que parece uma aplicação avariada.

Verifique a decisão que o kernel toma para um endereço de cada categoria:

ip route get 10.20.5.10
ip route get 203.0.113.25

A primeira deve indicar ppp0, a segunda o gateway normal. Se ambas indicarem a mesma interface, a política não está nada dividida. Acrescente o endereço do próprio servidor DNS à lista tunelizada, senão a resolução de nomes para hosts internos sai pelo resolvedor local e não devolve nada útil.

Uma verificação repetível em cinco passos

Execute as camadas por ordem e pare na primeira que falhar: canal de controlo, visibilidade do GRE, resposta do par PPP, rota dividida para um endereço interno e um pedido de aplicação pelo túnel. Cada passo tem o seu próprio comando, por isso uma falha é atribuível em vez de misteriosa.

Uma versão compacta para um cliente Linux é assim:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

No Windows aplica-se a mesma ordem com route print e o estado do adaptador mostrado no cliente. O PPTP é um protocolo legado, e se o servidor oferece SSTP ou IKEv2, mudar costuma ser um melhor uso do tempo do que afinar um caminho que depende de o protocolo 47 passar em cada salto. Verifique o certificado e o contrato de autenticação do substituto em vez de copiar um perfil antigo para uma versão nova.