L2TP NO_PROPOSAL_CHOSEN: какая фаза на самом деле не удалась?
Уведомление сообщает, что предложение отклонено, но не какое именно. Прочитайте журнал бэкенда, чтобы определить фазу, затем сравните наборы с тем, кто администрирует шлюз.
NO_PROPOSAL_CHOSEN приходит раньше, чем проверяется любое имя пользователя PPP, и это полезный факт, а также причина, по которой сообщение вводит в заблуждение. Оно сообщает, что одна сторона отклонила предложение; оно не сообщает, какой параметр не совпал, и ничего не говорит о том, произошёл ли отказ при построении ассоциации IKE или позже, при согласовании защиты трафика. За этими двумя возможностями стоят две разные правки, и только одна из них касается флажка PFS, к которому люди тянутся первым делом.
Одно сообщение, два набора предложений
В схеме IKEv1 L2TP/IPsec два согласования идут подряд. Фаза 1 строит ассоциацию безопасности IKE из алгоритма шифрования, алгоритма целостности и группы Diffie-Hellman. Затем фаза 2 согласует, как будет защищён трафик, и требование PFS относится именно ко второму разговору.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Поскольку фазы последовательны, место сбоя подсказывает, какой список сравнивать. В этом вся диагностическая ценность сообщения, и её стоит извлечь до того, как трогать любую настройку.
Почему флажок PFS не может исправить фазу 1
Отключение PFS меняет свойство фазы 2. Если стороны так и не договорились о фазе 1, разговор ESP вообще не состоится, поэтому флажок никак не влияет на отказ, и именно поэтому его переключение даёт ту же ошибку с другой отметкой времени.
Обратная ошибка столь же распространена. Успешная ассоциация IKE не доказывает, что предложение ESP приемлемо, и уж точно не доказывает, что группа фазы 2 совпадает. Относитесь к установленному управляющему туннелю как к доказательству только о фазе 1. Люди читают зелёную строку как «туннель поднят», а затем тратят час на неверную фазу, потому что никто не сказал им, что второе согласование не началось.
Прочитайте журнал, прежде чем выбирать алгоритмы
Соберите сообщения непосредственно перед отказом из бэкенда, который действительно обслуживает соединение, и сопоставьте их с той же попыткой. Без этого сопоставления вы читаете историю другого соединения и делаете из неё выводы.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanПо этим строкам ответьте на два вопроса: установилась ли ассоциация фазы 1 и какой обмен не удался. Эти два ответа сужают поиск до одного списка атрибутов. Голое уведомление без окружающего контекста этого не может, как бы ни было заманчиво попробовать предложение из темы на форуме. Копирование рабочей строки с машины с другим бэкендом обычно заменяет один отказ другим, чуть позже.
Синтаксис бэкенда не переносится
Запишите версию NetworkManager-l2tp и версию бэкенда IPsec, прежде чем что-либо сравнивать. Libreswan и strongSwan не разделяют ни синтаксис предложений, ни одинаковые наборы алгоритмов, поэтому строка, работающая в одном, является синтаксической ошибкой в другом. Установленный бэкенд может также отказать в IKEv1 по политике, и тогда ни одно предложение никогда не будет принято.
README проекта документирует эти различия между бэкендами и держит поля фазы 1 и фазы 2 раздельно. Читайте его как документацию структуры, а не как приглашение включить каждый исторический шифр и слабую группу, потому что соединение, которое достигается только так, — это не то соединение, которое вас просили построить.
Договоритесь о наборе, затем проверьте этапы
Спросите оператора шлюза, какие наборы IKE и ESP поддерживаются и утверждены, затем сравните этот ответ с фактическими предложениями клиента, а не с его конфигурационным файлом. Если разногласие касается именно PFS фазы 2, остановитесь на поддерживаемой группе или на явно утверждённой политике без PFS. Не выводите политику из названия ошибки.
Когда единственное пересечение требует криптографии, которую организация больше не принимает, решение принадлежит шлюзу или миграции протокола. Расширение клиентской строки до тех пор, пока что-нибудь не договорится, — это способ поставить известную слабость с зелёной галочкой рядом.
После исправления реального несоответствия подтвердите установление IPsec, прежде чем исследовать L2TP и PPP, и относите любой последующий отказ аутентификации к следующему этапу. Затем проверьте продление в утверждённом процессе тестирования, потому что установление первой ассоциации ничего не говорит об остальном сроке её жизни.