IPsec Site-to-Site VPN-Probleme nach dem letzten Linux-Kernel-Update

IPsec Site-to-Site VPN-Probleme nach dem letzten Linux-Kernel-Update

Letztes Wochenende haben wir ein automatisches Sicherheitsupgrade für eines unserer VPN-Gateways durchgeführt, das die Sites mit unserer Cloud-Umgebung verbindet. Nach der Fehlerbehebung (über grundlegende Netzwerk-Fehlerbehebung, z. B. über Wireshark) haben wir festgestellt, dass eines der neuesten Sicherheitsupdates die Ursache dafür ist. Wir haben das System wieder in einen bekannten guten Zustand versetzt und (unserer Meinung nach) betroffene Pakete auf Eis gelegt.

Es handelt sich um eine Ubuntu 20.04 LTS-Instanz auf AWS mit installiertem linux-image-aws. Wir verwenden IPsec, um mehrere EdgeRouter mit einer privaten Cloud-Umgebung zu verbinden.

Nach dem Upgrade stellen alle Sites wie gewohnt eine Verbindung her und kommunizieren. Beispielsweise funktioniert ICMP, aber wir können nicht auf bestimmte Dienste (wie RDP oder SMB) in der privaten Cloud-Umgebung zugreifen.

Die Änderungsprotokolle für die zugehörigen Pakete zeigen keine offensichtlichen verknüpften Änderungen, daher frage ich mich, ob ich etwas Grundlegendes übersehe. Diese Konfiguration/Einrichtung funktioniert seit über einem Jahr ohne Probleme.

Bekannte gute Version: linux-image-aws 5.8.0.1041.43~20.04.13

Problematische Version: linux-image-aws 5.8.0.1042.44~20.04.14 und höher (wir haben auch die neueste Version 5.11 getestet, die betroffen zu sein scheint)

Auszug aus der IPsec-Konfiguration

# 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

Vielen Dank im Voraus.

EDIT 1: Ich konnte nach einem weiteren Test-Upgrade einen weiteren TCPdump von einer erfolglosen RDP-Verbindung erfassen, der wie folgt aussieht:

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

Antwort1

Ohne tiefer in die Materie einzusteigen – ist es vielleicht die Entfernung der alten, schwachen Chiffren wie sha1 und aes128? Versuchen Sie, es in der funktionierenden Kernelversion in aes256-sha256-modp2048 zu ändern und führen Sie dann ein Upgrade durch, um zu sehen, ob es immer noch nicht funktioniert. Vielleicht auch ikev2 statt ikev1? Aber das ist ein Benutzerbereichsproblem, keine Kerneleinstellung.

Probieren Sie es aus …

verwandte Informationen