Temps d'espera L2TP a Ubuntu 22.04: l'error del túnel d'xl2tpd

L'escriptori mostra una connexió en curs, IPsec informa d'èxit i la interfície PPP no apareix mai. A syslog el mateix número de túnel es repeteix fins que l'intent expira a UDP 1701. Abans d'editar la clau prèviament compartida o la configuració del servidor, reconeixeu aquesta forma: a Ubuntu 22.04 sol ser una regressió d'empaquetat a xl2tpd, i el servidor era correcte tot el temps.

Què us diu el parell de línies repetides de syslog

Una sessió fallida imprimeix un parell de línies a intervals regulars: el dimoni no troba cap túnel per a un missatge de control entrant i després aboca els identificadors de trucada i de túnel que li han lliurat. Més tard el comptador de reintents arriba al límit i la connexió es tanca amb un temps d'espera al port 1701. Les adreces i els identificadors són accidentals; la forma és el que importa. IKE va completar-se, el trànsit de control L2TP va arribar i el dimoni no el va poder associar amb un túnel que ja havia creat.

Per tant, la fallada se situa entre el control L2TP i PPP. Encara no s'ha provat res del secret, les opcions PPP ni la subxarxa remota.

Confirmeu que IPsec ha reeixit de debò

Dues comprovacions separen això d'un problema de credencials, i totes dues van abans de qualsevol canvi de paquet.

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

La sortida d'estat llista la connexió i el seu estat, i un túnel establert vol dir que la primera i la segona fase s'han completat. Una línia del registre sobre una clau compartida absent assenyala només el secret, així que atureu-vos i arregleu-ho primer. Quan IPsec està establert i el temps d'espera L2TP encara apareix, el dimoni és el sospitós restant. Guardeu les línies exactes d'un intent en lloc d'un dia sencer de reintents.

Comproveu la compilació d'xl2tpd, no el nom de la versió

La compilació jammy d'xl2tpd 1.3.16 d'Ubuntu va activar l'optimització en temps d'enllaç, cosa que va trencar l'anàlisi de l'identificador de túnel a la resposta SCCRP del servidor. Llavors el dimoni descarta els paquets de control d'un túnel que ell mateix va crear. La cadena de versió importa més que el nom de la distribució.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

El paquet corregit és 1.3.16-1ubuntu0.1, així que una compilació sense aquest sufix és anterior a la correcció. La sortida de política mostra quin candidat instal·laria una actualització, i la llista de retinguts explica per què no ha arribat la correcció. On el paquet està disponible, actualitzeu-lo i torneu-vos a connectar pel perfil normal en lloc d'editar fitxers a mà. No reconstruïu mòduls ni canvieu el secret mentre la compilació antiga encara està instal·lada.

Verifiqueu PPP després del canvi

Una actualització reeixida es demostra a la capa que estava trencada. Comproveu que PPP ha pujat, no només que la icona ha canviat.

ip -4 addr show ppp0
ip route | grep ppp

El llistat d'interfícies hauria de mostrar una adreça local i una de parell, i la taula de rutes hauria de portar els prefixos del túnel. Syslog hauria de mostrar el túnel acceptat i pppd informant les dues adreces, sense línies repetides de túnel no trobat. Si PPP està aixecat i el trànsit encara falla, mireu després l'encaminament o l'MTU, perquè l'etapa L2TP ha acabat la seva feina. Anoteu la versió de paquet que funciona a les notes de la màquina, perquè una reinstal·lació futura no restauri la compilació trencada.

On el paquet corregit no està disponible, les alternatives documentades són una compilació local del codi font 1.3.16 o 1.3.17, un canvi a kl2tpd o una baixada fixada. Cadascuna comporta un cost de manteniment que val la pena anotar.