L2TP-tempoŝuo en Ubuntu 22.04: la tunela cimo de xl2tpd

La labortablo montras konekton en progreso, IPsec raportas sukceson, kaj la PPP-interfaco neniam aperas. En la sistema protokolo la sama tunela numero ripetiĝas ĝis la provo tempas for sur UDP 1701. Antaŭ ol redakti la antaŭe kunhavigitan ŝlosilon aŭ la servilan agordon, rekonu ĉi tiun formon: en Ubuntu 22.04 ĝi kutime estas pakaĵa regreso en xl2tpd, kaj la servilo estis ĝusta la tutan tempon.

Kion diras al vi la ripetiĝanta protokola paro

Malsukcesa sesio presas paron da linioj je regulaj intervaloj: la demono ne trovas tunelon por alvenanta kontrola mesaĝo, poste elĵetas la vokajn kaj tunelajn identigilojn kiujn ĝi ricevis. Poste la reprova nombrilo atingas sian limon kaj la konekto fermiĝas per tempoŝuo ĉe pordo 1701. Adresoj kaj identigiloj estas hazardaj; la formo gravas. IKE finiĝis, kontrola trafiko L2TP alvenis, kaj la demono malsukcesis ligi ĝin al tunelo kiun ĝi jam kreis.

Do la difekto troviĝas inter L2TP-kontrolo kaj PPP. Nenio pri la sekreto, la PPP-opcioj aŭ la fora subreto ankoraŭ estis provita.

Konfirmu, ke IPsec vere sukcesis

Du kontroloj apartigas ĉi tion de problema akreditaĵo, kaj ambaŭ apartenas antaŭ iu ajn pakaĵa ŝanĝo.

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

La statusa eligo listigas la konekton kaj ĝian staton, kaj establita tunelo signifas, ke fazo unu kaj fazo du finiĝis. Protokola linio pri mankanta kunhavigita ŝlosilo indikas nur la sekreton, do haltu kaj unue riparu tion. Kiam IPsec estas establita kaj la L2TP-tempoŝuo ankoraŭ aperas, la demono restas la suspektato. Konservu la precizajn liniojn de unu provo anstataŭ tuta tago da reprovoj.

Kontrolu la konstruaĵon de xl2tpd, ne la eldonan nomon

La jammy-konstruaĵo de Ubuntu por xl2tpd 1.3.16 ŝaltis ligtempan optimumigon, kiu rompis la analizon de la tunela identigilo en la SCCRP-respondo de la servilo. La demono tiam forĵetas kontrolpakaĵojn por tunelo kiun ĝi mem kreis. La versia ĉeno pli gravas ol la distribua nomo.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

La korektita pakaĵo estas 1.3.16-1ubuntu0.1, do konstruaĵo sen tiu sufikso antaŭas la korekton. La politika eligo montras kiun kandidaton ĝisdatigo instalus, kaj la tenlisto klarigas kial korekto ne alvenis. Kie la pakaĵo disponeblas, ĝisdatigu ĝin kaj rekonektiĝu per la normala profilo anstataŭ permane redakti dosierojn. Ne rekonstruu modulojn kaj ne ŝanĝu la sekreton dum la malnova konstruaĵo ankoraŭ estas instalita.

Kontrolu PPP post la ŝanĝo

Sukcesa ĝisdatigo pruviĝas ĉe la tavolo kiu estis rompita. Kontrolu ke PPP ekfunkciis, ne nur ke la piktogramo ŝanĝiĝis.

ip -4 addr show ppp0
ip route | grep ppp

La interfaca listo devus montri lokan kaj kunulan adreson, kaj la voja tabelo devus porti la prefiksojn de la tunelo. La sistema protokolo devus montri la tunelon akceptita kaj pppd raportanta ambaŭ adresojn, sen ripetitaj linioj pri tunelo ne trovita. Se PPP funkcias kaj trafiko ankoraŭ malsukcesas, rigardu poste enkursigon aŭ MTU, ĉar la L2TP-etapo finis sian taskon. Notu la funkciantan pakaĵan version en la maŝinaj notoj, por ke estonta reinstalo ne restarigu la rompitan konstruaĵon.

Kie la korektita pakaĵo ne disponeblas, la dokumentitaj alternativoj estas loka fonta konstruaĵo de 1.3.16 aŭ 1.3.17, ŝanĝo al kl2tpd aŭ fiksita malaltigo. Ĉiu portas prizorgan koston indan je notado.