Ubuntu 22.04 L2TP-tydsverloop: die xl2tpd-tonnelgogga
IPsec verbind, PPP begin nooit nie, en xl2tpd herhaal 'n tonnel wat hy nie kan pas nie. Kontroleer die geïnstalleerde bou voordat jy aan die PSK of die bediener raak.
Die rekenaar wys dat 'n verbinding aan die gang is, IPsec rapporteer sukses, en die PPP-koppelvlak verskyn nooit nie. In die stelsellog herhaal dieselfde tonnelnommer hom totdat die poging op UDP 1701 uittyd. Voordat jy die vooraf-gedeelde sleutel of die bedienerkonfigurasie wysig, herken hierdie patroon: op Ubuntu 22.04 is dit gewoonlik 'n pakketterugresessie in xl2tpd, en die bediener was die hele tyd korrek.
Wat die herhalende stelsellogpaar jou vertel
'n Mislukte sessie druk 'n paar reëls met gereelde tussenposes: die daemon kan nie 'n tonnel vir 'n inkomende beheerboodskap vind nie, en gooi dan die oproep- en tonnelidentifiseerders uit wat dit ontvang het. Later bereik die herpogingsteller sy limiet en sluit die verbinding met 'n time-out op poort 1701. Adresse en identifiseerders is toevallig; die patroon is wat saak maak. IKE het voltooi, L2TP-beheerverkeer het aangekom, en die daemon kon dit nie met 'n tonnel assosieer wat hy reeds geskep het nie.
Die fout lê dus tussen L2TP-beheer en PPP. Niks aan die geheim, die PPP-opsies of die afgeleë subnet is nog getoets nie.
Bevestig dat IPsec werklik geslaag het
Twee kontroles skei dit van 'n geloofsbriefprobleem, en albei hoort voor enige pakketverandering.
ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"Die statusuitvoer lys die verbinding en sy toestand, en 'n gevestigde tonnel beteken fase een en fase twee het voltooi. 'n Logreël oor 'n ontbrekende gedeelde sleutel wys op die geheim en niks anders nie, so stop en maak dit eerste reg. Wanneer IPsec gevestig is en die L2TP-tydsverloop steeds verskyn, is die daemon die oorblywende verdagte. Hou die presiese reëls van een poging eerder as 'n hele dag se herpogings.
Kontroleer die xl2tpd-bou, nie die vrystellingsnaam nie
Ubuntu se jammy-bou van xl2tpd 1.3.16 het skakeltyd-optimalisering geaktiveer, wat die ontleding van die tonnelidentifiseerder in die bediener se SCCRP-antwoord gebreek het. Die daemon verwerp dan beheerboodskappe vir 'n tonnel wat hy self geskep het. Die weergawekerstring maak meer saak as die verspreidingsnaam.
dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showholdDie reggestelde pakket is 1.3.16-1ubuntu0.1, so 'n bou sonder daardie agtervoegsel is ouer as die regstelling. Die beleidsuitvoer wys watter kandidaat 'n opgradering sou installeer, en die houlys verduidelik waarom 'n regstelling nie aangekom het nie. Waar die pakket beskikbaar is, gradeer dit op en koppel weer deur die normale profiel eerder as om lêers met die hand te wysig. Moenie modules herbou of die geheim verander terwyl die ou bou nog geïnstalleer is nie.
Verifieer PPP ná die verandering
'n Suksesvolle opgradering word bewys op die laag wat gebreek was. Kontroleer dat PPP opgekom het eerder as net dat die ikoon verander het.
ip -4 addr show ppp0
ip route | grep pppDie koppelvlaklys moet 'n plaaslike en 'n eweknie-adres wys, en die roetetabel moet die tonnel se voorvoegsels dra. Die stelsellog moet wys dat die tonnel aanvaar is en pppd albei adresse rapporteer, sonder herhaalde tonnel-nie-gevind-reëls. As PPP op is en verkeer steeds misluk, kyk volgende na roetering of MTU, want die L2TP-stadium het sy werk gedoen. Teken die werkende pakketweergawe in die masjiennotas aan, sodat 'n toekomstige herinstallasie nie die gebreekte bou terugbring nie.
Waar die reggestelde pakket nie beskikbaar is nie, is 'n plaaslike bronbou van 1.3.16 of 1.3.17, 'n oorskakeling na kl2tpd, of 'n vasgepen afgradering die gedokumenteerde alternatiewe. Elkeen bring 'n instandhoudingskoste mee wat die moeite werd is om neer te skryf.