Skrivebordet viser en tilkobling som pågår, IPsec rapporterer suksess, og PPP-grensesnittet dukker aldri opp. I syslog gjentas det samme tunnelnummeret til forsøket får tidsavbrudd på UDP 1701. Før du redigerer den forhåndsdelte nøkkelen eller serverkonfigurasjonen, kjenn igjen dette mønsteret: på Ubuntu 22.04 er det vanligvis en pakkeregresjon i xl2tpd, og serveren var korrekt hele tiden.

Hva det gjentatte syslog-paret forteller deg

En økt som feiler skriver ut et par linjer med jevne mellomrom: daemonen finner ikke en tunnel for en innkommende kontrollmelding, og dumper deretter kall- og tunnel-ID-ene den fikk. Senere når nytt forsøk-telleren grensen sin, og tilkoblingen lukkes med tidsavbrudd på port 1701. Adresser og ID-er er tilfeldige; mønsteret er det som betyr noe. IKE fullførte, L2TP-kontrolltrafikk ankom, og daemonen klarte ikke å knytte den til en tunnel den allerede hadde opprettet.

Feilen ligger altså mellom L2TP-kontroll og PPP. Ingenting om hemmeligheten, PPP-alternativene eller det eksterne subnettet er prøvd ennå.

Bekreft at IPsec virkelig lyktes

To sjekker skiller dette fra et legitimasjonsproblem, og begge hører hjemme før enhver pakkeendring.

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

Statusutdataene lister tilkoblingen og tilstanden, og en etablert tunnel betyr at fase én og fase to er fullført. En logglinje om en manglende delt nøkkel peker bare på hemmeligheten, så stopp og rett det først. Når IPsec er etablert og L2TP-tidsavbruddet fortsatt vises, er daemonen den gjenværende mistenkte. Ta vare på de nøyaktige linjene fra ett forsøk i stedet for en hel dag med nye forsøk.

Sjekk xl2tpd-bygget, ikke utgivelsesnavnet

Ubuntus jammy-bygg av xl2tpd 1.3.16 aktiverte linketidsoptimalisering, noe som brøt analysen av tunnel-ID-en i serverens SCCRP-svar. Daemonen forkaster da kontrollpakker for en tunnel den selv opprettet. Versjonsstrengen betyr mer enn distribusjonsnavnet.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Den korrigerte pakken er 1.3.16-1ubuntu0.1, så et bygg uten den endelsen er eldre enn rettelsen. Policy-utdataene viser hvilken kandidat en oppgradering ville installere, og hold-listen forklarer hvorfor en rettelse ikke har kommet. Der pakken er tilgjengelig, oppgrader den og koble til på nytt via den vanlige profilen i stedet for å redigere filer for hånd. Ikke bygg moduler på nytt og ikke endre hemmeligheten mens det gamle bygget fortsatt er installert.

Bekreft PPP etter endringen

En vellykket oppgradering bevises på laget som var brutt. Sjekk at PPP kom opp, ikke bare at ikonet endret seg.

ip -4 addr show ppp0
ip route | grep ppp

Grensesnittlisten bør vise en lokal adresse og en peer-adresse, og rutetabellen bør bære tunnelens prefikser. Syslog bør vise at tunnelen ble akseptert og at pppd rapporterer begge adressene, uten gjentatte linjer om tunnel ikke funnet. Hvis PPP er oppe og trafikken fortsatt feiler, se deretter på ruting eller MTU, fordi L2TP-trinnet har gjort jobben sin. Noter den fungerende pakkeversjonen i maskinnotatene, slik at en fremtidig reinstallasjon ikke gjenoppretter det ødelagte bygget.

Der den korrigerte pakken ikke er tilgjengelig, er de dokumenterte alternativene et lokalt kildebygg av 1.3.16 eller 1.3.17, et bytte til kl2tpd eller en festet nedgradering. Hver av dem har en vedlikeholdskostnad som er verdt å skrive ned.

Relaterte artikler