Журнал отладки 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

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