Изтичане на времето при L2TP в Ubuntu 22.04: грешката в тунела на xl2tpd

Работният плот показва връзка в ход, 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 или фиксирано понижаване. Всяка от тях носи разход за поддръжка, който си струва да бъде записан.