L2TP фатален сигнал 15: NO_PROPOSAL_CHOSEN и липсващ modp1024

Връзката ви забива, клиентът излиза и последният ред на екрана е death_handler: Fatal signal 15 received. Този ред съобщава за прекратяване, а не за причина. Един ред по-горе в журнала на IPsec почти винаги има NO_PROPOSAL_CHOSEN и двойката сочи към фаза 2 на обмена, където страните сравняват изборите за криптиране и хеширане и спират, когато не споделят нито един. На този етап идентификационните данни още не са изпратени, така че повторното въвеждане на паролата не може да промени резултата.

Обикновено две неща изпразват това сечение на Linux клиент. Локалният демон може вече да не реализира групата Diffie-Hellman, която профилът изисква, или профилът може да носи предложение за фаза 1 в поле за фаза 2. И двете оставят следи в журнала и нито едно не е проблем с акаунта.

Какво всъщност казват двете съобщения

IKE преговаря на етапи. Фаза 1 изгражда защитен канал и избира собствени алгоритми; фаза 2, дъщерната SA, пренася трафик по отделен набор. NO_PROPOSAL_CHOSEN е нотификацията, която отговарящата страна връща, когато нито една от предложените комбинации не е приемлива, и се появява като [ HASH N(NO_PROP) ] вътре в обмен INFORMATIONAL.

Сигнал 15 е друго събитие: нещо нареди на локалния процес да спре и обработчикът го записа. Когато двата реда се появят заедно, редът е причинен — първо отказ, после спиране.

Прочетете преговорите, преди да пипате идентификационни данни

Вдигнете нивото на журнала там, където демонът пише, след което се свържете отново, докато наблюдавате изхода. На хост с NetworkManager приставката L2TP предава това ниво на бекенда и съобщенията попадат в journal или в класическия syslog файл в зависимост от дистрибуцията. Всяко от тези ще покаже обмена: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' или tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Ред с име pluto идва от libreswan, charon — от strongSwan, и двете описват едно и също състояние с различни думи. Формата, която си струва да търсите, е тази, която назовава липсващата група, например algorithm 'modp1024' is not supported, защото превръща неясния отказ в конкретен.

Къде изчезна modp1024

Група 2 на Diffie-Hellman е достатъчно слаба, че няколко дистрибуции спряха да я компилират в libreswan от 3.30 нататък. Тогава профил, писан преди години или копиран от ръководство за шлюз, което изброява само aes128-sha1-modp1024, иска от локалния демон нещо, което той изобщо не може да изпълни. По-новите сборки на NetworkManager-l2tp правят този изход по-вероятен: от 1.2.16 те подменят набора с предложения в стил Windows 10 и iOS и изхвърлят modp1024, щом бъде открит libreswan. Отсрещната страна често е невинна и все още предлага точно групата, която сте конфигурирали.

Именно тази асиметрия кара отказа да изглежда случаен. По-стар клиент се свързва, същият профил на обновен лаптоп — не, а конфигурацията на сървъра никога не е мърдала. Щетата я нанася разминаването на версиите.

Два ремонта с различен обхват на щетите

Евтиният ремонт е да спрете да втвърдявате алгоритмите. Изчистете двете полета за предложения в редактора и оставете приставката да избере набор, който далечната страна приема; ако шлюзът поддържа съвременни групи, преговорите завършват без допълнителна работа.

Вторият ремонт запазва стария шлюз достъпен чрез инсталиране на strongSwan, чиито пакети все още реализират група 2 в повечето дистрибуции. Това е смяна на демон, така че има цена: проверете дали други тунели на хоста зависят от конфигурацията на libreswan, преди да го премахнете, и очаквайте откази на SELinux между NetworkManager и приставката strongSwan във Fedora. Тези откази излизат в одитния журнал, а не в следата на IKE, затова тунелът може да изглежда счупен веднага след успешна инсталация. Редът, който работи, е първо dnf install strongswan, после rpm -e libreswan.

Съвпадащи низове за предложения и капаните около тях

Когато полетата трябва да се попълват на ръка, фаза 1 и фаза 2 приемат различни стойности. Двойка, за която се знае, че работи срещу отсрещна страна от типа Meraki, предлага aes128-sha1-modp1024 във фаза 1 с 3des-sha1-modp1024 зад него, двете затворени с удивителен знак, който прави набора строг, така че се изпращат само тези предложения.

След това фаза 2 се стеснява до aes128-sha1 и 3des-sha1 със същия строг маркер и без никаква наставка Diffie-Hellman. Ред във фаза 2, носещ -modp1024, е стойност от фаза 1 в грешното поле и отговарящата страна го отхвърля при всеки повторен опит. Копирайте този ред във втори профил и вторият профил се проваля по същия начин — така една печатна грешка става инцидент за целия флот.

Други повреди носят същия изскачащ прозорец, без да са несъответствие на предложения. В KDE типът L2TP може да фигурира при инсталирана приставка, докато всяка връзка умира веднага, защото редакторът на връзки и помощните програми за изпълнение се доставят като отделни пакети. Хостове без екран могат да използват отново профил от работещ десктоп: копирайте го от /etc/NetworkManager/system-connections/, задайте режим 600, след което изпълнете nmcli con reload. Вдигнете го с nmcli con up id work-l2tp, тъй като голата форма иска UUID, и премахнете всеки остарял запис ifname, иначе мениджърът отговаря Could not find source connection, докато всичко останало е правилно.

Предварително споделен ключ може да се съхранява като чист текст или като 0s, последван от base64; и двете форми работят, но стойността трябва да съвпада с шлюза байт по байт, включително крайните интервали, които сте копирали с нея.