Qual das etapas da VPN falhou: IPsec, o controle L2TP ou a autenticação PPP

Você mudou a senha e nada se mexeu, porque a falha nunca esteve no PPP. O L2TP/IPsec relata um único erro de conexão para cinco entregas bem diferentes, e cada entrega tem o seu próprio reparo. Trabalhe ao contrário: ache a última etapa que funcionou e altere só o que vem depois. A ordem abaixo também decide quais evidências você reúne primeiro.

Responda a quatro perguntas em ordem

Force uma tentativa nova, porque alguns clientes continuam mostrando o erro anterior até o perfil ser desconectado e reconectado. Depois responda: havia uma associação de segurança IPsec, apareceram uma conexão de controle L2TP e uma chamada, o PPP chegou a um veredito de autenticação e o IPCP entregou um endereço ao cliente? O primeiro não é a etapa que você corrige. Tudo depois dele não foi testado, então um nome de usuário recusado não prova nada quando nunca existiu associação.

Sincronize os relógios dos dois lados antes de comparar. Uma nova tentativa que limpou o IPsec e falhou no PPP parece uma única falha quando o cliente mostra apenas a mensagem final e o log do servidor ainda guarda a tentativa anterior. Leia por carimbo de tempo, não pela linha mais ruidosa.

Quando só tem a captura de tela do usuário, apoie-se na separação mais barata: uma chave pré-compartilhada errada e um xl2tpd que nunca responde produzem o mesmo texto na caixa do Windows, mas um exige um segredo trocado nos dois lados e o outro um daemon iniciado ou uma regra de firewall no próprio servidor. Um equipamento no meio não consegue descartar o 1701 interno depois que o IPsec em modo transporte o envolveu, então não procure um filtro de caminho que não existe.

O que cada camada realmente possui

O IPsec protege os pacotes entre os dois pares; o L2TP transporta uma sessão PPP dentro desse caminho protegido, e é por isso que o RFC 3193 especifica o modo transporte em vez de um túnel próprio. O rótulo do cliente diz L2TP, então o túnel e o login parecem um único mecanismo. Não são: a conexão de controle L2TP autentica as pontas do túnel onde a implantação a habilita, e o PPP autentica o usuário separadamente com CHAP, PAP ou MS-CHAPv2 conforme a política do servidor.

Essa separação explica os dois segredos que as pessoas continuam confundindo. Uma chave pré-compartilhada autentica os pares de IPsec. Um nome de usuário e uma senha identificam o usuário ao PPP. Redigitar o segredo compartilhado do Windows em um perfil que autentica com certificados não muda nada na etapa que falha, e editar a senha do PPP não pode fornecer um canal protegido ausente. A mesma contenção vale para a verificação de identidade: não desligue a identidade do par nem a validação do certificado para conseguir um túnel, porque então o que se conecta é o caminho, não o par.

A autenticação também não é o fim do PPP. Depois de aceitar o usuário, o IPCP negocia o endereço do cliente e as opções DNS e WINS que o servidor está disposto a entregar. Um cliente pode passar pelo CHAP ou MS-CHAPv2 e ainda terminar sem endereço, o que é uma falha dentro do PPP e não um problema de roteamento. O L2TP puro sem IPsec continua válido e desprotegido, então uma conexão bem-sucedida nunca prova que o tráfego está protegido; verifique o que o servidor exige, não o rótulo do cliente.

Decida pela primeira etapa ausente

Leia a tabela pelo primeiro item ausente, da esquerda para a direita. A coluna da direita é o único trabalho que vale a pena naquele momento; tudo à esquerda dela já está provado, e testar de novo queima a janela de indisponibilidade sem acrescentar informação.

Três linhas merecem aviso. A linha 1701 é onde os clientes Windows atrás de NAT costumam pousar: a associação se completa, depois nada chega, e a causa é a encapsulação, não uma senha ruim. A linha do IPCP é a que é mal lida como problema de rota, porque o Windows embrulha o endereço ausente no erro 720 e o ícone da bandeja só diz que a conexão falhou; essa falha fica depois da autenticação e antes do roteamento. A última linha não é falha de IPsec nenhuma, mesmo que o ícone diga desconectado.

Comandos que separam as camadas

