Log de depuração do L2TP vazio? O erro provavelmente está no journal

Você inicia o auxiliar do L2TP com depuração, observa o terminal, e ele para sem nada útil na tela. Isso não é um sinalizador de depuração quebrado. Uma conexão L2TP do NetworkManager são quatro processos que cooperam, e apenas alguns deles escrevem no terminal que você está observando. O restante das evidências está no journal, a um filtro de distância.

Quatro processos, dois destinos de registro

A conexão começa com o IPsec, que é libreswan ou strongSwan dependendo da instalação. Depois o daemon L2TP, tradicionalmente xl2tpd e em algumas compilações kl2tpd, conduz o túnel. Por fim o pppd cuida da autenticação e do endereçamento dentro dele.

O serviço auxiliar coordena essas peças e imprime o próprio progresso. O daemon IPsec e o pppd geralmente relatam pelo journal do sistema, e por isso o terminal mostra uma conexão que falha enquanto o motivo está em um arquivo que você não abriu.

Essa separação também explica por que um erro de PSK e um erro de senha parecem iguais na área de trabalho: os dois produzem uma desconexão genérica, e a etapa que falhou só é visível na saída de cada processo. É toda a razão pela qual o journal importa aqui. Uma mensagem genérica na área de trabalho, quatro autores possíveis por trás.

Reúna uma tentativa e depois leia a ordem

Reproduza uma vez, com um perfil conhecido e um horário conhecido, e depois leia uma janela estreita em vez de toda a inicialização. Repetir tentativas enquanto muda configurações transforma o log em uma mistura que não pode ser interpretada.

Estes comandos selecionam os processos participantes da inicialização atual, e vale confirmar o caminho do plugin na sua distribuição:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Campos repetidos em uma única invocação selecionam a união desses processos, o que mantém a sequência em ordem temporal. Em um sistema baseado em Debian a consulta equivalente é dpkg -L; o ponto é descobrir onde o auxiliar realmente vive antes de tentar executá-lo à mão.

Três condições decidem o próximo passo

Leia a primeira etapa que falha e escolha de acordo. Se o IPsec relata uma falha de proposta ou de autenticação do par, o túnel nunca se formou, e mudar a senha PPP não pode ajudar.

Se o túnel se formou e o pppd rejeitou o login, o segredo compartilhado já estava correto e o problema de credenciais está uma camada acima. Se o pppd negociou um endereço e a falha aparece depois, os dois funcionam e o problema restante é roteamento, DNS ou a política do próprio servidor.

Esses três ramos cobrem quase toda desconexão genérica, e são decididos por qual processo registrou o último erro, não por qual mensagem de erro parece mais alarmante.

Também vale confirmar qual backend do IPsec está instalado antes de mexer em uma configuração de depuração. Uma opção de registro escrita para o strongSwan não faz nada quando o libreswan está rodando, e a conexão continuará falhando no mesmo ponto enquanto você edita um arquivo que ninguém lê.

O modo de depuração deixa arquivos

O fluxo de depuração original executa o serviço à mão com um sinalizador de depuração, e esse modo pode deixar arquivos de configuração de execução gerados no lugar quando a conexão termina.

Esses arquivos contêm material de autenticação: a chave pré-compartilhada, credenciais ou ambos. Uma configuração gerada copiada para uma janela de chat é uma revelação de credenciais, não um trecho de log. Remova as linhas secretas antes de compartilhar qualquer coisa e apague o diretório quando a investigação terminar. Trate-os como segredos, extraia as linhas específicas de que precisa para um relatório e apague-os depois, em vez de colar um diretório em um ticket.

A instância manual também precisa ser coordenada com a normal. Iniciar uma cópia de depuração enquanto o serviço já possui o plugin produz dois proprietários e um log que mistura os dois, o que é pior do que nenhuma saída de depuração.

Depois restaure o auxiliar normal

Quando a investigação terminar, pare a instância manual, remova os arquivos de execução retidos e reconecte pelo caminho normal para que a próxima pessoa veja uma configuração que corresponde à realidade.

Em seguida verifique o resultado na camada que falhou, não no ícone da área de trabalho:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Uma sessão que se autentica, recebe um endereço e roteia para o destino pretendido é o resultado que você estava depurando. Um terminal silencioso durante uma tentativa falha só lhe diz onde a saída não foi escrita.