Afati i L2TP në Ubuntu 22.04: gabimi i tunelit të xl2tpd

Desktopi tregon një lidhje në vazhdim, IPsec raporton sukses dhe ndërfaqja PPP nuk shfaqet kurrë. Në syslog i njëjti numër tuneli përsëritet derisa përpjekja skadon në UDP 1701. Përpara se të redaktoni çelësin e përbashkët paraprak ose konfigurimin e serverit, njihni këtë formë: në Ubuntu 22.04 zakonisht është një regresion pakete në xl2tpd, dhe serveri ishte i saktë gjatë gjithë kohës.

Çfarë ju tregon çifti i rreshtave që përsëritet

Një sesion që dështon printon një çift rreshtash në intervale të rregullta: daemoni nuk gjen një tunel për një mesazh kontrolli në hyrje, pastaj hedh identifikuesit e thirrjes dhe të tunelit që iu dhanë. Më vonë numëruesi i përpjekjeve arrin kufirin dhe lidhja mbyllet me një afat në portin 1701. Adresat dhe identifikuesit janë të rastësishëm; forma është ajo që ka rëndësi. IKE përfundoi, trafiku i kontrollit L2TP mbërriti dhe daemoni nuk arriti ta lidhë me një tunel që e kishte krijuar tashmë.

Prandaj defekti ndodhet midis kontrollit L2TP dhe PPP. Asgjë për sekretin, opsionet PPP ose nënrrjetin e largët nuk është provuar ende.

Konfirmoni që IPsec ka pasur vërtet sukses

Dy kontrolle e ndajnë këtë nga një problem kredencialesh, dhe të dyja vijnë përpara çdo ndryshimi pakete.

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

Dalja e statusit liston lidhjen dhe gjendjen e saj, dhe një tunel i vendosur do të thotë që faza një dhe faza dy përfunduan. Një rresht log për një çelës të përbashkët që mungon tregon vetëm sekretin, pra ndaloni dhe rregulloni fillimisht atë. Kur IPsec është vendosur dhe afati i L2TP shfaqet ende, daemoni mbetet i dyshuari. Ruani rreshtat e saktë të një përpjekjeje në vend të një dite të tërë përpjekjesh.

Kontrolloni ndërtimin e xl2tpd, jo emrin e versionit

Ndërtimi jammy i xl2tpd 1.3.16 nga Ubuntu aktivizoi optimizimin në kohën e lidhjes, gjë që prishi analizën e identifikuesit të tunelit në përgjigjen SCCRP të serverit. Daemoni pastaj hedh paketat e kontrollit për një tunel që e krijoi vetë. Vargu i versionit ka më shumë rëndësi se emri i shpërndarjes.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Paketa e korrigjuar është 1.3.16-1ubuntu0.1, pra një ndërtim pa atë prapashtesë është më i vjetër se korrigjimi. Dalja e politikës tregon se cilin kandidat do të instalonte një përditësim, dhe lista e mbajtjeve shpjegon pse një korrigjim nuk ka mbërritur. Aty ku paketa është e disponueshme, përditësojeni dhe rilidhuni përmes profilit normal në vend që t'i redaktoni skedarët me dorë. Mos rindërtoni module dhe mos ndryshoni sekretin ndërsa ndërtimi i vjetër është ende i instaluar.

Verifikoni PPP pas ndryshimit

Një përditësim i suksesshëm vërtetohet në shtresën që ishte prishur. Kontrolloni që PPP u ngrit, jo vetëm që ikona ndryshoi.

ip -4 addr show ppp0
ip route | grep ppp

Lista e ndërfaqeve duhet të tregojë një adresë lokale dhe një adresë kolegu, dhe tabela e rrugëzimit duhet të mbajë prefikset e tunelit. Syslog duhet të tregojë tunelin e pranuar dhe pppd që raporton të dyja adresat, pa rreshta të përsëritur për tunel të pagjetur. Nëse PPP është lart dhe trafiku ende dështon, shikoni më pas rrugëzimin ose MTU, sepse faza L2TP ka përfunduar punën e saj. Shënoni versionin e paketës që funksionon në shënimet e makinës, që një riinstalim i ardhshëm të mos rikthejë ndërtimin e prishur.

Aty ku paketa e korrigjuar nuk është e disponueshme, alternativat e dokumentuara janë një ndërtim lokal nga burimi 1.3.16 ose 1.3.17, një kalim në kl2tpd ose një zbritje e fiksuar. Secila sjell një kosto mirëmbajtjeje që ia vlen të shënohet.