IKE SA đã thiết lập, CHILD SA thiếu: dữ liệu dừng ở đâu
IKE SA được thiết lập không có nghĩa là dữ liệu đang chảy. Hãy đọc các mục con, kiểm tra bộ chọn và bộ đếm, rồi gọi tên tầng thực sự đã hỏng.
Máy khách nói rằng đã xác thực, trạng thái IKE trông khỏe mạnh, và các bộ đếm gói vẫn đứng ở số không. Sự kết hợp này không phải mâu thuẫn: IKEv2 tách quan hệ điều khiển và quan hệ dữ liệu ra riêng, và cái đầu có thể thành công trong khi cái sau không bao giờ dựng lên. Phụ huynh lo đàm phán; con lo lưu lượng. Hãy đọc hai tầng riêng rẽ trước khi gọi đường hầm là hỏng.
Hai SA làm gì
IKE SA là quan hệ điều khiển: nó xác thực các bên và chở những trao đổi đàm phán, thay thế và gỡ bảo vệ. Nó không bao giờ chở gói của ứng dụng bạn. Vì vậy một phụ huynh khỏe chỉ chứng minh hai đầu có thể đồng ý về chính sách bảo mật, và không hơn thế.
CHILD SA là quan hệ dữ liệu, được tạo dưới phụ huynh, với bộ chọn lưu lượng và vật liệu khóa cho một tập được bảo vệ. Nó có hướng, nên đầu ra trạng thái liệt kê một liên kết vào và một liên kết ra với mã định danh riêng, và thường có bộ đếm riêng cho mỗi hướng. Chính cặp này là lý do một hướng có thể chạy trong khi hướng kia rơi, và lý do câu đường hầm đã lên không nói gì về lưu lượng. Một phụ huynh cũng có thể giữ nhiều con, và như vậy một nhãn kết nối che mất cái bạn cần.
Đọc các mục của con, không phải nhãn kết nối
Mở trạng thái phụ huynh và danh sách con cùng lúc, rồi tìm con có bộ chọn khớp với luồng bạn đang kiểm tra. Ghi lại bộ chọn lưu lượng, thuật toán đã thỏa thuận, thời hạn sống và bộ đếm ở cả hai hướng. Nếu có nhiều con, hãy đối chiếu theo bộ chọn chứ không theo vị trí, vì vị trí thay đổi sau khi làm mới khóa. Viết các mã định danh ra trước khi thay đổi bất cứ điều gì.
Nếu phụ huynh liệt kê một tập lưu lượng khác với tập bạn đang kiểm tra, bạn đang đọc sai con. Đó là vấn đề bộ chọn, không phải đường hầm hỏng.
Ghi lại cả dấu thời gian. Việc làm mới khóa có thể thay một tầng trong khi tầng kia vẫn được thiết lập, và một con trông mới có thể là bản thay thế cho con bạn đang theo dõi. So sánh các mã định danh trước khi kết luận rằng một con đã biến mất.
Khi không có con nào
Xác thực có thể thành công trong khi đề xuất dữ liệu hoặc bộ chọn thất bại, và phụ huynh ở lại hoàn toàn không có con. Nguyên nhân thường gặp là lệch thuật toán hoặc lệch bộ chọn lưu lượng, và cả hai bên đều ghi lại đề xuất bị từ chối. Hãy đọc cả hai đầu, vì phía bạn với tới có thể chỉ hiển thị sự từ chối. Sửa chỗ lệch thay vì khởi động lại phụ huynh, vì việc đó lặp lại đúng cuộc đàm phán thất bại ấy và thêm một lần gián đoạn nữa vào bằng chứng.
Một phụ huynh liên tục thiết lập lại là lỗi khác với một phụ huynh đứng vững mà không có con. Trong trường hợp thứ hai, nhật ký nêu tên đề xuất bị từ chối, nên hãy thu thập đề xuất đó từ cả hai đầu trước khi sửa chính sách.
Khi có con nhưng bộ đếm vẫn bằng không
Gửi một yêu cầu mới khớp với bộ chọn của con. Yêu cầu tới đích nằm ngoài chính sách đó sẽ không làm bộ đếm nhúc nhích, dù nó trông thành công đến đâu.
Kiểm tra tuyến đường phải đẩy luồng vào đường hầm, vì một con không có lưu lượng thường là con mà không có gì được định tuyến tới. Bộ đếm chỉ nhúc nhích một hướng cho thấy lệch bộ chọn hoặc chính sách trên đường về. Xem bộ chọn chiều về của bên đối tác từ xa trước khi chạm vào phía cục bộ. Một yêu cầu mới cũng cho bạn dấu thời gian để đối chiếu với đầu ra trạng thái của cả hai đầu.
Gọi tên tầng trong báo cáo
Báo cáo sự cố thành ba trường thay vì một phán quyết: tầng đã hỏng, trao đổi hoặc con bạn đã kiểm tra, và bằng chứng bạn có. Tầng là một trong ba: phụ huynh chưa bao giờ được thiết lập, đàm phán của con bị từ chối, hoặc có con và lưu lượng không tới được nó. Bằng chứng là mã định danh của con cùng bộ chọn và bộ đếm của nó, hoặc đề xuất bị từ chối được trích từ cả hai nhật ký. Bất kỳ ai đọc điều đó đều có thể đi thẳng tới trao đổi quan trọng thay vì hỏi bạn muốn nói VPN nào.
tài liệu strongSwan về IKEv2 chỉ ra những tầng đó trông thế nào trong đầu ra trạng thái. Hãy đính kèm đầu ra của con bạn đã kiểm tra, không chỉ bản tóm tắt của phụ huynh.