A actualización de Ubuntu rompeu L2TP/IPsec? Compare as propostas de IKEv1

A conexión funcionaba o xoves, a actualización executouse o venres, e o luns o cliente xira en “connecting” e réndese. Mesmo portátil, mesmo servidor, mesma conta, mesma clave precompartida. Non se editou nada do perfil, e por iso os sospeitosos obvios, o contrasinal e a devasa, fanlle perder o tempo.

O que cambiou é a lista de transformacións que a súa máquina está disposta a ofrecer. As dúas pilas IPsec usadas en Ubuntu, strongSwan e Libreswan, eliminan algoritmos que xa non consideran seguros, e o complemento de NetworkManager que as precede ten a súa propia lista, que se move cun calendario distinto. Un servidor fixado a 3DES, SHA1 e un grupo Diffie-Hellman de 1024 bits pode acabar sen oír nada do que acepta.

Que cambiou realmente a actualización

Dúas capas alimentan a proposta de IKEv1. O demo inclúe un conxunto de propostas predeterminado compilado, e o complemento L2TP ou ben confía nel ou ben fornece a súa propia lista. Antes de NetworkManager-l2tp 1.2.16 o complemento confiaba nel, así que a súa proposta era o que o demo instalado consideraba razoable. A partir de 1.2.16 o complemento envía unha lista documentada inspirada nos clientes de Windows e Apple, e esa lista é máis ampla que o valor predeterminado antigo pero xa non contén todas as combinacións herdadas á fronte da cola.

Esa división explica un modo de fallo que á xente lle resulta confuso: dúas máquinas na mesma versión de Ubuntu poden comportarse de forma distinta porque unha ten o paquete da distribución e a outra ten un backport, e a versión do demo en ambas parece idéntica nun informe de erro. Comprobe a versión do complemento, non só a do demo, antes de concluír que a actualización non cambiou nada relevante.

Hai unha trampa máis pequena na mesma zona. Os dous demos escriben de forma distinta os grupos Diffie-Hellman de curva elíptica, un escribe ecp384 e o outro ecp_384. Pegue a ortografía incorrecta no diálogo Avanzado e o demo rexeitará o axuste como non analizable, o que no rexistro aparece como un problema de negociación e non como unha errata de configuración.

Lea o fallo antes de cambiar nada

Comece por que backend está executando, porque a resposta decide tanto a sintaxe como a localización do rexistro.

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

Despois lea o intercambio en si. En strongSwan o demo rexistra no journal nunha versión actual e en /var/log/syslog nunha máis antiga, e a parte interesante é a proposta que envía, non a liña final. Busca texto sobre ningunha proposta coincidente, que é un problema de algoritmo; un fallo de autenticación, que apunta á clave ou á conta; ou un tempo de espera simple, que apunta á accesibilidade.

Estes tres resultados trátanse como un só síntoma con demasiada frecuencia. Un tempo de espera cun rexistro de demo baleiro significa que os paquetes non chegan. Un rexeitamento da proposta significa que chegaron e foron rexeitados. Se o seu rexistro está silencioso, suba o nivel de depuración do complemento para un intento e báixeo despois, porque a saída detallada enche un journal rapidamente.

A fase 1 e a fase 2 son apostas separadas

IKEv1 negocia dúas veces. O modo principal constrúe a asociación de seguridade IKE a partir dun algoritmo de cifrado, un algoritmo de integridade, un grupo Diffie-Hellman e un método de autenticación. O modo rápido constrúe despois a asociación ESP que transportará L2TP. Un servidor é libre de aceptar a primeira e rexeitar a segunda, así que un perfil medio correcto falla máis tarde do que espera e parece un erro distinto.

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

O signo de exclamación é sintaxe de strongSwan para unha entrada estrita: ofreza esta única combinación e nada máis. Sen el a entrada únese a unha lista de reserva, o que está ben cando o par é moderno e é contraproducente cando é un aparello cunha única política codificada. Trate o par anterior como unha ilustración da forma, non como unha recomendación para nada do que estea construíndo hoxe.

Cambie un campo e repita a proba

Nun complemento actual, a proba inicial máis rápida é borrar por completo ambos os campos de propostas e reconectar, porque a lista predeterminada incluída xa contén as combinacións habituais de Windows e Apple. Nun complemento máis antigo, borralos devolve o control a un demo que pode ter descartado o algoritmo que o seu servidor esixe, e o fallo empeora.

Se borralos non axuda, estableza o par estrito que documenta o seu servidor, unha fase cada vez. Cambie a fase 1, reconecte e lea o rexistro antes de tocar a fase 2. Cando unha combinación por fin funcione, anótea xunto ao modelo do servidor e á versión do complemento, porque os valores predeterminados volverán moverse e esa nota é o que converte a próxima actualización nunha comprobación de cinco minutos.