Тайм-аут L2TP в Ubuntu 22.04: ошибка туннеля xl2tpd
IPsec подключается, PPP не запускается, а xl2tpd повторяет туннель, который не может сопоставить. Проверьте установленную сборку, прежде чем трогать PSK или сервер.
Рабочий стол показывает устанавливающееся соединение, IPsec сообщает об успехе, а интерфейс PPP так и не появляется. В системном журнале один и тот же номер туннеля повторяется, пока попытка не завершится тайм-аутом на UDP 1701. Прежде чем править предварительно общий ключ или конфигурацию сервера, распознайте эту форму: в Ubuntu 22.04 это обычно регрессия пакета в xl2tpd, и сервер всё это время был в порядке.
О чём говорит повторяющаяся пара строк в журнале
Неудачная сессия печатает пару строк через равные интервалы: демон не находит туннель для входящего управляющего сообщения, затем выводит идентификаторы вызова и туннеля, которые получил. Позже счётчик повторных попыток достигает предела, и соединение закрывается по тайм-ауту порта 1701. Адреса и идентификаторы случайны; важна форма. IKE завершился, управляющий трафик L2TP пришёл, а демон не смог связать его с туннелем, который уже создал.
Значит, неисправность находится между управлением L2TP и PPP. О секрете, параметрах PPP и удалённой подсети ещё ничего не проверено.
Убедитесь, что IPsec действительно завершился успешно
Две проверки отделяют это от проблемы с учётными данными, и обе выполняются до любого изменения пакета.
ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"Вывод состояния перечисляет соединение и его состояние, а установленный туннель означает, что первая и вторая фазы завершены. Строка журнала об отсутствующем общем ключе указывает только на секрет, поэтому остановитесь и сначала исправьте это. Когда IPsec установлен, а тайм-аут L2TP всё ещё появляется, демон остаётся подозреваемым. Сохраните точные строки одной попытки вместо целого дня повторных попыток.
Проверяйте сборку xl2tpd, а не название выпуска
Сборка xl2tpd 1.3.16 в jammy от Ubuntu включила оптимизацию времени компоновки, что сломало разбор идентификатора туннеля в ответе SCCRP сервера. Затем демон отбрасывает управляющие пакеты для туннеля, который создал сам. Строка версии важнее названия дистрибутива.
dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showholdИсправленный пакет — 1.3.16-1ubuntu0.1, поэтому сборка без этого суффикса предшествует исправлению. Вывод политики показывает, какого кандидата установит обновление, а список удержаний объясняет, почему исправление не пришло. Там, где пакет доступен, обновите его и переподключитесь через обычный профиль вместо ручного редактирования файлов. Не пересобирайте модули и не меняйте секрет, пока старая сборка ещё установлена.
Проверьте PPP после изменения
Успешное обновление доказывается на том уровне, который был сломан. Проверьте, что PPP поднялся, а не только что значок изменился.
ip -4 addr show ppp0
ip route | grep pppСписок интерфейсов должен показывать локальный адрес и адрес партнёра, а таблица маршрутов должна нести префиксы туннеля. В журнале должно быть видно, что туннель принят и pppd сообщает оба адреса, без повторяющихся строк о ненайденном туннеле. Если PPP поднят, а трафик всё ещё не идёт, смотрите дальше маршрутизацию или MTU, потому что этап L2TP уже выполнил свою работу. Запишите рабочую версию пакета в заметки машины, чтобы будущая переустановка не вернула сломанную сборку.
Там, где исправленный пакет недоступен, документированные альтернативы — локальная сборка из исходников 1.3.16 или 1.3.17, переход на kl2tpd или закреплённый откат. Каждая несёт затраты на сопровождение, которые стоит записать.