Senyal fatal 15 a L2TP: NO_PROPOSAL_CHOSEN i modp1024 absent

La connexió es penja, el client surt i l’última línia de la pantalla és death_handler: Fatal signal 15 received. Aquesta línia informa d’una interrupció, no d’una causa. Una línia abans, al registre d’IPsec, gairebé sempre hi ha NO_PROPOSAL_CHOSEN, i la parella assenyala la fase 2 de l’intercanvi, on els parells comparen les opcions de xifratge i de hash i s’aturen quan no en comparteixen cap. En aquesta etapa encara no s’han enviat les credencials, així que tornar a escriure la contrasenya no pot canviar el resultat.

Normalment dues coses buiden aquesta intersecció en un client Linux. El dimoni local pot haver deixat d’implementar el grup Diffie-Hellman que demana el perfil, o el perfil pot portar una proposta de fase 1 en un camp de fase 2. Totes dues deixen rastre al registre, i cap no és un problema de compte.

Què diuen realment els dos missatges

L’IKE negocia per passades. La fase 1 construeix un canal protegit i tria els seus propis algorismes; la fase 2, la SA filla, transporta trànsit amb un conjunt separat. NO_PROPOSAL_CHOSEN és la notificació que retorna el responedor quan cap de les combinacions ofertes no és acceptable, i apareix com a [ HASH N(NO_PROP) ] dins d’un intercanvi INFORMATIONAL.

El senyal 15 és un esdeveniment diferent: alguna cosa va dir al procés local que s’aturés i el gestor ho va registrar. Quan les dues línies apareixen juntes, l’ordre és causal: primer el rebuig i després l’aturada.

Llegeix la negociació abans de tocar les credencials

Apuja el nivell de registre allà on escriu el dimoni i torna a connectar mentre mires la sortida. En un equip amb NetworkManager, el connector L2TP passa aquest nivell al backend, i els missatges arriben al journal o al fitxer syslog clàssic segons la distribució. Qualsevol d’aquests dos mostrarà l’intercanvi: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' o tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Una línia que anomena pluto ve de libreswan, charon de strongSwan, i totes dues descriuen la mateixa condició amb paraules diferents. La forma que val la pena buscar és la que anomena el grup que falta, com ara algorithm 'modp1024' is not supported, perquè converteix un error vague en un de concret.

On va anar modp1024

El grup 2 de Diffie-Hellman és prou feble que diverses distribucions van deixar de compilar-lo dins de libreswan a partir de la 3.30. Llavors un perfil escrit fa anys, o copiat d’una guia de passarel·la que només llista aes128-sha1-modp1024, demana al dimoni local una cosa que no pot executar de cap manera. Les compilacions més noves de NetworkManager-l2tp fan aquest desenllaç més probable: des de la 1.2.16 substitueixen el conjunt per propostes a l’estil de Windows 10 i iOS i descarten modp1024 quan detecten libreswan. L’extrem frontal sovint és innocent i encara ofereix exactament el grup que heu configurat.

Aquesta asimetria és el que fa que la fallada sembli aleatòria. Un client antic es connecta, el mateix perfil en un portàtil actualitzat no, i la configuració del servidor no s’ha mogut mai. El dany el fa la deriva de versions.

Dues reparacions amb abast diferent

La reparació barata és deixar de fixar els algorismes a mà. Buida els dos camps de propostes de l’editor i deixa que el connector triï un conjunt que l’extrem llunyà accepti; si la passarel·la admet grups moderns, la negociació acaba sense més feina.

La segona reparació manté accessible una passarel·la antiga instal·lant strongSwan, els paquets del qual encara implementen el grup 2 a la majoria de distribucions. Això és un canvi de dimoni, així que té un cost: confirmeu si altres túnels de l’equip depenen de la configuració de libreswan abans de treure’l, i espereu denegacions d’SELinux entre NetworkManager i el connector strongSwan a Fedora. Aquestes denegacions surten al registre d’auditoria i no al traçat d’IKE, i per això un túnel pot semblar trencat just després d’una instal·lació correcta. L’ordre que funciona és primer dnf install strongswan, després rpm -e libreswan.

Cadenes de propostes que encaixen, i els paranys al voltant

Quan els camps s’han d’omplir a mà, la fase 1 i la fase 2 prenen valors diferents. Una parella que se sap que funciona contra un extrem d’estil Meraki ofereix aes128-sha1-modp1024 a la fase 1 amb 3des-sha1-modp1024 al darrere, totes dues tancades amb un signe d’exclamació que fa el conjunt estricte, de manera que només s’envien aquestes propostes.

Després la fase 2 s’estreny a aes128-sha1 i 3des-sha1 amb el mateix marcador estricte i sense cap sufix Diffie-Hellman. Una línia de fase 2 que porta -modp1024 és un valor de fase 1 al camp equivocat, i el responedor la rebutja a cada reintent. Copieu aquesta línia a un segon perfil i el segon perfil falla igual, i així una errata es converteix en un incident per a tota la flota.

Altres fallades porten el mateix diàleg emergent sense ser desajustos de propostes. A KDE el tipus L2TP pot aparèixer llistat amb el connector instal·lat mentre cada connexió mor de seguida, perquè l’editor de connexions i els auxiliars d’execució es distribueixen com a paquets separats. Els equips sense pantalla poden reutilitzar un perfil d’un escriptori que funciona: copieu-lo des de /etc/NetworkManager/system-connections/, poseu el mode a 600 i després executeu nmcli con reload. Aixequeu-lo amb nmcli con up id work-l2tp, ja que la forma nua vol un UUID, i traieu qualsevol entrada ifname obsoleta, o el gestor respon Could not find source connection mentre tota la resta és correcta.

Una clau compartida prèviament es pot desar com a text clar o com a 0s seguit de base64; totes dues formes funcionen, però el valor ha de coincidir amb la passarel·la byte a byte, inclosos els espais finals que hi heu copiat.