Timeout L2TP su Ubuntu 22.04: il bug del tunnel di xl2tpd

Il desktop mostra una connessione in corso, IPsec segnala un successo e l’interfaccia PPP non compare mai. In syslog lo stesso numero di tunnel si ripete finché il tentativo non scade su UDP 1701. Prima di modificare la chiave precondivisa o la configurazione del server, riconoscete questa forma: su Ubuntu 22.04 di solito è una regressione di pacchettizzazione in xl2tpd, e il server era corretto per tutto il tempo.

Cosa vi dice la coppia di righe ripetuta in syslog

Una sessione che fallisce stampa una coppia di righe a intervalli regolari: il demone non trova un tunnel per un messaggio di controllo in arrivo, poi scarica gli identificatori di chiamata e di tunnel che ha ricevuto. Più tardi il contatore dei tentativi raggiunge il limite e la connessione si chiude con un timeout sulla porta 1701. Gli indirizzi e gli identificatori sono casuali; la forma è ciò che conta. IKE è terminato, il traffico di controllo L2TP è arrivato e il demone non è riuscito ad associarlo a un tunnel che aveva già creato.

Il guasto si trova quindi tra il controllo L2TP e PPP. Nulla del segreto, delle opzioni PPP o della sottorete remota è ancora stato provato.

Confermate che IPsec sia davvero riuscito

Due controlli separano questo da un problema di credenziali, ed entrambi vanno prima di qualsiasi modifica del pacchetto.

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

L’output di stato elenca la connessione e il suo stato, e un tunnel stabilito significa che la fase uno e la fase due sono state completate. Una riga di log su una chiave condivisa mancante punta solo al segreto, quindi fermatevi e correggete quello per primo. Quando IPsec è stabilito e il timeout L2TP compare ancora, il demone resta il sospetto. Conservate le righe esatte di un tentativo invece di un’intera giornata di nuovi tentativi.

Controllate la build di xl2tpd, non il nome della versione

La build jammy di xl2tpd 1.3.16 di Ubuntu ha attivato l’ottimizzazione al momento del collegamento, che ha rotto l’analisi dell’identificatore di tunnel nella risposta SCCRP del server. Il demone quindi scarta i pacchetti di controllo di un tunnel che ha creato lui stesso. La stringa di versione conta più del nome della distribuzione.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Il pacchetto corretto è 1.3.16-1ubuntu0.1, quindi una build senza quel suffisso è precedente alla correzione. L’output delle politiche mostra quale candidato installerebbe un aggiornamento, e l’elenco dei trattenuti spiega perché una correzione non è arrivata. Dove il pacchetto è disponibile, aggiornatelo e riconnettetevi tramite il profilo normale invece di modificare i file a mano. Non ricostruite moduli e non cambiate il segreto finché la vecchia build è ancora installata.

Verificate PPP dopo la modifica

Un aggiornamento riuscito si dimostra sullo strato che era rotto. Verificate che PPP sia salito, non solo che l’icona sia cambiata.

ip -4 addr show ppp0
ip route | grep ppp

L’elenco delle interfacce dovrebbe mostrare un indirizzo locale e uno di peer, e la tabella di routing dovrebbe portare i prefissi del tunnel. Syslog dovrebbe mostrare il tunnel accettato e pppd che riporta entrambi gli indirizzi, senza righe ripetute di tunnel non trovato. Se PPP è attivo e il traffico fallisce ancora, guardate poi il routing o l’MTU, perché la fase L2TP ha finito il suo lavoro. Annotate la versione del pacchetto funzionante nelle note della macchina, così una futura reinstallazione non ripristini la build rotta.

Dove il pacchetto corretto non è disponibile, le alternative documentate sono una build locale dai sorgenti 1.3.16 o 1.3.17, un passaggio a kl2tpd o un downgrade bloccato. Ognuna comporta un costo di manutenzione che vale la pena annotare.