Timeout ng L2TP sa Ubuntu 22.04: ang bug ng tunnel ng xl2tpd

Nagpapakita ang desktop ng koneksyong nagaganap, nag-uulat ng tagumpay ang IPsec, at hindi kailanman lumilitaw ang interface ng PPP. Sa syslog, inuulit ang parehong numero ng tunnel hanggang sa mag-timeout ang pagtatangka sa UDP 1701. Bago i-edit ang paunang ibinahaging key o ang configuration ng server, kilalanin ang hugis na ito: sa Ubuntu 22.04, karaniwang regresyon ito ng pakete sa xl2tpd, at tama ang server sa buong panahon.

Ano ang sinasabi sa iyo ng paulit-ulit na pares ng log

Ang sesyong nabibigo ay nagpi-print ng pares ng linya sa regular na pagitan: hindi makahanap ang daemon ng tunnel para sa papasok na control message, pagkatapos ay itinatapon ang mga identifier ng tawag at tunnel na ibinigay dito. Sa kalaunan, naaabot ng counter ng muling pagtatangka ang limitasyon nito at nagsasara ang koneksyon sa timeout sa port 1701. Ang mga address at identifier ay hindi mahalaga; ang hugis ang mahalaga. Natapos ang IKE, dumating ang control traffic ng L2TP, at nabigo ang daemon na iugnay ito sa tunnel na ginawa na nito.

Kaya ang depekto ay nasa pagitan ng kontrol ng L2TP at PPP. Wala pang nasubukan tungkol sa secret, mga opsyon ng PPP o ang malayong subnet.

Kumpirmahin na talagang nagtagumpay ang IPsec

Dalawang pagsusuri ang naghihiwalay nito sa problema sa kredensyal, at pareho silang bago ang anumang pagbabago sa pakete.

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

Inililista ng status output ang koneksyon at ang estado nito, at ang naitatag na tunnel ay nangangahulugang natapos ang phase one at phase two. Ang isang linya ng log tungkol sa nawawalang shared key ay tumutukoy lamang sa secret, kaya huminto at ayusin muna iyon. Kapag naitatag ang IPsec at lumilitaw pa rin ang timeout ng L2TP, ang daemon ang natitirang pinaghihinalaan. Itago ang eksaktong mga linya mula sa isang pagtatangka sa halip na buong araw ng mga muling pagtatangka.

Suriin ang build ng xl2tpd, hindi ang pangalan ng release

Ang jammy build ng Ubuntu ng xl2tpd 1.3.16 ay nag-enable ng link-time optimization, na sumira sa pag-parse ng tunnel identifier sa SCCRP reply ng server. Itinatapon na ng daemon ang mga control packet para sa tunnel na siya mismo ang gumawa. Ang version string ay mas mahalaga kaysa sa pangalan ng distribution.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Ang naitamang pakete ay 1.3.16-1ubuntu0.1, kaya ang build na walang suffix na iyon ay mas matanda kaysa sa pagtatama. Ipinapakita ng policy output kung aling kandidato ang i-install ng upgrade, at ipinapaliwanag ng hold list kung bakit hindi dumating ang pagtatama. Kung saan available ang pakete, i-upgrade ito at kumonekta muli sa normal na profile sa halip na i-edit ang mga file nang manu-mano. Huwag muling buuin ang mga module o baguhin ang secret habang naka-install pa ang lumang build.

I-verify ang PPP pagkatapos ng pagbabago

Ang matagumpay na upgrade ay napatutunayan sa layer na sira. Suriin na umangat ang PPP, hindi lamang na nagbago ang icon.

ip -4 addr show ppp0
ip route | grep ppp

Ang listahan ng interface ay dapat magpakita ng lokal at peer address, at ang route table ay dapat magdala ng mga prefix ng tunnel. Dapat ipakita ng syslog na tinanggap ang tunnel at iniuulat ng pppd ang parehong address, nang walang paulit-ulit na linyang tunnel-not-found. Kung nakaupo ang PPP at nabibigo pa rin ang trapiko, tingnan sa susunod ang routing o MTU, dahil natapos na ng yugto ng L2TP ang trabaho nito. Itala ang gumaganang bersyon ng pakete sa mga tala ng makina, upang hindi maibalik ng muling pag-install sa hinaharap ang sirang build.

Kung saan hindi available ang naitamang pakete, ang mga dokumentadong alternatibo ay isang lokal na source build ng 1.3.16 o 1.3.17, isang paglipat sa kl2tpd, o isang naka-pin na downgrade. Ang bawat isa ay may gastos sa pagpapanatili na sulit itala.