A atualização do Ubuntu quebrou o L2TP/IPsec? Compare as propostas IKEv1

A ligação funcionava na quinta-feira, a atualização correu na sexta-feira, e na segunda-feira o cliente gira em “connecting” e desiste. O mesmo portátil, o mesmo servidor, a mesma conta, a mesma chave pré-partilhada. Nada foi editado no perfil, e é por isso que os suspeitos óbvios, a palavra-passe e a firewall, lhe fazem perder tempo.

O que mudou foi a lista de transformações que a sua máquina está disposta a oferecer. Ambas as pilhas IPsec usadas no Ubuntu, strongSwan e Libreswan, eliminam algoritmos que já não consideram seguros, e o plugin do NetworkManager que as precede tem a sua própria lista, que se move segundo um calendário diferente. Um servidor fixado em 3DES, SHA1 e um grupo Diffie-Hellman de 1024 bits pode acabar por não ouvir nada do que aceita.

O que a atualização mudou de facto

Duas camadas alimentam a proposta IKEv1. O daemon fornece um conjunto de propostas predefinido compilado, e o plugin L2TP ou confia nele ou fornece a sua própria lista. Antes do NetworkManager-l2tp 1.2.16 o plugin confiava nele, por isso a sua proposta era o que o daemon instalado considerava razoável. A partir de 1.2.16 o plugin envia uma lista documentada inspirada nos clientes Windows e Apple, e essa lista é mais ampla do que a predefinição antiga mas já não contém todas as combinações herdadas à frente da fila.

Essa separação explica um modo de falha que as pessoas acham confuso: duas máquinas na mesma versão de Ubuntu podem comportar-se de forma diferente porque uma tem o pacote da distribuição e a outra tem um backport, e a versão do daemon em ambas parece idêntica num relatório de erro. Verifique a versão do plugin, não apenas a versão do daemon, antes de concluir que a atualização não mudou nada de relevante.

Há uma armadilha mais pequena na mesma zona. Os dois daemons escrevem de forma diferente os grupos Diffie-Hellman de curva elíptica, um escreve ecp384 e o outro ecp_384. Cole a ortografia errada na caixa de diálogo Avançado e o daemon rejeita a definição como não analisável, o que no registo aparece como um problema de negociação e não como um erro de escrita na configuração.

Leia a falha antes de mudar alguma coisa

Comece por saber que backend está a executar, porque a resposta decide tanto a sintaxe como a localização do registo.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Depois leia a troca em si. No strongSwan o daemon escreve no journal numa versão atual e em /var/log/syslog numa mais antiga, e a parte interessante é a proposta que envia, não a última linha. Está à procura de texto sobre nenhuma proposta correspondente, que é um problema de algoritmo; uma falha de autenticação, que aponta para a chave ou a conta; ou um simples tempo limite, que aponta para a acessibilidade.

Estes três resultados são tratados como um único sintoma demasiadas vezes. Um tempo limite com um registo de daemon vazio significa que os pacotes não chegam. Uma rejeição da proposta significa que chegaram e foram recusados. Se o seu registo está silencioso, aumente o nível de depuração do plugin para uma tentativa e baixe-o depois, porque a saída detalhada enche um journal depressa.

A fase 1 e a fase 2 são apostas separadas

O IKEv1 negoceia duas vezes. O modo principal constrói a associação de segurança IKE a partir de um algoritmo de cifra, um algoritmo de integridade, um grupo Diffie-Hellman e um método de autenticação. O modo rápido constrói depois a associação ESP que transportará L2TP. Um servidor é livre de aceitar a primeira e rejeitar a segunda, por isso um perfil meio correto falha mais tarde do que espera e parece um erro diferente.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

O ponto de exclamação é sintaxe do strongSwan para uma entrada estrita: ofereça apenas esta combinação e nada mais. Sem ele a entrada junta-se a uma lista de recurso, o que é bom quando o par é moderno e contraproducente quando é um aparelho com uma única política codificada. Trate o par acima como uma ilustração da forma, não como uma recomendação para nada do que esteja a construir hoje.

Mude um campo e repita o teste

Num plugin atual, o primeiro teste mais rápido é limpar por completo os dois campos de propostas e voltar a ligar, porque a lista predefinida fornecida já inclui as combinações habituais de Windows e Apple. Num plugin mais antigo, limpá-los devolve o controlo a um daemon que pode ter abandonado o algoritmo que o seu servidor exige, e a falha piora.

Se limpar não ajudar, defina o par estrito que o seu servidor documenta, uma fase de cada vez. Mude a fase 1, volte a ligar e leia o registo antes de tocar na fase 2. Quando uma combinação finalmente funcionar, anote-a ao lado do modelo de servidor e da versão do plugin, porque os valores predefinidos voltarão a mudar e essa nota é o que transforma a próxima atualização numa verificação de cinco minutos.