L2TP-tidsudløb på Ubuntu 22.04: tunnelbugen i xl2tpd

Skrivebordet viser en forbindelse i gang, IPsec rapporterer succes, og PPP-grænsefladen dukker aldrig op. I syslog gentages det samme tunnelnummer, indtil forsøget får tidsudløb på UDP 1701. Før du redigerer den foruddelte nøgle eller serverkonfigurationen, skal du genkende dette mønster: på Ubuntu 22.04 er det normalt en pakningsregression i xl2tpd, og serveren var korrekt hele tiden.

Hvad det gentagne syslog-par fortæller dig

En fejlende session udskriver et par linjer med jævne mellemrum: dæmonen kan ikke finde en tunnel til en indgående kontrolmeddelelse og dumper derefter de kalde- og tunnel-id'er, den har fået. Senere når genforsøgstælleren sin grænse, og forbindelsen lukkes med en timeout på port 1701. Adresser og id'er er tilfældige; mønstret er det, der betyder noget. IKE blev fuldført, L2TP-kontroltrafik ankom, og dæmonen kunne ikke knytte den til en tunnel, den allerede havde oprettet.

Fejlen ligger altså mellem L2TP-kontrol og PPP. Der er endnu ikke testet noget om hemmeligheden, PPP-indstillingerne eller det eksterne subnet.

Bekræft, at IPsec faktisk lykkedes

To kontroller adskiller dette fra et legitimationsproblem, og begge hører før enhver pakkeændring.

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

Statusoutputtet viser forbindelsen og dens tilstand, og en etableret tunnel betyder, at fase et og fase to blev fuldført. En loglinje om en manglende delt nøgle peger kun på hemmeligheden, så stop og ret det først. Når IPsec er etableret, og L2TP-timeouten stadig vises, er dæmonen den resterende mistænkte. Gem de præcise linjer fra ét forsøg i stedet for en hel dags genforsøg.

Kontroller xl2tpd-buildet, ikke udgivelsesnavnet

Ubuntus jammy-build af xl2tpd 1.3.16 aktiverede link-time-optimering, hvilket brød parsingen af tunnel-id'et i serverens SCCRP-svar. Dæmonen kasserer derefter kontrolpakker til en tunnel, den selv oprettede. Versionsstrengen betyder mere end distributionsnavnet.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Den rettede pakke er 1.3.16-1ubuntu0.1, så et build uden det suffiks er ældre end rettelsen. Policy-outputtet viser, hvilken kandidat en opgradering ville installere, og hold-listen forklarer, hvorfor en rettelse ikke er ankommet. Hvor pakken er tilgængelig, skal du opgradere den og genoprette forbindelse via den normale profil i stedet for at redigere filer manuelt. Genopbyg ikke moduler, og skift ikke hemmeligheden, mens det gamle build stadig er installeret.

Bekræft PPP efter ændringen

En vellykket opgradering bevises på det lag, der var brudt. Kontroller, at PPP kom op, og ikke bare at ikonet ændrede sig.

ip -4 addr show ppp0
ip route | grep ppp

Grænsefladelisten bør vise en lokal adresse og en peer-adresse, og rutetabellen bør bære tunnelens præfikser. Syslog bør vise, at tunnelen blev accepteret, og at pppd rapporterer begge adresser, uden gentagne linjer om tunnel ikke fundet. Hvis PPP er oppe, og trafikken stadig fejler, så se derefter på routing eller MTU, fordi L2TP-trinnet har gjort sit arbejde. Notér den fungerende pakkeversion i maskinnoterne, så en fremtidig geninstallation ikke gendanner det brudte build.

Hvor den rettede pakke ikke er tilgængelig, er de dokumenterede alternativer et lokalt kildebuild af 1.3.16 eller 1.3.17, et skift til kl2tpd eller en fastlåst nedgradering. Hver af dem har en vedligeholdelsesomkostning, der er værd at skrive ned.