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; обе формы работают, но значение должно совпадать со шлюзом побайтово, включая пробелы в конце, скопированные вместе с ним.