Por que o PPTP e o L2TP/IPsec param antes do pedido do nome de usuário?

A ausência do pedido do nome de usuário é um presente de diagnóstico: o PPP ainda não arrancou, portanto a conta, a palavra-passe e a política de domínio ainda não foram consultadas. Numa ligação PPTP ou L2TP/IPsec o cliente só pede credenciais depois de o túnel existir e de o servidor ter iniciado uma sessão PPP. Tudo o que pode falhar antes desse momento é transporte, troca de chaves ou configuração do túnel, uma superfície muito menor do que «a VPN está avariada».

Um pedido ausente reduz a falha a três etapas

Anote a última etapa que teve sucesso visível, porque cada uma tem um dono diferente e uma correção diferente. Adivinhar as definições da conta enquanto está preso duas etapas antes é como se perde uma tarde.

Um cliente que expira sem pedido nunca obteve uma associação IPsec, portanto a falha está no IKE ou no facto de os seus pacotes chegarem sequer ao gateway. O que informa que está a verificar credenciais e depois cai chegou mais longe do que a mensagem sugere. Um pedido seguido de rejeição é autenticação PPP, e isso pertence a um artigo sobre a conta, não a este.

Primeira etapa: o protocolo que uma firewall descarta em silêncio

O PPTP precisa de TCP 1723 para o canal de controlo e do protocolo IP 47 para o caminho de dados, e os dois viajam separadamente. Muitas redes reencaminham 1723 e descartam o protocolo 47, o que produz um túnel que negoceia e depois não transporta absolutamente nada. Um router que faz NAT também precisa de uma passagem compatível com GRE, e um caminho de acesso apenas IPv6 não pode transportar PPTP em nenhuma configuração.

O L2TP sobre IPsec gasta a porta 500 no IKE e a porta 4500 na travessia de NAT, depois envolve o próprio tráfego L2TP em 1701, enquanto o ESP transporta a carga protegida assim que a associação existe. Permita as duas portas de controlo mas não o ESP, e obtém exatamente o sintoma do título: progresso visível e depois um cliente morto antes de qualquer diálogo de credenciais. Testar a partir de um hotspot de telemóvel é uma forma barata de separar um problema de cliente de um problema de caminho.

Segunda etapa: uma chave que não é a chave, uma proposta que não é oferecida

Uma chave pré-partilhada que não coincide falha depressa e em silêncio, e a versão habitual é uma chave que parece correta no ecrã enquanto traz uma quebra de linha colada ou um espaço no fim. Num cliente Linux o diálogo não é necessariamente a fonte da verdade: o plugin L2TP do NetworkManager guarda segredos em ficheiros sob /etc/ipsec.d/, e um ficheiro antigo por ligação que o /etc/ipsec.secrets ainda inclui será usado em vez do que acabou de escrever. Copie esse ficheiro para um local seguro, retire-o do caminho de inclusão e depois escreva a chave novamente à mão.

A outra metade desta etapa é a proposta. As duas pontas têm de concordar no mesmo conjunto de algoritmos da fase 1 — cifra, integridade e grupo Diffie-Hellman — e em transformações ESP correspondentes para a fase 2, senão a associação não se forma de todo. Um gateway que só oferece 3DES, SHA1 e MODP1024 recusará um cliente configurado para algoritmos mais fortes, e o respetivo registo nomeia a transformação recusada. O registo nomeia a divergência se o ler em vez de reiniciar o serviço outra vez. Em vez de copiar uma cadeia de algoritmos de um tópico de fórum, pergunte ao gateway que transformações vai realmente negociar: o ike-scan apontado ao seu endereço devolve as transformações que ele vai negociar. Se a única oferta for criptografia que a sua política já não permite, a correção pertence ao gateway, não a um downgrade do cliente.

No Windows a chave e o método de autenticação vivem no perfil de VPN, e uma divergência surge antes do pedido de credenciais e não depois. Quando o recetor é um Windows Server, confirme que a função de acesso remoto está instalada, que o certificado corresponde ao nome a que os clientes se ligam, e que nenhum filtro de portas é mais estreito do que os protocolos acima.

Terceira etapa: o túnel existe e o PPP nunca arranca

Quando o IKE termina e o pedido continua a não aparecer, olhe para o daemon do túnel em vez da firewall. O L2TP precisa de algo a escutar em UDP 1701 — xl2tpd ou kl2tpd em Linux, o serviço de acesso remoto no Windows — e um serviço instalado mas parado vê-se do lado do cliente exatamente como um pacote descartado. Verifique o ouvinte antes de reabrir regras que já verificou. Depois o PPP tem de negociar, e a primeira troca LCP é onde uma falha silenciosa costuma aterrar.

Uma armadilha nesta etapa não é de todo uma falha de rede: o Windows só permite uma ligação de um dado tipo de VPN de cada vez, por isso uma segunda tentativa devolve o erro 937, «outra ligação deste tipo está em uso». É uma regra local, e a forma de a contornar é outro dispositivo, outro tipo de túnel ou partilhar a única ligação que já existe.

Leia o registo na ordem das etapas em vez de adivinhar

Pare o cliente, volte a iniciá-lo e leia os componentes na ordem em que escrevem no registo. Ou seja, primeiro o daemon IPsec — strongSwan ou Libreswan, e o ipsec --version diz-lhe qual — depois o daemon L2TP, depois o pppd. Qualquer componente que tenha escrito por último antes da falha marca a etapa a investigar, porque tudo o que vem depois na sequência não correu de todo.

Verifique com uma ligação nova e não com uma sessão guardada, porque um cliente que se religa a partir da cache pode saltar partes da troca e reproduzir um resultado desatualizado. Confirme alcance, troca de chaves, túnel e PPP um de cada vez, nessa ordem. Então o pedido ausente deixa de ser um mistério e torna-se a segunda linha de uma lista que realmente se pode percorrer. Essa lista é também o que entrega à equipa de rede, a quem de outro modo se pediria que verificasse a firewall por causa de uma falha que vive num daemon não iniciado.