L2TP NO_PROPOSAL_CHOSEN: яка фаза насправді не вдалася?

Повідомлення каже, що пропозицію відхилено, але не яку саме. Прочитайте журнал бекенду, щоб визначити фазу, потім порівняйте набори з тим, хто адмініструє шлюз.

NO_PROPOSAL_CHOSEN надходить раніше, ніж перевіряється будь-яке ім'я користувача PPP, і це корисний факт, а також причина, чому повідомлення вводить в оману. Воно повідомляє, що одна сторона відхилила пропозицію; воно не повідомляє, який параметр не збігся, і нічого не каже про те, чи відмова сталася під час побудови асоціації IKE або пізніше, під час переговорів про захист трафіку. За цими двома можливостями стоять дві різні правки, і лише одна з них стосується прапорця PFS, до якого люди тягнуться першими.

Одне повідомлення, два набори пропозицій

У схемі IKEv1 L2TP/IPsec два узгодження йдуть послідовно. Фаза 1 будує асоціацію безпеки IKE з алгоритму шифрування, алгоритму цілісності та групи Diffie-Hellman. Далі фаза 2 узгоджує, як захищатиметься трафік, і вимога PFS належить саме тій другій розмові.

PhaseWhat is agreedWhat a rejection here means
Phase 1Encryption, integrity, DH group for the IKE SANo management tunnel exists, so nothing later can run
Phase 2ESP transforms plus the PFS group policyThe 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, і ставтеся до будь-якої пізнішої відмови автентифікації як до такої, що належить наступному етапу. Потім перевірте поновлення в затвердженому процесі тестування, бо встановлення першої асоціації нічого не каже про решту її життя.

Схожі статті