Điểm:1

Sự cố VPN site-to-site IPsec sau khi cập nhật nhân Linux gần đây

lá cờ ke
ICT

Cuối tuần trước, chúng tôi đã nâng cấp bảo mật tự động trên một trong các cổng VPN kết nối các trang web với môi trường đám mây của chúng tôi. Sau khi thực hiện khắc phục sự cố (thông qua khắc phục sự cố mạng cơ bản, chẳng hạn như qua Wireshark), chúng tôi đã xác định được một trong những bản cập nhật bảo mật gần đây nhất là nguyên nhân gây ra sự cố này. Chúng tôi đã khôi phục hệ thống trở lại trạng thái tốt đã biết và đã đặt (chúng tôi tin là) các gói bị ảnh hưởng ở trạng thái tạm dừng.

Đây là phiên bản Ubuntu 20.04 LTS trên AWS đã cài đặt linux-image-aws. Chúng tôi đang sử dụng IPsec để kết nối một số EdgeRouter với môi trường đám mây riêng.

Sau khi nâng cấp, tất cả các trang kết nối và giao tiếp như bình thường, ví dụ: ICMP đang hoạt động nhưng chúng tôi không thể truy cập một số dịch vụ nhất định (chẳng hạn như RDP hoặc SMB) trong môi trường đám mây riêng.

Nhật ký thay đổi cho các gói liên quan không hiển thị bất kỳ thay đổi được liên kết rõ ràng nào, vì vậy tôi tự hỏi liệu mình có thiếu điều gì cơ bản không. Cấu hình/thiết lập này đã hoạt động tốt hơn một năm nay mà không gặp sự cố nào.

Phiên bản tốt được biết đến: linux-hình ảnh-aws 5.8.0.1041.43~20.04.13

phiên bản có vấn đề: linux-image-aws 5.8.0.1042.44~20.04.14 trở đi (chúng tôi cũng đã thử nghiệm phiên bản 5.11 mới nhất có vẻ bị ảnh hưởng)

Trích xuất cấu hình IPsec

# CẤU HÌNH IPSEC VPN CHÍNH
thiết lập cấu hình

kết nối %default
        keyexchange=ikev1

# <ĐÃ LOẠI BỎ>
kết nối ngang hàng-rt1.<REMOVED>.net.au-tunnel-1
        còn lại =% bất kỳ
        right=rt1.<LOẠI BỎ>.net.au
        rightid="%any"
        leftsubnet=172.31.0.0/16
        rightsubnet=10.35.0.0/16
        ike=aes128-sha1-modp2048!
        keyexchange=ikev1
        ikelifetime=28800s
        đặc biệt=aes128-sha1-modp2048!
        tuổi thọ phím = 3600s
        rekeymargin=540s
        loại = đường hầm
        nén = không
        authby=bí mật
        auto=lộ trình
        keyingtries=%forever
        dpddelay=30s
        dpdtimeout=120s
        dpdaction=khởi động lại

Cảm ơn bạn trước.

CHỈNH SỬA 1: Tôi đã có thể chụp một tcpdump khác từ kết nối RDP không thành công sau khi nâng cấp thử nghiệm khác, giống như sau:

