O L2TP conecta, mas a negociação PPP falha: qual fase?

O túnel IPsec é estabelecido, o cliente mostra um par protegido e então a conexão morre antes que algo chegue à sub-rede privada. Essa lacuna é o PPP fazendo o próprio trabalho: opções de enlace, autenticação do usuário e atribuição de endereço acontecem todas depois que o túnel cifrado existe. Nada em uma troca bem-sucedida de primeira fase fornece uma senha ou um endereço interno. Leia as fases em ordem e a falha costuma se nomear sozinha.

O túnel é apenas a primeira camada

L2TP transporta quadros PPP dentro de um túnel protegido por IPsec, o que significa que duas negociações independentes precisam ter sucesso antes de um pacote poder ser roteado. A externa prova que as duas pontas concordam sobre chaves e identidades. A interna decide os parâmetros do enlace, se o usuário se autentica e qual endereço o cliente recebe.

Uma falha dentro do PPP parece um túnel quebrado em todo cliente que mostra apenas uma luz de status. Tratá-la como problema de túnel leva a regenerar chaves, reiniciar serviços e, por fim, substituir um segredo compartilhado que nunca esteve errado. A distinção útil é barata: se a troca com o par terminou e o cliente passou a um pedido de nome de usuário ou a uma etapa de autenticação, o túnel está bem. Tudo depois desse ponto pertence ao PPP.

Leia a última fase que teve sucesso

Percorra o log para frente e pare na primeira fase que não foi concluída. O LCP vem primeiro, depois a autenticação, depois o IPCP para os parâmetros IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Um tempo esgotado de LCP significa que as duas pontas nunca concordaram sobre as opções básicas de enlace, o que é um perfil incompatível ou um protocolo interno bloqueado, não uma senha ruim. Uma rejeição explícita de autenticação é o caso oposto: o enlace subiu e um lado recusou as credenciais. Um tempo esgotado de IPCP após autenticação bem-sucedida aponta para pools de endereços ou política do servidor. Cada um tem um dono diferente e um reparo diferente, e é por isso que a fase importa mais que o texto final do erro.

Guarde o trecho do log junto com o nome da fase no chamado. Uma cauda colada sem a fronteira da fase convida o próximo leitor a adivinhar, e adivinhar aqui custa uma hora.

Acordo entre o cliente e o servidor

As duas pontas precisam aceitar o mesmo método de autenticação, e um perfil salvo pode pedir um que o servidor aposentou no trimestre passado. Implantações gerenciadas também escondem o lado do servidor, onde o motivo da rejeição costuma ser registrado no usuário e não no dispositivo.

Ative um método suportado em vez de cada opção legada, porque um cliente que oferece cinco métodos esconde qual falhou. Peça ao administrador a política do lado do servidor e a rejeição exata, o que não exige que ninguém publique uma senha. Um método legado ativado para salvar um cliente tende a se espalhar para todo perfil que copia o arquivo.

Verifique o endereço, não o login

Um login concluído não é uma sessão utilizável. O IPCP negocia o endereço interno, e um pool esgotado ou uma política que nega o cliente ainda podem deixar um túnel conectado sem nada para rotear.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Verifique primeiro o endereço interno, depois a rota e o resolvedor para o recurso de que você realmente precisa. Um endereço interno não é a saída pública que um site informa, e confundir os dois manda as pessoas caçar um vazamento que não existe. Teste o recurso privado por endereço antes de testá-lo por nome, para que uma falha de DNS não seja confundida com uma falha de roteamento.

Escreva a fase, o método e o endereço em uma única nota e date-a. Se a mesma conta falhar de novo em um mês, essa nota é a diferença entre uma verificação de cinco minutos e uma investigação nova. Falhas em fases diferentes são incidentes diferentes, mesmo quando o cliente mostra uma só caixa de diálogo.