L2TP sa Ubuntu 24.04 sira: xl2tpd o go-l2tp daemon?

Tahimik na pinalitan ng Ubuntu 24.04 ang daemon sa likod ng L2TP plugin ng NetworkManager. Ginamit ng lumang landas ang xl2tpd; ang mas bagong packaging ay nagdala ng implementasyon sa Go na gumagawa ng daemon na tinatawag na kl2tpd. Sinisimulan ng plugin ang nakainstall, kaya maaaring palitan ng upgrade ang daemon nang hindi hinahawakan ang iyong profile o mga kredensyal. Iyon ang buong sira: isang control message na hindi kinikilala ng bagong daemon.

Inuugnay ng plugin ang IPsec, L2TP at PPP, pagkatapos ay ibinibigay ang nagawang interface sa NetworkManager. Hindi nito mismo ipinapatupad ang L2TP.

Ang plugin ay tagapag-ugnay, hindi daemon

network-manager-l2tp ang nagpapatakbo ng IPsec helper, isang L2TP daemon at PPP, at ikinokonekta ang interface sa pamamahala ng koneksyon ng desktop. Sa loob ng maraming taon ang daemon ay xl2tpd, at bawat tutorial na nagbanggit ng configuration nito ay nagmana ng palagay na iyon. Kalaunan tinanggap ng packaging ng Debian ang alinman sa dalawang implementasyon, at ang 24.04 ay nag-install ng bersyon sa Go, na nagbibigay ng kl2tpd. Walang field sa profile ang nagtatala kung aling daemon ang tumakbo dati, kaya nananatiling di-nakikita ang pagpapalit hanggang may mensaheng tanggihan.

Ang makina na may parehong package ay maaaring hindi pa rin patakbuhin ang inaasahan mo. Ang pagpili ay desisyon ng plugin, hindi ng gabay na sinundan mo.

Basahin ang yugto bago pumili ng pag-aayos

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd _COMM=charon _COMM=pluto

Iugnay ang isang pagtatangka sa mga helper sa halip na magtiwala sa notification ng desktop. Ipinapakita ng query na iyon kung saan huminto ang pagkakasunod-sunod, at ipinapakita ng dpkg -l kung aling implementasyon ang nakainstall. Ang pagkabigo na lumilitaw pagkatapos maitatag ang IPsec peer, at nagbanggit ng control message o hindi kilalang attribute, ay tumuturo sa daemon. Ang pagkabigo bago umiral ang tunnel ay nangangahulugang hindi naabot ang daemon.

Ang hindi pagtutugma ng pre-shared key ay nagtatapos sa yugto ng IPsec at pinangalanan ang peer. Ang problema sa kredensyal ng PPP ay lumilitaw kapag nakaangat ang tunnel at karaniwang may dalang nababasang pagtanggi ng CHAP o MS-CHAP. Pareho silang nakikita sa parehong query, at magkaibang problema sila.

Dalawang landas, at hindi sila naghahalo

sudo apt install xl2tpd
sudo apt purge go-l2tp

Inilalagay ng pares na iyon ang xl2tpd at pagkatapos ay tinatanggal ang Go daemon, hinahayaan ang plugin na pumili ng implementasyon na ang diyalekto ay sinasalita ng gateway. Mahalaga ang pagkakasunod-sunod: umaasa ang plugin sa isa o sa isa pang implementasyon, kaya ang pagtanggal muna ng Go package ay ibinabagsak din ang plugin. Pinapanatili ng ikalawang landas ang Go daemon at lumilipat sa mas bagong build na nauunawaan ang mensahe, na karaniwang nangangahulugang PPA ng maintainer sa halip na bersyon mula sa archive. Sa pinamamahalaang fleet, mas madaling bigyang-katwiran ang pag-pin ng PPA kaysa turuan ang mga user na mag-alis ng package.

Huwag pagsamahin ang dalawa sa isang pagbabago. Pagkatapos ay hindi mo masasabi kung aling kalahati ang nakatulong kapag may nabigong mamaya, at maaaring maibalik ng hinaharap na upgrade ang package na inalis mo lang.

Ilagay sa ticket ang binary ng daemon, ang bersyon nito at ang eksaktong mensahe. Walang makakagawa muli ng ulat na nagsasabi lamang na sira ang L2TP pagkatapos ng release, samantalang ang pinangalanang attribute at bersyon ng package ay nagbibigay sa kanila ng simula.

Tatlong bagay na hindi ito

Hindi ito problema sa profile, dahil gumana ang parehong profile sa 22.04 sa parehong gateway. Hindi ito nawawalang ruta o pagbabago sa firewall, dahil nabibigo ang mga iyon sa ibang lugar na may ibang ebidensya. Hindi rin ito naaayos ng muling pag-install ng plugin, dahil pinipili muli ang parehong daemon. Pinangalanan ng kapaki-pakinabang na paglalarawan ang daemon at ang mensaheng tinanggihan nito.

Ang pag-aayos sa panig ng gateway ay ang isa pang lehitimong kinalabasan. Ang firmware na humihinto sa pagpapadala ng attribute ay nakakaligtas sa bawat upgrade ng kliyente, samantalang ang naka-pin na package ay nakakaligtas sa susunod na release ng distribusyon kung may nakakaalala kung bakit ito naka-pin.

Ihambing ang dalawang landas sa gastos sa pagpapanatili sa halip na bilis. Pareho silang maaaring gumana; isa lang ang nag-aalis ng pagkakaiba sa diyalekto.