L2TP-tidsavbrot på Ubuntu 22.04: xl2tpd-tunnelfeilen

Skrivebordet viser ei tilkopling som pågår, IPsec rapporterer suksess, og PPP-grensesnittet dukkar aldri opp. I syslog vert det same tunnelnummeret gjenteke til forsøket får tidsavbrot på UDP 1701. Før du redigerer den førhandsdelte nøkkelen eller serverkonfigurasjonen, kjenn att dette mønsteret: på Ubuntu 22.04 er det vanlegvis ein pakkeregresjon i xl2tpd, og serveren var korrekt heile tida.

Kva det gjentekne syslog-paret fortel deg

Ei økt som feilar skriv ut eit par linjer med jamne mellomrom: daemonen finn ikkje ein tunnel for ei innkomande kontrollmelding, og dumpar deretter kall- og tunnel-ID-ane han fekk. Seinare når nytt forsøk-teljaren grensa si, og tilkoplinga vert lukka med tidsavbrot på port 1701. Adresser og ID-ar er tilfeldige; mønsteret er det som betyr noko. IKE fullførte, L2TP-kontrolltrafikk kom inn, og daemonen klarte ikkje å knyte han til ein tunnel han alt hadde oppretta.

Feilen ligg altså mellom L2TP-kontroll og PPP. Ingenting om hemmelegheita, PPP-alternativa eller det eksterne subnettet er prøvd enno.

Stadfest at IPsec verkeleg lukkast

To sjekkar skil dette frå eit legitimasjonsproblem, og begge høyrer heime før kvar pakkeendring.

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

Statusutdata listar tilkoplinga og tilstanden, og ein etablert tunnel tyder at fase éin og fase to er fullførte. Ei logglinje om ein manglande delt nøkkel peikar berre på hemmelegheita, så stopp og rett det først. Når IPsec er etablert og L2TP-tidsavbrotet framleis viser seg, er daemonen den gjenverande mistenkte. Ta vare på dei nøyaktige linjene frå eitt forsøk i staden for ein heil dag med nye forsøk.

Sjekk xl2tpd-bygget, ikkje utgivingsnamnet

Ubuntu sitt jammy-bygg av xl2tpd 1.3.16 slo på lenkjetidsoptimalisering, noko som braut analysen av tunnel-ID-en i SCCRP-svaret frå serveren. Daemonen kastar då kontrollpakkar for ein tunnel han sjølv oppretta. Versjonsstrengen betyr meir enn distribusjonsnamnet.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Den retta pakken er 1.3.16-1ubuntu0.1, så eit bygg utan den enden er eldre enn rettinga. Policy-utdata viser kva kandidat ei oppgradering ville installere, og hald-lista forklarar kvifor ei retting ikkje har kome. Der pakken er tilgjengeleg, oppgrader han og kople til på nytt via den vanlege profilen i staden for å redigere filer for hand. Ikkje bygg modular på nytt og ikkje endre hemmelegheita medan det gamle bygget framleis er installert.

Stadfest PPP etter endringa

Ei vellukka oppgradering vert prova på laget som var brote. Sjekk at PPP kom opp, ikkje berre at ikonet endra seg.

ip -4 addr show ppp0
ip route | grep ppp

Grensesnittlista bør vise ei lokal adresse og ei peer-adresse, og rutetabellen bør bere prefiksa til tunnelen. Syslog bør vise at tunnelen vart godteken og at pppd rapporterer begge adressene, utan gjentekne linjer om tunnel ikkje funnen. Viss PPP er oppe og trafikken framleis feilar, sjå deretter på ruting eller MTU, fordi L2TP-trinnet har gjort jobben sin. Noter den fungerande pakkeversjonen i maskinnotatane, slik at ein framtidig reinstallasjon ikkje gjenopprettar det øydelagde bygget.

Der den retta pakken ikkje er tilgjengeleg, er dei dokumenterte alternativa eit lokalt kjeldebygg av 1.3.16 eller 1.3.17, eit byte til kl2tpd eller ein festa nedgradering. Kvar av dei har ein vedlikehaldskostnad som er verdt å skrive ned.