Працоўны стол паказвае злучэнне ў працэсе, 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 ці замацаваны адкат. Кожная з іх нясе выдатак на суправаджэнне, які варта запісаць.

Падобныя артыкулы