L2TP: semnal fatal 15, NO_PROPOSAL_CHOSEN și modp1024 lipsă

Conexiunea se blochează, clientul iese, iar ultima linie de pe ecran este death_handler: Fatal signal 15 received. Acea linie raportează o întrerupere, nu o cauză. Cu o linie mai sus în jurnalul IPsec există aproape întotdeauna NO_PROPOSAL_CHOSEN, iar perechea indică faza 2 a schimbului, unde părțile compară opțiunile de criptare și hash și se opresc atunci când nu au nimic comun. Credențialele nu au fost încă trimise în acea etapă, așa că reintroducerea parolei nu poate schimba rezultatul.

De obicei două lucruri golesc acea intersecție pe un client Linux. Daemonul local poate să nu mai implementeze grupul Diffie-Hellman cerut de profil, sau profilul poate purta o propunere de faza 1 într-un câmp de faza 2. Ambele lasă urme în jurnal, și niciuna nu este o problemă de cont.

Ce spun de fapt cele două mesaje

IKE negociază în etape. Faza 1 construiește un canal protejat și își alege algoritmii; faza 2, SA copil, transportă traficul sub un set separat. NO_PROPOSAL_CHOSEN este notificarea pe care răspunzătorul o returnează atunci când niciuna dintre combinațiile oferite nu este acceptabilă, și apare ca [ HASH N(NO_PROP) ] în interiorul unui schimb INFORMATIONAL.

Semnalul 15 este un alt eveniment: ceva a spus procesului local să se oprească, iar handlerul a înregistrat asta. Când ambele linii apar împreună, ordinea este cauzală: mai întâi respingerea, apoi oprirea.

Citiți negocierea înainte de a atinge credențialele

Ridicați nivelul de jurnalizare acolo unde scrie daemonul, apoi reconectați-vă urmărind ieșirea. Pe un gazdă cu NetworkManager, modulul L2TP transmite acel nivel backendului, iar mesajele ajung în journal sau în fișierul syslog clasic în funcție de distribuție. Oricare dintre acestea va arăta schimbul: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' sau tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

O linie care numește pluto vine de la libreswan, charon de la strongSwan, iar ambele descriu aceeași stare cu cuvinte diferite. Forma care merită căutată este cea care numește grupul lipsă, de exemplu algorithm 'modp1024' is not supported, pentru că transformă o eroare vagă într-una concretă.

Unde a dispărut modp1024

Grupul 2 Diffie-Hellman este suficient de slab încât mai multe distribuții au încetat să îl compileze în libreswan începând cu 3.30. Atunci un profil scris cu ani în urmă, sau preluat dintr-un ghid de gateway care listează doar aes128-sha1-modp1024, cere daemonului local ceva ce acesta nu poate executa deloc. Compilările mai noi de NetworkManager-l2tp fac acel rezultat mai probabil: din 1.2.16 înlocuiesc setul cu propuneri în stilul Windows 10 și iOS și renunță la modp1024 imediat ce libreswan este detectat. Cealaltă parte este adesea nevinovată și încă oferă exact grupul pe care l-ați configurat.

Această asimetrie face ca eșecul să pară aleatoriu. Un client mai vechi se conectează, același profil pe un laptop actualizat nu, iar configurația serverului nu s-a mișcat niciodată. Paguba este făcută de derivarea versiunilor.

Două reparații cu impact diferit

Reparația ieftină este să nu mai codificați algoritmii manual. Goliți ambele câmpuri de propuneri din editor și lăsați modulul să aleagă un set acceptat de partea îndepărtată; dacă gatewayul acceptă grupuri moderne, negocierea se încheie fără muncă suplimentară.

A doua reparație menține un gateway vechi accesibil instalând strongSwan, ale cărui pachete încă implementează grupul 2 pe majoritatea distribuțiilor. Aceasta este o schimbare de daemon, deci are un cost: verificați dacă alte tuneluri de pe gazdă depind de configurația libreswan înainte de a-l elimina, și așteptați-vă la refuzuri SELinux între NetworkManager și modulul strongSwan pe Fedora. Acele refuzuri apar în jurnalul de audit, nu în urma IKE, motiv pentru care un tunel poate părea stricat imediat după o instalare reușită. Ordinea care funcționează este mai întâi dnf install strongswan, apoi rpm -e libreswan.

Șiruri de propuneri care se potrivesc, și capcanele din jur

Când câmpurile trebuie completate manual, faza 1 și faza 2 iau valori diferite. O pereche cunoscută că funcționează împotriva unei părți în stil Meraki oferă aes128-sha1-modp1024 în faza 1 cu 3des-sha1-modp1024 în spate, ambele închise de un semn de exclamare care face setul strict, așa că doar acele propuneri sunt trimise.

Faza 2 se îngustează apoi la aes128-sha1 și 3des-sha1 cu același marcaj strict și fără niciun sufix Diffie-Hellman. O linie de faza 2 care poartă -modp1024 este o valoare de faza 1 în câmpul greșit, iar răspunzătorul o respinge la fiecare reîncercare. Copiați acea linie într-un al doilea profil și al doilea profil eșuează la fel, și astfel o greșeală de tastare devine un incident pentru întreaga flotă.

Alte defecțiuni poartă aceeași fereastră fără a fi nepotriviri de propuneri. În KDE tipul L2TP poate fi listat cu modulul instalat în timp ce fiecare conexiune moare imediat, pentru că editorul de conexiuni și ajutoarele de execuție sunt livrate ca pachete separate. Gazdele fără ecran pot reutiliza un profil de pe un desktop funcțional: copiați-l din /etc/NetworkManager/system-connections/, setați modul la 600, apoi rulați nmcli con reload. Ridicați-l cu nmcli con up id work-l2tp, deoarece forma goală cere un UUID, și eliminați orice intrare ifname învechită, altfel managerul răspunde Could not find source connection în timp ce tot restul este corect.

O cheie partajată în prealabil poate fi stocată ca text simplu sau ca 0s urmat de base64; ambele forme funcționează, dar valoarea trebuie să corespundă gatewayului octet cu octet, inclusiv spațiile finale pe care le-ați copiat împreună cu ea.