Vì sao đường hầm IPsec của bạn chỉ chạy đến lần đổi khóa CHILD SA đầu tiên

Đường hầm dựng lên, ping trả lời và mọi người ký nhận. Bốn giờ sau phiên rớt, hai bên ghi lỗi đề xuất hoặc trao đổi khóa, và phỏng đoán đầu tiên là có gì đó đã thay đổi trên mạng. Không có gì thay đổi. Một đường hầm mang lưu lượng đã chứng minh hai bên đồng ý cách xác thực và cách bảo vệ liên kết con đầu tiên, và nó không chứng minh gì về việc trao đổi khóa mà họ sẽ đòi khi gia hạn. Sự lệch nằm trong khoảng trống giữa hai sự kiện đó.

Đã kết nối không có nghĩa là các thiết lập PFS khớp nhau

Với IKEv2, liên kết con đầu tiên được tạo trong quá trình trao đổi xác thực, và khóa của nó bắt nguồn từ vật liệu mà liên kết IKE đã tạo ra. Không có trao đổi Diffie-Hellman riêng cho liên kết con đó, nên chính sách đòi hỏi một lần trao đổi như vậy khi gia hạn không được thử lúc dựng lên.

Gia hạn là một trao đổi khác. Khi khóa của liên kết con được gia hạn, hai bên có thể thực hiện trao đổi khóa mới với nhóm được nêu trong đề xuất của họ, và đó là lần đầu tiên các thiết lập nhóm được so sánh. Vì vậy hai bên không khớp vẫn có thể xác thực, cài đặt liên kết con và cho lưu lượng đi qua, rồi thất bại khi gia hạn.

Sự lệch ẩn ở đâu trong chuỗi đề xuất

Trong strongSwan nhóm được nối vào đề xuất con, vì thế một chuỗi như aes256gcm16-prfsha256-ecp256 trông như lựa chọn mã hóa nhưng cũng mang yêu cầu trao đổi khóa. Bên chỉ cung cấp aes256gcm16-prfsha256 không có yêu cầu đó, và hai danh sách giao nhau ở phần mã hóa nhưng khác nhau ở phần trao đổi.

Hãy đọc đề xuất con và đề xuất IKE như hai danh sách riêng. Một nhóm xuất hiện trong danh sách IKE không nói gì về danh sách con, và sửa cái này trong khi đọc cái kia là cách thường khiến điều này bị bỏ sót.

Hãy đọc lỗi, không phải tệp bạn đã sửa

Tìm notify đã kết thúc trao đổi. Việc gia hạn khóa con trả về «không có đề xuất nào được chấp nhận» chỉ vào các danh sách đề xuất; yêu cầu gia hạn không bao giờ nhận được trả lời chỉ vào đường đi hoặc một bên đã ngừng lắng nghe. Hai trường hợp này cần cách sửa khác nhau, và cách diễn đạt của dòng nhật ký phân biệt chúng.

Xác nhận cấu hình đang chạy, không phải cấu hình trên đĩa. Một tệp đã lưu nhưng chưa nạp, hoặc một kết nối được đọc lại từ include khác, sẽ tạo ra sự lệch mà không mức sửa tệp nhìn thấy được nào chữa được.

Ba sự kiện đều được gọi là gia hạn khóa

Gia hạn khóa của liên kết IKE, xác thực lại IKE và gia hạn khóa của liên kết con là các thao tác riêng với quy tắc đề xuất riêng. Một thất bại được báo ở một trong số đó không nói gì trực tiếp về những cái còn lại, và nhật ký trộn lẫn chúng sẽ đọc như một hỏng hóc lặp lại duy nhất trong khi có ba.

Để ý bên kia nêu sự kiện nào, rồi chỉ kiểm tra đề xuất cho sự kiện đó. Đổi một danh sách, nạp lại và buộc cùng sự kiện xảy ra lần nữa. Nếu nhật ký nêu xác thực lại, đề xuất IKE là thứ cần đọc. Nếu nó nêu gia hạn khóa con, đề xuất con mang nhóm quan trọng.

Tắt gia hạn không phải là cách sửa

Đặt thời gian gia hạn khóa về không sẽ chặn trao đổi đang thất bại, và đường hầm sau đó sống cho đến khi bị dỡ bỏ hoặc bên kia khởi động lại. Thứ bạn mua là một khóa sống lâu hơn và một sự lệch sẽ gặp lại bạn trong lúc di chuyển, kiểm toán hoặc cập nhật từ nhà cung cấp. Điều tương tự cũng đúng với thời hạn bị kéo dài xa hơn chính sách mà bên kia mong đợi.

Thay vào đó hãy căn chỉnh các đề xuất. Chọn một nhóm mà cả hai bên triển khai, đặt nó vào đề xuất con ở cả hai đầu, và giữ chính sách gia hạn trong khoảng mà tổ chức thực sự yêu cầu.

Hãy chứng minh bằng chính trao đổi đã thất bại

Rút ngắn thời gian gia hạn khóa con trong cửa sổ bảo trì để sự kiện đến trong vài phút thay vì vài giờ, hoặc kích hoạt gia hạn khóa con thủ công. Sau đó theo dõi một lần gia hạn thành công và xác nhận lưu lượng vẫn tiếp tục đi qua nó, vì một bắt tay mới cài đặt liên kết con nhưng làm rơi luồng ứng dụng là một lỗi khác.

Sau đó khôi phục thời hạn bình thường và giữ cả hai bản ghi sự kiện, bản thất bại và bản thành công. Bằng chứng bạn muốn là kết nối sống qua vòng đời của chính nó, không phải rằng nó sống qua một ping.