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, не името на изданието

Градењето jammy на Ubuntu на xl2tpd 1.3.16 вклучи оптимизација при поврзување, што го расипа парсирањето на идентификаторот на тунелот во одговорот 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 или закачено намалување на верзијата. Секоја носи трошок за одржување што вреди да се запише.