L2TP: sinal fatal 15, NO_PROPOSAL_CHOSEN e modp1024 ausente

A conexión colga, o cliente sae e a última liña na pantalla é death_handler: Fatal signal 15 received. Esa liña informa dunha interrupción, non dunha causa. Unha liña máis arriba no rexistro de IPsec case sempre hai NO_PROPOSAL_CHOSEN, e o par apunta á fase 2 do intercambio, onde os extremos comparan opcións de cifrado e de hash e detéñense cando non comparten ningunha. Nesa etapa aínda non se enviaron as credenciais, así que volver escribir o contrasinal non pode cambiar o resultado.

Normalmente dúas cousas baleiran esa intersección nun cliente Linux. Pode que o daemon local xa non implemente o grupo Diffie-Hellman que pide o perfil, ou que o perfil leve unha proposta de fase 1 nun campo de fase 2. Ambas deixan rastro no rexistro, e ningunha é un problema de conta.

Que din en realidade as dúas mensaxes

IKE negocia por pasadas. A fase 1 constrúe unha canle protexida e escolle os seus propios algoritmos; a fase 2, a SA filla, transporta tráfico cun conxunto aparte. NO_PROPOSAL_CHOSEN é a notificación que devolve o respondedor cando ningunha das combinacións ofrecidas é aceptable, e aparece como [ HASH N(NO_PROP) ] dentro dun intercambio INFORMATIONAL.

O sinal 15 é outro suceso: algo lle dixo ao proceso local que parase e o xestor rexistrouno. Cando as dúas liñas aparecen xuntas, a orde é causal: primeiro o rexeitamento e despois o apagado.

Lea a negociación antes de tocar as credenciais

Sube o nivel de rexistro onde escribe o daemon e volve conectar mentres observas a saída. Nun equipo con NetworkManager o complemento L2TP pasa ese nivel ao backend, e as mensaxes acaban no journal ou no ficheiro syslog clásico segundo a distribución. Calquera destes dous mostrará o intercambio: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' ou tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Unha liña que nomea pluto vén de libreswan, charon de strongSwan, e as dúas describen a mesma condición con palabras distintas. A forma que paga a pena buscar é a que nomea o grupo que falta, como algorithm 'modp1024' is not supported, porque converte un fallo vago nun concreto.

A onde foi modp1024

O grupo 2 de Diffie-Hellman é abondo feble como para que varias distribucións deixasen de compilalo dentro de libreswan a partir da 3.30. Entón un perfil escrito hai anos, ou copiado dunha guía de pasarela que só lista aes128-sha1-modp1024, pide ao daemon local algo que non pode executar de ningún xeito. As compilacións máis recentes de NetworkManager-l2tp fan ese desenlace máis probable: desde a 1.2.16 substitúen o conxunto por propostas ao estilo de Windows 10 e iOS e descartan modp1024 en canto detectan libreswan. O extremo remoto adoita ser inocente e segue ofrecendo exactamente o grupo que configurou.

Esa asimetría é o que fai que o fallo pareza aleatorio. Un cliente antigo conéctase, o mesmo perfil nun portátil actualizado non, e a configuración do servidor nunca se moveu. O dano fáino a deriva de versións.

Dúas reparacións con alcance distinto

A reparación barata é deixar de fixar os algoritmos a man. Baleira os dous campos de propostas do editor e deixa que o complemento escolla un conxunto que o extremo remoto acepte; se a pasarela admite grupos modernos, a negociación remata sen máis traballo.

A segunda reparación mantén accesible unha pasarela antiga instalando strongSwan, cuxos paquetes aínda implementan o grupo 2 na maioría das distribucións. Iso é un cambio de daemon, así que ten un custo: confirma se outros túneles do equipo dependen da configuración de libreswan antes de quitalo, e agarda denegacións de SELinux entre NetworkManager e o complemento strongSwan en Fedora. Esas denegacións aparecen no rexistro de auditoría e non na traza de IKE, por iso un túnel pode parecer roto xusto despois dunha instalación correcta. A orde que funciona é primeiro dnf install strongswan e despois rpm -e libreswan.

Cadeas de propostas que encaixan, e as trampas que as rodean

Cando os campos hai que enchelos a man, a fase 1 e a fase 2 toman valores distintos. Unha parella que se sabe que funciona contra un extremo de estilo Meraki ofrece aes128-sha1-modp1024 na fase 1 con 3des-sha1-modp1024 detrás, ambas pechadas cun signo de exclamación que fai estrito o conxunto, de xeito que só se envían esas propostas.

Despois a fase 2 estreítase a aes128-sha1 e 3des-sha1 co mesmo marcador estrito e sen ningún sufixo Diffie-Hellman. Unha liña de fase 2 que leva -modp1024 é un valor de fase 1 no campo equivocado, e o respondedor rexéitaa en cada reintento. Copia esa liña nun segundo perfil e o segundo perfil falla igual, e así unha errata convértese nun incidente para toda a frota.

Outras fallas levan a mesma xanela emerxente sen ser desaxustes de propostas. En KDE o tipo L2TP pode aparecer listado co complemento instalado mentres cada conexión morre ao instante, porque o editor de conexións e os axudantes de tempo de execución distribúense como paquetes separados. Os equipos sen pantalla poden reutilizar un perfil dun escritorio que funciona: cópiao desde /etc/NetworkManager/system-connections/, pon o modo en 600 e despois executa nmcli con reload. Sobeo con nmcli con up id work-l2tp, xa que a forma espida pide un UUID, e elimina calquera entrada ifname obsoleta, ou o xestor responde Could not find source connection mentres todo o demais é correcto.

Unha chave precompartida pode gardarse como texto claro ou como 0s seguido de base64; as dúas formas funcionan, pero o valor debe coincidir coa pasarela byte a byte, incluídos os espazos finais que copiou con ela.