Tempo de espera L2TP en Ubuntu 22.04: o fallo do túnel de xl2tpd

O escritorio mostra unha conexión en curso, IPsec informa de éxito e a interface PPP nunca aparece. En syslog o mesmo número de túnel repítese ata que o intento esgota o tempo en UDP 1701. Antes de editar a clave precompartida ou a configuración do servidor, recoñeza esta forma: en Ubuntu 22.04 adoita ser unha regresión de empaquetado en xl2tpd, e o servidor era correcto todo o tempo.

Que lle di o par de liñas repetido de syslog

Unha sesión fallida imprime un par de liñas a intervalos regulares: o daemon non atopa un túnel para unha mensaxe de control entrante e despois volca os identificadores de chamada e de túnel que recibiu. Máis tarde o contador de reintentos chega ao límite e a conexión péchase cun tempo de espera no porto 1701. Os enderezos e os identificadores son accidentais; a forma é o que importa. IKE completouse, chegou o tráfico de control L2TP e o daemon non puido asocialo a un túnel que xa creara.

Por tanto, o fallo sitúase entre o control L2TP e PPP. Aínda non se probou nada do secreto, das opcións PPP nin da subrede remota.

Confirme que IPsec tivo éxito de verdade

Dúas comprobacións separan isto dun problema de credenciais, e ambas van antes de calquera cambio de paquete.

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

A saída de estado lista a conexión e o seu estado, e un túnel establecido significa que a fase un e a fase dous se completaron. Unha liña do rexistro sobre unha clave compartida ausente apunta só ao secreto, así que detéñase e arranxe iso primeiro. Cando IPsec está establecido e o tempo de espera L2TP segue aparecendo, o daemon é o sospeitoso restante. Garde as liñas exactas dun intento en lugar dun día enteiro de reintentos.

Comprobe a compilación de xl2tpd, non o nome da versión

A compilación jammy de xl2tpd 1.3.16 de Ubuntu activou a optimización en tempo de enlace, o que rompeu a análise do identificador de túnel na resposta SCCRP do servidor. O daemon entón descarta os paquetes de control dun túnel que creou el mesmo. A cadea de versión importa máis que o nome da distribución.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

O paquete corrixido é 1.3.16-1ubuntu0.1, así que unha compilación sen ese sufixo é anterior á corrección. A saída de políticas mostra que candidato instalaría unha actualización, e a lista de retidos explica por que non chegou unha corrección. Onde o paquete está dispoñible, actualíceo e volva conectarse polo perfil normal en lugar de editar ficheiros á man. Non reconstruía módulos nin cambie o secreto mentres a compilación antiga siga instalada.

Verifique PPP despois do cambio

Unha actualización correcta demóstrase na capa que estaba rota. Comprobe que PPP subiu, non só que a icona cambiou.

ip -4 addr show ppp0
ip route | grep ppp

A listaxe de interfaces debería mostrar un enderezo local e un de par, e a táboa de rutas debería levar os prefixos do túnel. Syslog debería mostrar o túnel aceptado e pppd informando ambos os enderezos, sen liñas repetidas de túnel non atopado. Se PPP está activo e o tráfico segue fallando, mire despois o encamiñamento ou a MTU, porque a etapa L2TP xa rematou o seu traballo. Anote a versión de paquete que funciona nas notas da máquina, para que unha futura reinstalación non restaure a compilación rota.

Onde o paquete corrixido non está dispoñible, as alternativas documentadas son unha compilación local do código fonte 1.3.16 ou 1.3.17, un cambio a kl2tpd ou unha baixada fixada. Cada unha comporta un custo de mantemento que paga a pena anotar.