Журнал налагодження L2TP порожній? Помилка, ймовірно, у journal

Ви запускаєте допоміжну програму L2TP з налагодженням, дивитеся в термінал, і вона зупиняється, не показавши нічого корисного. Це не зламаний прапорець налагодження. З’єднання NetworkManager L2TP — це чотири взаємодійні процеси, і лише деякі з них пишуть у термінал, за яким ви спостерігаєте. Решта доказів — у journal, на відстані одного фільтра.

Чотири процеси, два місця запису

З’єднання починається з IPsec — це libreswan або strongSwan залежно від встановлення. Далі демон L2TP, традиційно xl2tpd, а в деяких збірках kl2tpd, веде тунель. Нарешті pppd займається автентифікацією й адресацією всередині нього.

Допоміжна служба координує ці частини й друкує власний прогрес. Демон IPsec і pppd зазвичай звітують через системний journal, тому термінал показує збій з’єднання, а причина лежить у файлі, який ви не відкривали.

Цей поділ також пояснює, чому помилка PSK і помилка пароля виглядають з робочого столу однаково: обидві дають загальний розрив, а етап, який не пройшов, видно лише у виводі окремого процесу. Саме тому journal тут важливий. Одне загальне повідомлення на робочому столі, чотири можливі автори за ним.

Зберіть одну спробу, потім читайте порядок

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

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

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Повторювані поля в одному виклику вибирають об’єднання цих процесів, що зберігає послідовність у часовому порядку. У системі на базі Debian еквівалентний запит — dpkg -L; сенс у тому, щоб знайти, де допоміжна програма насправді живе, перш ніж запускати її вручну.

Три умови визначають наступний крок

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

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

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

Варто також підтвердити, який бекенд IPsec встановлено, перш ніж чіпати налаштування налагодження. Опція журналювання, написана для strongSwan, нічого не робить, коли працює libreswan, і з’єднання продовжить збоїти в тому самому місці, поки ви редагуєте файл, який ніхто не читає.

Режим налагодження залишає файли

Оригінальний робочий процес налагодження запускає службу вручну з прапорцем налагодження, і цей режим може залишити згенеровані файли конфігурації часу виконання на місці, коли з’єднання завершується.

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

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

Потім відновіть звичайну допоміжну програму

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

Потім перевірте результат на тому рівні, який не пройшов, а не на значку робочого столу:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

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