SA IKEv2 của bạn đã lên nhưng không có SA con: đọc cuộc trao đổi

IKE nói đường hầm đã lên, SA con không có, và cả hai câu có thể cùng đúng một lúc. Mối quan hệ điều khiển đã thiết lập không phải là liên kết dữ liệu, và hai đối tượng có vòng đời, đàm phán và kiểu hỏng riêng. Báo cáo điều đầu tiên như khả năng kết nối là cách một phiếu kết thúc bằng việc khẳng định đường hầm đã lên trong khi không có gì hoạt động. Hãy đọc danh sách liên kết thay vì nhãn tóm tắt của kết nối, vì danh sách đó là nơi duy nhất đối tượng thiếu hiện ra. Dưới đây là thứ tự khiến danh sách trở nên dễ hiểu.

Hai liên kết, hai nhiệm vụ

SA IKE mang kênh điều khiển: danh tính, khóa và các đề xuất cho chính cuộc trao đổi điều khiển. SA con mang lớp bảo vệ ESP, với thuật toán riêng và bộ chọn lưu lượng riêng. Xác thực và việc tạo SA con thường đi cùng nhau, vì SA con đầu tiên được đàm phán bên trong IKE_AUTH, và chính sự gộp đó khiến người ta bất ngờ về việc tách rời.

Điều này cũng giải thích hai dạng hỏng mà bạn sẽ gặp. SA con bị từ chối trong cuộc trao đổi ban đầu thường kéo SA IKE xuống theo, nên bạn không thấy kênh điều khiển nào được thiết lập. SA IKE đứng một mình thường có nghĩa là SA con đầu tiên thành công và một lần thử tạo SA con sau đó thất bại, chẳng hạn khi gia hạn khóa. Dấu thời gian tách những trường hợp đó nhanh hơn bất kỳ lần rà soát cấu hình nào.

Tầng nào đã từ chối

Khi một SA con bị từ chối, thông báo nêu tên tầng. Từ chối đề xuất nghĩa là hai bên không thể thống nhất thuật toán, thường vì một bên yêu cầu nhóm bí mật hoàn hảo về phía trước khác hoặc một mật mã mà bên kia không chấp nhận. Từ chối bộ chọn nghĩa là tập lưu lượng bị từ chối thẳng, và đó là lập luận về phạm vi, không phải mật mã.

Đôi khi không có SA con chính là thiết kế. SA IKE không có SA con là một tiện ích mở rộng được định nghĩa, dùng ở nơi liên kết dữ liệu phải được tạo theo yêu cầu, nên việc vắng mặt là đúng và SA con xuất hiện khi lưu lượng khớp đến. Ghi chú của strongSwan về IKEv2 bao gồm cả kiểu theo yêu cầu và các thiết lập đề xuất quyết định trường hợp đầu tiên.

Hãy kiểm tra xem có cấu hình theo yêu cầu hay bẫy trước khi chẩn đoán lỗi. Nếu SA con được tạo lười, việc không có SA con khi rảnh là trạng thái mong đợi, và phép thử thật là lưu lượng có dựng một cái lên không. Phép thử đó cũng tách thiết kế lười khỏi hỏng lặng lẽ, vì việc tạo thất bại để tín hiệu kích hoạt không có trả lời chứ không chỉ nằm yên.

Sau đó hỏi về đường dữ liệu

Khi đã có SA con, các bộ đếm trả lời câu hỏi tiếp theo. ip -s xfrm state báo số gói và byte cho mỗi liên kết, và một SA con không mang gì trong khi bạn tạo lưu lượng chỉ ra việc khớp hay định tuyến chứ không phải tới một liên kết thiếu. swanctl --list-sas in các bộ chọn của SA con bên cạnh những bộ đếm đó, và chính điều đó xác nhận gói nằm trong tập được chấp nhận.

Hãy tách riêng trong báo cáo giữa xác thực thành công và cuộc trao đổi SA con thất bại. Một báo cáo nói xác thực thất bại sẽ gửi kỹ sư tiếp theo tới kho chứng chỉ, và câu chính xác ngắn hơn nhiều: SA IKE đã lên, và SA con cho luồng này chưa bao giờ được chấp nhận.

Đối chiếu hai đầu

Với máy chủ bạn tự vận hành, hãy lấy nhật ký của máy khách và cổng cho cùng một cuộc trao đổi thay vì so sánh hai lần thử kết nối lại cách nhau một giờ. Các thông báo phải khớp ở cả hai phía, và ở nơi không khớp, bạn đã tìm ra phía bị cấu hình sai.

Hãy sửa đàm phán SA con, rồi thử lại với lưu lượng bên trong bộ chọn dự định. Đây là phép thử duy nhất chứng minh đối tượng thiếu nay đã hiện diện, vì danh sách liên kết được làm mới khi rảnh có thể trông giống hệt trước và sau khi sửa.