Робочий стіл показує з'єднання, що встановлюється, 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 чи закріплений відкат. Кожна несе витрати на супровід, які варто записати.

Схожі статті