Phát hiện peer chết của IKEv2 không kiểm tra ứng dụng của bạn

Kiểm tra sự sống của IKEv2 đặt một câu hỏi: peer còn lại có còn trả lời trên mối quan hệ điều khiển được bảo vệ hay không. Nó không đo xem một ứng dụng nội bộ có khỏe mạnh không, có tuyến đường nào sau gateway không, hay việc duyệt web có vẻ nhanh không. Kiểm tra có thể đạt trong khi mọi thứ hữu ích sau đường hầm đều hỏng.

Hãy đọc riêng hai loại bằng chứng trước khi thay đổi bộ đếm thời gian.

Kiểm tra sự sống thực sự hỏi điều gì

Một trao đổi sự sống được gửi bên trong hiệp hội bảo mật IKE đã thiết lập và mong đợi câu trả lời trong một cửa sổ được cấu hình. Thành công nghĩa là việc triển khai IKE của peer vẫn còn đó và vẫn sẵn sàng nói chuyện. Nó không nói gì về các hiệp hội bảo mật con mang lưu lượng, không nói gì về định tuyến ngoài gateway, và không nói gì về dịch vụ mà bạn đã mở đường hầm. Đó là ba câu hỏi riêng biệt với ba cách hỏng riêng biệt.

Sự khác biệt đó quyết định nơi bạn nhìn khi một phiên trở nên im lặng. Một peer tiếp tục trả lời trong khi đường dữ liệu bị hỏng chỉ ra chính sách, định tuyến hoặc một dịch vụ ở hạ nguồn. Một peer ngừng trả lời chỉ ra khả năng tiếp cận hoặc trạng thái của chính đầu xa.

Đọc các hiệp hội bảo mật trước trình duyệt

Trạng thái điều khiển và trạng thái dữ liệu được liệt kê riêng khi bạn hỏi daemon, và các bộ đếm cho biết có bất cứ điều gì được thử hay không. Một hiệp hội con chưa từng được cài đặt trông hoàn toàn khác với một hiệp hội đã cài đặt rồi ngừng chuyển gói, dù cả hai đều tạo ra cùng một phàn nàn của người dùng.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Ghi tên các trạng thái nguyên văn vào ticket, cùng với các bộ đếm tại thời điểm phàn nàn. Mô tả kiểu đường hầm sập che giấu hiệp hội nào trong hai hiệp hội đã kết thúc, và đó thường là sự thật duy nhất đáng giữ lại.

Lỗi tuyến đường trông giống hệt một peer chết

Gateway có thể trả lời các trao đổi điều khiển trong khi một máy chủ riêng đang ngoại tuyến, một tuyến được chuyển tiếp bị thiếu, hoặc phân giải tên nội bộ thất bại hoàn toàn. Từ góc nhìn của máy khách, mỗi trường hợp trong số đó hiện ra như một phiên đang hoạt động và một đích không hoạt động. Hãy kiểm tra đường về cẩn thận như đường đi, vì định tuyến bất đối xứng ở phía xa chỉ tạo ra sự im lặng theo một hướng.

Kiểm tra trực tiếp ứng dụng dự kiến và nêu địa chỉ mà nó đã thử, thay vì kiểm tra xem đường hầm có hoạt động không. Ping tới gateway chứng minh gateway trả lời; nó chưa bao giờ chứng minh ứng dụng đã trả lời. Ghi lại địa chỉ chính xác mà ứng dụng đã thử. Chuỗi đó thu hẹp việc tìm kiếm sau này, và đó là sự thật duy nhất mà ticket thường bỏ qua.

Giữ bộ đếm thời gian ra ngoài chẩn đoán

Rút ngắn khoảng phát hiện không phải là thay đổi hiệu năng và không thêm dung lượng. Khi mất gói, nó thay đổi mức độ nhanh chóng một lỗi được nhận ra, điều có thể làm triệu chứng trông khác đi mà không cải thiện gì. Trước tiên hãy ghi lại thời điểm thực của lỗi, rồi quyết định xem dung sai có sai với đường liên kết mà bạn thực sự có hay không.

Việc làm mới ánh xạ NAT thuộc cùng loại. Chúng giữ một đường đã dịch dùng được, và chúng không phải bằng chứng rằng ứng dụng từ xa hoạt động.

Một chính sách khôi phục đầy đủ nói máy khách nên làm gì khi một peer bị tuyên bố là chết: khởi động lại, đóng hoặc giữ, và lưu lượng khác được làm gì trong lúc đó. Không có nó, cùng một sự cố lại được chẩn đoán từ đầu mỗi quý.