Num servidor Linux com strongSwan, o swanctl --list-sas lista as associações estabelecidas com a identidade do par, e o ipsec statusall cobre hosts strongSwan e libreswan mais antigos. Por baixo, o ip xfrm state mostra as associações reais do núcleo, enquanto o ss -lunp | grep 1701 prova onde o xl2tpd está ligado. Execute o xl2tpd -D em primeiro plano para ver conexões de controle e chamadas surgirem, e ative a depuração do pppd em /etc/ppp/options.xl2tpd para ver o método oferecido e a resposta.

Quando os logs mostram autenticação bem-sucedida, a pergunta seguinte é se o IPCP foi concluído. Verifique se o ip range na seção [lns default] de /etc/xl2tpd/xl2tpd.conf ainda tem endereços livres, e se o /etc/ppp/options.xl2tpd realmente carrega ms-dns e ms-wins quando o cliente os espera. Um conjunto esgotado e uma opção DNS ausente parecem diferentes no cabo: o primeiro deixa o cliente sem endereço e com um 720, o segundo dá endereço mas nenhum resolvedor, então os nomes falham enquanto o ping para endereços crus funciona. Nenhum dos dois se conserta digitando a senha de novo.

No cliente, o plugin L2TP do NetworkManager escreve a conversa do pppd no diário, então o journalctl -u NetworkManager -b normalmente separa túnel de pé, autenticação recusada de nenhum túnel. No Windows, o Get-VpnConnection relata as configurações reais de autenticação do perfil, e os eventos RasClient em Application do Visualizador de Eventos nomeiam o componente que falha. Quando a caixa de diálogo é vaga demais, ative o netsh ras set tracing * enable.

As capturas exigem uma precaução. Com IPsec em modo transporte, o UDP 1701 interno vai cifrado, então uma captura na interface externa mostra ESP, ou UDP 4500 sob NAT-T, e nenhum L2TP. A falta de 1701 numa captura é esperada e não é prova de porta bloqueada; observe se os contadores de ESP ou de 4500 se movem.

NAT, MTU e rotas: onde a pilha engana você

O NAT quebra suposições antes de qualquer coisa ser autenticada. O ESP é um protocolo IP próprio, então um equipamento que traduz o descarta a menos que os pares encapsulem; é o que o UDP 4500 fornece. Num servidor Windows que ele mesmo está atrás de um roteador doméstico ou de um gateway NAT na nuvem, a etapa IPsec falha com o erro 789 até o AssumeUDPEncapsulationContextOnSendRule ser definido como 2 sob a chave PolicyAgent e a máquina reiniciar, e a falha continua indistinguível de uma porta fechada. Clientes atrás de NAT são mais fáceis: com um endereço público no servidor, o NAT-T sobre UDP 4500 os transporta e esse valor não entra na conta.

Depois que o PPP sobe, uma MTU com buraco negro imita um túnel morto: pacotes pequenos passam, um aperto de mão TLS ou o carregamento de uma página trava, e o cliente pode ainda exibir conectado. Baixe a MTU da interface ou fixe o MSS no gateway antes de culpar o servidor. O roteamento de túnel dividido é o outro impostor; uma sub-rede enviada com a máscara errada deixa o túnel saudável e uma aplicação inalcançável. Um nome de host privado acrescenta o seu próprio salto: se a consulta sai pelo resolvedor local, o nome não é resolvido antes de qualquer rota ser testada.

Lista de verificação antes de tocar nas credenciais

Percorra a lista em ordem e pare no primeiro item que falhar. Cada passo é barato, e cada um elimina toda uma classe de edições.

1. Confirme que a associação existe nos dois lados, emparelhada pela identidade do par e não por um rótulo de conectado.
2. Confirme que o UDP 1701 chega ao xl2tpd; uma associação sem chamada é a sua falha.
3. Leia o veredito do PPP e, se autenticou, o resultado do IPCP, antes de supor que a senha está errada.
4. Só agora digite as credenciais de novo no formato que o servidor espera, porque um prefixo de domínio muda a conta.
5. Se ainda falhar, capture os dois lados com carimbos de tempo alinhados e compare etapa por etapa.

Parar no segundo passo significa um problema de caminho ou de encapsulação, e nenhuma edição da senha vai mover isso. Parar no terceiro passo significa que o log já nomeia o método ou o conjunto de endereços a corrigir. De um jeito ou de outro, a próxima mudança é uma que você consegue justificar, e você para de girar por configurações que nunca estiveram envolvidas.