21:43:01.813502 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [S], seq 2706968963, win 64954, tùy chọn [mss 1460,nop,wscale 8,nop,nop,sackOK], độ dài 0
21:43:01.813596 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [S], seq 2706968963, win 64954, tùy chọn [mss 1460,nop,wscale 8,nop,nop,sackOK], độ dài 0
21:43:01.814238 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [S.], seq 152885333, ack 2706968964, win 64000, tùy chọn [mss 1460,nop,wscale 0,nop,nop,sackOK], chiều dài 0
21:43:01.839105 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 1, win 1025, độ dài 0
21:43:01.839168 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 1, win 1025, độ dài 0
21:43:01.840486 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 1:48, ack 1, win 1025, chiều dài 47
21:43:01.840541 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 1:48, ack 1, win 1025, chiều dài 47
21:43:01.843746 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [P.], seq 1:20, ack 48, win 63953, chiều dài 19
21:43:01.922120 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 20, win 1025, độ dài 0
21:43:01.922212 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 20, win 1025, chiều dài 0
21:43:01.932646 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 48:226, ack 20, win 1025, chiều dài 178
21:43:01.932729 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 48:226, ack 20, win 1025, chiều dài 178
21:43:01.940677 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [P.], seq 20:1217, ack 226, win 63775, chiều dài 1197
21:43:01.967343 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 226:408, ack 1217, win 1020, chiều dài 182
21:43:01.967417 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 226:408, ack 1217, win 1020, chiều dài 182
21:43:01.969452 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [P.], seq 1217:1324, ack 408, win 63593, chiều dài 107
21:43:02.044376 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 1324, win 1020, chiều dài 0
21:43:02.044471 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 1324, win 1020, chiều dài 0
21:43:02.135594 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 408:637, ack 1324, win 1020, chiều dài 229
21:43:02.135653 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [P.], seq 408:637, ack 1324, win 1020, chiều dài 229
21:43:02.136796 IP <REMOTE>.3389 > <LOCAL>.51099: Flags [P.], seq 1324:2609, ack 637, win 63364, chiều dài 1285
21:43:02.212871 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 2609, win 1025, độ dài 0
21:43:02.212940 IP <LOCAL>.51099 > <REMOTE>.3389: Flags [.], ack 2609, win 1025, độ dài 0
Tim avatar
lá cờ gp
Tim
Nếu bạn không thể giải quyết nó, có lẽ hãy cân nhắc sử dụng dịch vụ AWS VPN thay vì máy chủ?
ICT avatar
lá cờ ke
ICT
Chào tim. Đó là một điểm hợp lý, chúng tôi đã cân nhắc sử dụng VPC nhưng muốn giữ lại một số quyền kiểm soát đối với một số khía cạnh mà chúng tôi chỉ có thông qua thiết lập dựa trên máy ảo. Nhưng chúng tôi chắc chắn sẽ xem xét thêm nếu vấn đề vẫn tiếp diễn.
lá cờ cn
Không chắc nó liên quan như thế nào đến phiên bản gói, nhưng các sự cố MTU hiển thị các mẫu tương tự. Vì ICMP đang hoạt động, tôi sẽ thử tăng kích thước gói ICMP để xem liệu có kích thước tối đa nhất định cho các gói hoạt động đáng tin cậy hay không và nếu có, sẽ đặt MTU đường hầm theo cách thủ công (ở cả hai đầu).
ICT avatar
lá cờ ke
ICT
Xin chào grasbueschel, cảm ơn vì đã chỉ ra điều này - nghe có vẻ đáng để thử. Tôi cũng sẽ lên lịch trình này!
Điểm:1
lá cờ id
MLu

Nếu không đào sâu vào nó - có lẽ nó đã loại bỏ các mật mã cũ, yếu như sha1 và aes128? Hãy thử thay đổi nó thành aes256-sha256-modp2048 trong phiên bản kernel đang hoạt động và sau đó nâng cấp để xem nó có còn bị hỏng không. Cũng có thể là ikev2 thay vì ikev1? Nhưng đó là mối quan tâm về không gian người dùng, không phải cài đặt kernel.

Hãy thử đi...

ICT avatar
lá cờ ke
ICT
Cảm ơn bạn rất nhiều vì lời giới thiệu, tôi sẽ thử cái này sau giờ làm việc!
ICT avatar
lá cờ ke
ICT
Thật không may, điều này không giải quyết được vấn đề liên quan. Có vẻ như đã xảy ra sự cố với lưu lượng TCP. Tôi đã cập nhật bài đăng gốc của mình bằng tcpdump của kết nối RDP không thành công.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.