L2TP fataal sein 15: NO_PROPOSAL_CHOSEN en ontbrekende modp1024

Jou verbinding hang, die kliënt sluit af, en die laaste reël op die skerm is death_handler: Fatal signal 15 received. Daardie reël meld 'n afbreking, nie 'n oorsaak nie. Een reël vroeër in die IPsec-log is daar byna altyd NO_PROPOSAL_CHOSEN, en die paar wys na fase 2 van die uitruiling, waar die eweknieë enkripsie- en hash-keuses vergelyk en stop wanneer hulle niks deel nie. Aanmeldgegewens is op daardie stadium nog nie gestuur nie, so om die wagwoord weer te tik kan nie die uitkoms verander nie.

Twee dinge maak gewoonlik daardie snypunt leeg op 'n Linux-kliënt. Die plaaslike daemon implementeer dalk nie meer die Diffie-Hellman-groep wat die profiel aanvra nie, of die profiel dra 'n fase 1-voorstel in 'n fase 2-veld. Beide laat bewyse in die log, en nie een is 'n rekeningprobleem nie.

Wat die twee boodskappe eintlik sê

IKE onderhandel in rondtes. Fase 1 bou 'n beskermde kanaal en kies sy eie algoritmes; fase 2, die kind-SA, dra verkeer onder 'n aparte stel. NO_PROPOSAL_CHOSEN is die kennisgewing wat 'n antwoorder terugstuur wanneer geen van die aangebode kombinasies aanvaarbaar is nie, en dit verskyn as [ HASH N(NO_PROP) ] binne 'n INFORMATIONAL-uitruiling.

Sein 15 is 'n ander gebeurtenis: iets het die plaaslike proses aangesê om te stop en die hanteerder het dit gelog. Wanneer albei reëls saam verskyn, is die orde oorsaaklik, eers verwerping en dan die afsluiting.

Lees die onderhandeling voordat jy aan aanmeldgegewens raak

Verhoog die logvlak waar die daemon skryf, en maak dan weer verbinding terwyl jy die uitvoer dophou. Op 'n NetworkManager-gasheer gee die L2TP-inprop daardie vlak aan die agterkant deur, en boodskappe beland in die joernaal of in die klassieke syslog-lêer, afhangend van die verspreiding. Enige van hierdie twee sal die uitruiling wys: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' of tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

'n Reël wat pluto noem, kom van libreswan, charon van strongSwan, en die twee beskryf dieselfde toestand in verskillende woorde. Die vorm wat die moeite werd is om te soek, is die een wat die ontbrekende groep noem, soos algorithm 'modp1024' is not supported, want dit maak 'n vae fout 'n spesifieke een.

Waar modp1024 heen gegaan het

Diffie-Hellman-groep 2 is swak genoeg dat verskeie verspreidings dit van 3.30 af opgehou het om in libreswan te kompileer. 'n Profiel wat jare gelede geskryf is, of uit 'n pasgids oorgeneem is wat net aes128-sha1-modp1024 lys, vra die plaaslike daemon dan vir iets wat dit glad nie kan uitvoer nie. Nuwer NetworkManager-l2tp-boude maak daardie uitkoms waarskynliker: van 1.2.16 af vervang hulle die stel met 'n voorstelstel in die styl van Windows 10 en iOS en laat modp1024 vaar sodra libreswan bespeur word. Die koppunt is dikwels onskuldig en bied steeds presies die groep wat jy opgestel het.

Daardie asimmetrie is wat die fout lukraak laat voel. 'n Ouer kliënt verbind, dieselfde profiel op 'n opgedateerde skootrekenaar nie, en die bedienerkonfigurasie het nooit beweeg nie. Weergaweverskuiwing doen die skade.

Twee herstellings met verskillende impak

Die goedkoop herstelling is om op te hou om algoritmes hard te kodeer. Maak albei voorstelvelde in die redigeerder leeg en laat die inprop 'n stel kies wat die verre kant aanvaar; as die poort moderne groepe ondersteun, voltooi die onderhandeling sonder verdere werk.

Die tweede herstelling hou 'n ou poort bereikbaar deur strongSwan te installeer, wie se pakette op die meeste verspreidings steeds groep 2 implementeer. Dit is 'n daemon-omruiling, so dit kos iets: bevestig of ander tonnels op die gasheer van libreswan-konfigurasie afhanklik is voordat jy dit verwyder, en verwag SELinux-weierings tussen NetworkManager en die strongSwan-inprop op Fedora. Daardie weierings kom in die ouditlog na vore eerder as in die IKE-spoor, en daarom kan 'n tonnel reg ná 'n suksesvolle installasie as stukkend lyk. Die volgorde wat werk is dnf install strongswan eerste, dan rpm -e libreswan.

Voorstelstringe wat pas, en die strikke daaromheen

Wanneer die velde met die hand ingevul moet word, neem fase 1 en fase 2 verskillende waardes. 'n Paar wat bekend is om teen 'n Meraki-agtige koppunt te werk, bied aes128-sha1-modp1024 in fase 1 met 3des-sha1-modp1024 agter dit, albei afgesluit met 'n uitroepteken wat die stel streng maak, sodat net daardie voorstelle ooit gestuur word.

Fase 2 vernou dan na aes128-sha1 en 3des-sha1 met dieselfde streng merker en glad geen Diffie-Hellman-agtervoegsel nie. 'n Fase 2-reël wat -modp1024 dra, is 'n fase 1-waarde in die verkeerde veld, en die antwoorder verwerp dit by elke herprobeerslag. Kopieer daardie reël na 'n tweede profiel, en die tweede profiel misluk op dieselfde manier, en dit is hoe een tikfout 'n vlootwye voorval word.

Ander foute dra dieselfde opspringvenster sonder om voorstel-wanpassings te wees. Op KDE kan die L2TP-tipe gelys word met die inprop geïnstalleer terwyl elke verbinding dadelik sterf, want die verbindingredigeerder en die tydren-hulpies word as aparte pakkette verskeep. Gashere sonder 'n skerm kan 'n profiel van 'n werkende lessenaar hergebruik: kopieer dit uit /etc/NetworkManager/system-connections/, stel die modus op 600, en voer dan nmcli con reload uit. Bring dit op met nmcli con up id work-l2tp, aangesien die kaal vorm 'n UUID wil hê, en verwyder enige verouderde ifname-inskrywing, anders antwoord die bestuurder Could not find source connection terwyl alles anders korrek is.

'n Vooraf-gedeelde sleutel kan as gewone teks gestoor word of as 0s gevolg deur base64; enige vorm werk, maar die waarde moet die poort byte vir byte pas, insluitend sleepspasie wat jy saam gekopieer het.