L2TP/IPsec falha: isole o IPsec, a autenticação do túnel ou o login PPP

Três coisas se autenticam dentro de uma única conexão L2TP/IPsec, e apenas uma delas envolve a pessoa que disca. O IPsec comprova os extremos do túnel, a conexão de controle L2TP pode comprovar os pares de novo com seu próprio segredo, e o PPP então comprova a conta de usuário dentro da sessão. Uma falha em qualquer etapa parece um erro genérico de login na janela do cliente e parece completamente diferente no log do servidor. Percorra as etapas em ordem e pare na primeira que falhar, porque toda etapa abaixo de uma não testada também está não testada.

Três etapas de autenticação, três identidades diferentes

O IPsec comprova quem possui os extremos, usando uma chave pré-compartilhada ou um certificado. Essa identidade pertence a máquinas ou gateways, nunca à pessoa no teclado. Quando os pares não conseguem concordar nesta etapa, nenhum pacote L2TP é trocado.

A conexão de controle L2TP pode acrescentar uma segunda troca desafio-resposta, separada, conduzida por um segredo compartilhado que ambas as pontas precisam ter.

O RFC 2661 torna opcional essa autenticação da conexão de controle, o que explica por que o mesmo erro produz sintomas diferentes em dois servidores. Uma implantação que nunca configurou um segredo de túnel pula a etapa por completo; uma que o configurou apenas de um lado falha antes de o PPP ser oferecido. O PPP então autentica o usuário com PAP, CHAP ou MSCHAPv2 e entrega o nome a um armazenamento de contas que pode ser local, em chap-secrets ou no RADIUS. Uma senha errada nesse ponto ainda deixa você com um túnel funcionando e uma sessão que falhou.

Leia o ponto de parada antes de editar uma configuração

Comece com ipsec --version para saber se a saída de status pertence ao strongSwan ou ao Libreswan. Depois leia o log do servidor, não a janela do cliente, porque o servidor registra qual etapa recusou.

Uma linha normalmente resolve o ticket: uma queixa de IKE ou de propostas é a etapa um, uma mensagem da conexão de controle é a etapa dois e uma recusa de método PPP ou de conta é a etapa três. Copie essa linha para o ticket com o carimbo de tempo. Adivinhar pelo lado do cliente desperdiça a única evidência que você já tem.

Mantenha material de chave e senhas fora dessa colagem; o nome da etapa encaminha o trabalho, e uma chave pré-compartilhada vazada reabre o ticket com consequências piores.

Etapa um: o IPsec tem uma associação?

Execute ipsec statusall no strongSwan ou ipsec whack --status no Libreswan e procure uma associação filha estabelecida com contadores diferentes de zero. ip xfrm state mostra a visão do kernel nos dois. Um par de SAs instalado com contadores subindo significa que a etapa um está concluída e você pode seguir.

A ausência total de associação aponta para o endereço do par, o conjunto de propostas ou a chave pré-compartilhada, e às vezes para um dispositivo que reescreve UDP 500 e descarta UDP 4500. Uma associação que se estabelece e depois desaparece após alguns segundos costuma ser uma divergência de tempo de vida entre as duas pontas e não um problema de credenciais. Verifique se os dois lados listam as mesmas propostas de criptografia e hash antes de digitar qualquer coisa de novo. Se não, nenhuma chave funcionará jamais.

Pare enquanto a associação está ausente. Editar as opções de PPP nesse ponto não muda nada e esconde o defeito real da próxima pessoa.

Etapa dois: a conexão de controle L2TP se autenticou?

Depois que o IPsec está no ar, observe o daemon L2TP em busca de uma conexão de controle que atinja um estado estabelecido, pois o PPP não pode começar antes disso. Uma recusa na conexão de controle significa que o segredo do túnel difere entre as pontas, ou que uma ponta exige um segredo que a outra nunca envia. Os clientes costumam expor um único campo rotulado shared secret, e ele normalmente pertence ao IPsec e não ao L2TP. Preenchê-lo não configura o segredo do túnel, e apagá-lo não o desativa.

Se nenhum dos lados configurou um segredo de túnel, pule esta etapa e trate a falha da conexão de controle como um problema de alcance. Confirme que o UDP 1701 chega ao daemon e que as duas pontas concordam com a mesma encapsulação. Uma regra de firewall escrita para uma dessas duas condições é uma causa comum de uma conexão que abre pela metade.

Apenas uma sessão que começa a negociar PPP realmente passou da etapa do túnel.

Etapa três: o PPP está rejeitando a conta?

Uma falha de PPP parece diferente de fora: o túnel está estabelecido, a sessão começa e o daemon registra falha do método de autenticação ou rejeição da conta. Leia o método nomeado nessa mensagem. PAP e CHAP falham por motivos diferentes, e um servidor que recusa um vai recusar um cliente que ofereça apenas esse.

Num servidor Linux, inspecione o arquivo de opções que o daemon passa ao PPP, normalmente /etc/ppp/options.xl2tpd, e confirme quais métodos são aceitos e onde as contas são resolvidas. Um nome que existe no RADIUS mas não no arquivo de segredos local falha de forma limpa e parece uma senha errada. Depois verifique se o cliente oferece um método que o servidor aceita, em vez de um mais forte que o servidor se recusa a negociar. Trocar a chave pré-compartilhada para consertar esta etapa desperdiça uma tarde e não muda nada.

Quando a sessão finalmente sobe, a atribuição de endereços, o DNS e as rotas ainda não foram verificados, e cada uma falha em silêncio do seu jeito. Mantenha as três camadas separadas nas suas anotações: uma chave correta com uma conta errada sempre falha, e consertar uma camada nunca conserta outra.