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, пропонує у фазі 1 aes128-sha1-modp1024 із 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; обидві форми працюють, але значення має збігатися зі шлюзом побайтово, включно з пробілами в кінці, скопійованими разом із ним.