Timeout L2TP pe Ubuntu 22.04: eroarea de tunel a xl2tpd

Desktopul arată o conexiune în curs, IPsec raportează succes, iar interfața PPP nu apare niciodată. În syslog același număr de tunel se repetă până când încercarea expiră pe UDP 1701. Înainte de a edita cheia prepartajată sau configurația serverului, recunoașteți această formă: pe Ubuntu 22.04 este de obicei o regresie de pachet în xl2tpd, iar serverul a fost corect tot timpul.

Ce vă spune perechea de linii repetată din syslog

O sesiune care eșuează tipărește o pereche de linii la intervale regulate: demonul nu găsește un tunel pentru un mesaj de control primit, apoi aruncă identificatorii de apel și de tunel care i-au fost dați. Mai târziu contorul de reîncercări ajunge la limită și conexiunea se închide cu un timeout pe portul 1701. Adresele și identificatorii sunt întâmplători; forma este ce contează. IKE s-a încheiat, traficul de control L2TP a sosit, iar demonul nu a reușit să îl asocieze unui tunel pe care îl crease deja.

Așadar defecțiunea se află între controlul L2TP și PPP. Despre secret, opțiunile PPP sau subrețeaua îndepărtată nu s-a testat încă nimic.

Confirmați că IPsec a reușit cu adevărat

Două verificări despart acest caz de o problemă de acreditări, iar ambele se fac înainte de orice modificare de pachet.

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

Ieșirea de stare listează conexiunea și starea ei, iar un tunel stabilit înseamnă că faza unu și faza doi s-au încheiat. O linie de jurnal despre o cheie partajată lipsă indică doar secretul, așa că opriți-vă și reparați mai întâi asta. Când IPsec este stabilit și timeoutul L2TP apare în continuare, demonul rămâne suspectul. Păstrați liniile exacte dintr-o singură încercare în loc de o zi întreagă de reîncercări.

Verificați compilarea xl2tpd, nu numele versiunii

Compilarea jammy a xl2tpd 1.3.16 din Ubuntu a activat optimizarea la momentul legării, ceea ce a stricat analiza identificatorului de tunel din răspunsul SCCRP al serverului. Demonul aruncă apoi pachetele de control pentru un tunel pe care l-a creat el însuși. Șirul versiunii contează mai mult decât numele distribuției.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Pachetul corectat este 1.3.16-1ubuntu0.1, deci o compilare fără acel sufix este mai veche decât corectura. Ieșirea de politică arată ce candidat ar instala o actualizare, iar lista de rețineri explică de ce nu a sosit o corectură. Unde pachetul este disponibil, actualizați-l și reconectați-vă prin profilul normal în loc să editați fișiere manual. Nu reconstruiți module și nu schimbați secretul cât timp compilarea veche este încă instalată.

Verificați PPP după modificare

O actualizare reușită se dovedește la nivelul care era stricat. Verificați că PPP a urcat, nu doar că pictograma s-a schimbat.

ip -4 addr show ppp0
ip route | grep ppp

Lista interfețelor ar trebui să arate o adresă locală și una de peer, iar tabela de rutare ar trebui să poarte prefixele tunelului. Syslog ar trebui să arate tunelul acceptat și pppd raportând ambele adrese, fără linii repetate despre tunel negăsit. Dacă PPP este activ și traficul tot eșuează, priviți apoi rutarea sau MTU, fiindcă etapa L2TP și-a terminat treaba. Notați versiunea de pachet care funcționează în notițele mașinii, ca o reinstalare viitoare să nu readucă compilarea stricată.

Unde pachetul corectat nu este disponibil, alternativele documentate sunt o compilare locală din surse 1.3.16 sau 1.3.17, o trecere la kl2tpd sau o retrogradare fixată. Fiecare implică un cost de întreținere care merită notat.