NO_PROPOSAL_CHOSEN в L2TP? Сначала просканируйте шлюз

Клиент L2TP/IPsec, который срывается до запроса имени пользователя, так и не согласовал первую фазу. Просканируйте набор предложений шлюза вместо вставки строк шифрования.

Запрос имени пользователя так и не появляется, а клиент сообщает NO_PROPOSAL_CHOSEN. В этот момент учётные данные и общий секретный ключ не имеют значения, потому что стороны не договорились, как защищать фазу 1. Большинство людей в ответ вставляют строку шифрования, найденную в интернете. Сканирование шлюза отвечает на тот же вопрос с доказательствами и занимает примерно столько же времени.

Что исключает это сообщение

Отказ происходит в основном режиме, до любого обмена L2TP или PPP, поэтому ни туннель, ни база данных пользователей не опрашивались. Фаза 1 согласует шифрование, целостность и группу Diffie-Hellman. Фаза 2 согласует предложение ESP для данных. Сбой на фазе 1 нельзя исправить, изменив настройку PFS на фазе 2, и завершённая ассоциация IKE не доказывает, что предложение ESP подходит.

Запишите backend до правки синтаксиса: ipsec --version. libreswan и strongSwan принимают разные варианты написания предложения для одних и тех же алгоритмов.

Затем прочитайте отказ в контексте с помощью journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Просканируйте шлюз, чтобы узнать его набор преобразований

Сканер напрямую спрашивает шлюз, какие преобразования он будет согласовывать. Сначала остановите локальную службу IPsec, чтобы проба не конкурировала с вашим клиентом, затем прочитайте строки SA. Относитесь к списку как к доказательству о другой стороне, а не как к меню, которое нужно включить целиком.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Старые устройства часто предлагают 3DES, SHA1 и MODP1024, потому что это были значения по умолчанию на момент поставки продукта, и никто их не пересматривал. Сохраните необработанный вывод сканирования, поскольку это единственная запись о том, что другая сторона предлагала в тот день. Если это самое сильное доступное пересечение, правильная эскалация — к владельцу шлюза, а не к конфигурации клиента, которая снова включает слабую криптографию для всех.

Сопоставьте пересечение, не отключая безопасность

Введите только те преобразования, которые есть и в сканировании, и в вашей политике. Пример ниже отражает шлюз, предлагающий в фазе 1 3DES, SHA1 и MODP1024. Обратите внимание на оговорку о backend: libreswan 4.x не компилирует группу modp1024, поэтому это относится к strongSwan или к сборке libreswan с поддержкой DH2. Проверьте версию, прежде чем заключать, что клиент неисправен.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Восклицательный знак в конце фиксирует одно предложение. Используйте его, чтобы изолировать тест, а затем уберите, чтобы шлюз позже мог согласовать что-то более надёжное.

Проверьте демон и порт перед повторной попыткой

NetworkManager-l2tp запускает собственный экземпляр xl2tpd. Если системная служба уже владеет UDP 1701, клиент переходит на эфемерный исходный порт, что разрешает RFC 3193 и что некоторые серверы молча отбрасывают. Проверьте владельца сокета перед следующей попыткой.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Устаревшие сгенерированные секреты — ещё одна тихая причина. Файлы в /etc/ipsec.d/ названные в честь старого подключения, могут пережить создавший их профиль, поэтому удалите те, на которые ничего не ссылается, и повторите попытку.

Наконец, проверьте, откуда взялся совет. ipsec.conf, написанный для IKEv1 XAuth, описывает другой тип VPN, и его предложение — не единственная строка, которая окажется неверной в профиле L2TP. Запишите введённый набор преобразований рядом с профилем, чтобы следующий человек не повторял проверку.

Похожие статьи