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. Запишіть введений набір перетворень поряд із профілем, щоб наступна людина не повторювала перевірку.

Схожі статті