Que camada do perfil L2TP realmente quebrou

Desça pela pilha em vez de percorrer a página de definições: Negociação IPsec, depois controlo L2TP, depois autenticação PPP e, por fim, atribuição de endereço e DNS. Cada camada tem a sua própria assinatura de erro e a sua própria causa provável. Um perfil que falha na autenticação do utilizador já passou por três verificações a que um perfil que expirou mais cedo nunca chegou. Essa ordem é a primeira coisa a estabelecer.

O mesmo nome de protocolo esconde quatro conversas diferentes.

Nomeie a camada antes de alterar definições

Se a configuração do IPsec falhar, aponta para o segredo partilhado, para os algoritmos ou para a identidade do par. Se depois falhar o controlo L2TP, sugere a própria camada do túnel, que é um problema mais estreito. As falhas de autenticação PPP nomeiam a conta ou o método de autenticação. Uma falha de endereço ou de DNS após a autenticação significa que o transporte funcionou e a troca de configuração não.

Registe a versão do cliente, a versão do sistema operativo e a configuração documentada do operador. Sem estas três, cada alteração é um palpite que pode reparar outra coisa por acidente.

Compare o perfil com o cliente atual

Um perfil guardado pode conter um segredo partilhado, uma opção de autenticação ou um endpoint que o cliente atual já não aceita. Algumas plataformas retiraram ou removeram por completo o suporte a L2TP/IPsec, e um cliente atualizado pode abandonar o comportamento antigo do IKE sem qualquer alteração no servidor. Compare os seus valores guardados com os requisitos documentados atuais do operador, e não com o que funcionava há um ano. A diferença entre esses dois documentos é normalmente onde está a resposta.

Um segredo em cache ou uma conta renomeada normalmente não exigem mais do que uma atualização comum do perfil, e ambos merecem ser verificados antes de redesenhar seja o que for. Essas são as correções baratas, e devem ser excluídas antes de qualquer trabalho arquitetónico.

As opções antigas não voltam por serem ativadas

Desativar a validação não repara um problema de cadeia de confiança, e ativar um algoritmo só porque um tópico de fórum o menciona não prova nada sobre o que o servidor aceita. As propostas IKE fracas costumam ser removidas dos clientes por boas razões, e reativar uma delas cria uma ligação pior do que a que quebrou. Um túnel mais fraco não é uma reparação, é um problema novo com o mesmo sintoma. A pergunta correta é o que o operador suporta agora.

A reparação de ativar tudo muda muito mais do que a falha real e deixa-o incapaz de dizer o que a resolveu.

Apresente a migração como um projeto

Se a implementação já não suporta o cliente necessário, planeie uma substituição com o operador em vez de conservar uma exceção não documentada. Transfira o requisito de acesso, as identidades, as entradas DNS e as rotas, porque um novo handshake sozinho não recria nenhuma dessas permissões. São as peças de que uma ligação funcional dependia em silêncio. Guarde o perfil antigo em segurança até a recuperação ser confirmada e, depois, retire as credenciais obsoletas onde elas são realmente administradas. Deixá-las no lugar é a forma de um caminho antigo continuar utilizável muito depois de todos acreditarem que foi fechado.

Uma migração é também o momento de anotar para que servia o perfil. Caso contrário, a pessoa seguinte herda uma ligação funcional sem qualquer explicação.

Verifique a camada, a versão do cliente e os requisitos atuais do operador. Depois decida se isto é uma reparação ou uma substituição.