Problemas de VPN de sitio a sitio de IPsec después de la reciente actualización del kernel de Linux

Problemas de VPN de sitio a sitio de IPsec después de la reciente actualización del kernel de Linux

El fin de semana pasado tuvimos una actualización de seguridad automática en una de nuestras puertas de enlace VPN que conectan sitios a nuestro entorno de nube. Después de realizar la solución de problemas (a través de la solución básica de problemas de red, por ejemplo, a través de Wireshark), identificamos una de las actualizaciones de seguridad más recientes como la causa de esto. Hemos restaurado el sistema a un buen estado conocido y hemos puesto (creemos que) los paquetes afectados en espera.

Es una instancia de Ubuntu 20.04 LTS en AWS con linux-image-aws instalado. Estamos utilizando IPsec para conectar varios EdgeRouters a un entorno de nube privada.

Después de la actualización, todos los sitios se conectan y comunican como de costumbre; por ejemplo, ICMP funciona pero no podemos acceder a ciertos servicios (como RDP o SMB) en el entorno de nube privada.

Los registros de cambios de los paquetes relacionados no muestran ningún cambio vinculado obvio, por lo que me pregunto si me falta algo fundamental. Esta configuración ha funcionado bien durante más de un año sin problemas.

buena versión conocida: imagen-linux-aws 5.8.0.1041.43~20.04.13

Versión problemática: linux-image-aws 5.8.0.1042.44~20.04.14 y posteriores (también hemos probado la última versión 5.11 que parece estar afectada)

Extracto de configuración de IPsec

# MAIN IPSEC VPN CONFIG
config setup

conn %default
        keyexchange=ikev1

# <REMOVED>
conn peer-rt1.<REMOVED>.net.au-tunnel-1
        left=%any
        right=rt1.<REMOVED>.net.au
        rightid="%any"
        leftsubnet=172.31.0.0/16
        rightsubnet=10.35.0.0/16
        ike=aes128-sha1-modp2048!
        keyexchange=ikev1
        ikelifetime=28800s
        esp=aes128-sha1-modp2048!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        compress=no
        authby=secret
        auto=route
        keyingtries=%forever
        dpddelay=30s
        dpdtimeout=120s
        dpdaction=restart

Gracias de antemano.

EDITAR 1: Pude capturar otro tcpdump desde una conexión RDP fallida después de otra actualización de prueba, que se parece a lo siguiente:

21:43:01.813502 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [S], seq 2706968963, win 64954, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:43:01.813596 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [S], seq 2706968963, win 64954, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
21:43:01.814238 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [S.], seq 152885333, ack 2706968964, win 64000, options [mss 1460,nop,wscale 0,nop,nop,sackOK], length 0
21:43:01.839105 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 1, win 1025, length 0
21:43:01.839168 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 1, win 1025, length 0
21:43:01.840486 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 1:48, ack 1, win 1025, length 47
21:43:01.840541 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 1:48, ack 1, win 1025, length 47
21:43:01.843746 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [P.], seq 1:20, ack 48, win 63953, length 19
21:43:01.922120 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 20, win 1025, length 0
21:43:01.922212 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 20, win 1025, length 0
21:43:01.932646 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 48:226, ack 20, win 1025, length 178
21:43:01.932729 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 48:226, ack 20, win 1025, length 178
21:43:01.940677 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [P.], seq 20:1217, ack 226, win 63775, length 1197
21:43:01.967343 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 226:408, ack 1217, win 1020, length 182
21:43:01.967417 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 226:408, ack 1217, win 1020, length 182
21:43:01.969452 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [P.], seq 1217:1324, ack 408, win 63593, length 107
21:43:02.044376 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 1324, win 1020, length 0
21:43:02.044471 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 1324, win 1020, length 0
21:43:02.135594 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 408:637, ack 1324, win 1020, length 229
21:43:02.135653 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 408:637, ack 1324, win 1020, length 229
21:43:02.136796 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [P.], seq 1324:2609, ack 637, win 63364, length 1285
21:43:02.212871 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 2609, win 1025, length 0
21:43:02.212940 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 2609, win 1025, length 0

Respuesta1

Sin profundizar en ello, ¿se trata quizás de la eliminación de cifrados antiguos y débiles como sha1 y aes128? Intente cambiarlo a aes256-sha256-modp2048 en la versión funcional del kernel y luego actualice para ver si aún falla. ¿También tal vez ikev2 en lugar de ikev1? Pero eso es una preocupación del espacio de usuario, no de una configuración del kernel.

Pruébalo...

información relacionada