PSK для L2TP/IPsec відхилено: спершу діалог, потім файли

Ви вставляєте заздалегідь спільний ключ із повідомлення адміністратора в діалог NetworkManager, ставите прапорець, щоб його показати, і він збігається символ у символ. З'єднання все одно завершується помилкою автентифікації до того, як піднімається тунель. Уперше побачивши це, я припустив, що ключ неправильний; він не був. Ще дві речі визначають, що демон насправді читає: файл секретів, який плагін записує для цього з'єднання, і те, чи пройшло значення через діалог без змін.

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

Почніть із діалогу, але не довіряйте полю

Відкрийте вкладку IPsec з'єднання і введіть ключ заново замість вставлення. Ключ, скопійований із повідомлення в чаті, PDF або менеджера паролів, може прийти з переведенням рядка в кінці, якого поле не показує, а видимі символи все одно виглядають правильними.

Натисніть кнопку показу пароля і подивіться на кінець рядка, а не на середину. Якщо курсор залишає порожній рядок під текстом, видаліть його і введіть останній символ заново. Ця одна правка вирішує разючу частину таких звернень і коштує менше, ніж читання будь-якого журналу.

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

Простежте ключ усередину /etc/ipsec.d

Плагін ніколи не передає PSK демону IPsec як аргумент у командному рядку. Натомість він зберігає значення у файлі секретів і домагається, щоб демон цей файл підключив, додавши рядок include у /etc/ipsec.secrets, якщо його немає. Те, що тримає діалог, це вхідні дані для створеного файлу, а не значення, яке використовується.

Перелічіть, що є, перш ніж щось змінювати:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Старіші випуски плагіна писали по одному файлу на з'єднання, названому за UUID з'єднання, наприклад /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Видалення профілю в аплеті не видаляє цей файл надійно. Якщо старий файл від попереднього сервера все ще лежить на диску і все ще підключений, демон може вибрати секрет, що належить профілю, яким ви більше не користуєтеся, і з'єднання зривається, хоча видиме поле правильне.

Зрозумійте, що зміна 1.2.12 зробила з оновленнями

Версія плагіна 1.2.12 замінила файли секретів для кожного з'єднання одним спільним файлом, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Оновлення не прибирає старіші файли за UUID, а наявний рядок include /etc/ipsec.d/*.secrets усе ще їх підключає. Версія 1.2.16 змінила обробку типових пропозицій, а не розташування секретів.

Ця історія пояснює, чому дві машини з начебто однаковим профілем поводяться по-різному. Ключ однаковий; набір файлів, які підключає демон, ні. Коли прибираєте осиротілий файл, відсуньте його вбік, а не видаляйте, підтвердьте з'єднання і вже потім видаліть, коли робочий стан зафіксовано. Перейменування зберігає старе значення відновлюваним, якщо з'ясується, що збій в іншому місці.

Відокремте символи, які формат зберігання не може вмістити

Документація strongSwan щодо рядка спільного секрету зазначає, що значення не може містити переведення рядка або символ подвійної лапки. Ключ, вставлений із документа, може нести будь-що з цього без жодної видимої різниці у звичайному діалозі.

Від 1.2.12 збережене значення вже не простий текст. Плагін кодує PSK у base64 до того, як воно потрапить у файл, і примітки до випуску називають це кодування причиною, чому подвійна лапка тепер прийнятна в ключі. Тому лапка, введена в полі, є представною; те саме не стосується кожного керівного символу.

Довжина це інше обмеження. У програмному забезпеченні L2TP/IPsec немає універсального мінімуму: деякі клієнти приймають ключі коротші за двадцять символів, а деякі шлюзи вимагають мінімум. Якщо короткий ключ відхилено, правило належить політиці сервера або перевірці цього клієнта, і підвищення чогось локально цього не змінить.

Прочитайте, який рівень автентифікації не пройшов

Спочатку виконайте ipsec --version, бо strongSwan і Libreswan використовують різні назви файлів і синтаксис, і порада для одного може зашкодити іншому. Потім прочитайте стадію збою з повідомлення клієнта або журналу демона: скарга на заздалегідь спільний ключ це інша подія, ніж відхилені ім'я користувача й пароль.

PSK автентифікує кінці тунелю. Ім'я користувача й пароль автентифікують людину всередині L2TP, і PPP займається ними після того, як асоціація IPsec піднята. Правильний PSK із хибним обліковим записом усе одно не працює, і зміна запису не виправить ключ, який демон так і не прочитав правильно.

Закриваючи заявку, запишіть усі чотири пункти: версію плагіна, використовуваний файл секретів, чи ключ було введено заново чи вставлено, і рівень, названий у помилці. Тоді будь-хто, хто повторить цей шлях пізніше, зможе одразу перейти до різниці між робочою та збійною машиною.