Keepalive không phải là kết nối lại: hãy chọn theo lỗi bạn đang gặp

Keepalive và kết nối lại được cấu hình cùng lúc nhưng giải quyết những vấn đề khác nhau, vì thế chỉnh cái này hiếm khi sửa được cái kia. Keepalive gửi lưu lượng nhỏ để giữ một mục trạng thái còn sống hoặc để nhận ra rằng đối tác đã ngừng phản hồi. Kết nối lại phá bỏ phần đã hỏng và dựng lại mối quan hệ, bao gồm khóa, địa chỉ và tuyến đường. Hãy chọn cơ chế khớp với lỗi, không phải cơ chế mà bạn đã quen tay. Hai câu hỏi quyết định: đường đi đã chết, hay có gì đó giữa các đối tác đang quên nó?

Khi ánh xạ là vấn đề

Đường hầm chỉ chết sau vài phút im lặng thường mất một mục chuyển dịch chứ không phải đối tác. Tùy chọn PersistentKeepalive của WireGuard tồn tại cho trạng thái NAT và tường lửa, và ghi chú của chính dự án mô tả nó đúng như vậy, không phải như một lần kiểm tra sức khỏe. Khoảng vài chục giây giữ mục ấm, trong khi một gói mỗi giây là quyết định về pin chứ không phải về độ tin cậy. OpenVPN đi đến cùng chỗ qua ping và ping-restart , chúng nhận ra sự im lặng trước rồi mới hành động theo đó.

Những cài đặt này cũng không thay thế được giữa các giao thức. Chính sách đối tác chết của IKEv2, bộ hẹn giờ ping của OpenVPN và keepalive của WireGuard trả lời cùng một câu hỏi bằng ba cú pháp và ba giá trị mặc định khác nhau, nên sao chép một con số giữa chúng là phỏng đoán khoác áo tinh chỉnh.

Khi mối quan hệ đã mất

Nếu đối tác đổi địa chỉ, thông tin xác thực hết hạn hoặc đầu xa khởi động lại, những gói nhỏ không phải là cách sửa. Kết nối lại phải dựng lại trạng thái : lấy địa chỉ, cài lại tuyến đường, đàm phán lại khóa và trong một số triển khai xác thực lại người dùng.

Các máy khách kết nối lại không có người giám sát giữ một chứng chỉ hoặc một bí mật đã lưu. Máy khách sẽ hỏi con người thất bại đúng lúc không có ai, và đó là tình huống mà kết nối lại có ý nghĩa. Đó là quyết định thiết kế được đưa ra từ nhiều tháng trước, không phải cài đặt bạn có thể đổi trong lúc sự cố.

Điều mà cả hai đều không chứng minh

Đường hầm có thể đã kết nối lại, có khóa và tuyến đường, trong khi dịch vụ phía sau đã chết, và keepalive có thể giữ một ánh xạ mở cho phiên mà máy chủ đã biến mất từ nhiều giờ. Cả hai cơ chế đều có thể báo thành công trong khi thứ bạn thực sự quan tâm không khả dụng.

Vì thế bài kiểm tra kết thúc bằng một yêu cầu thật. Gửi thứ gì đó qua đường hầm sau khoảng thời gian bạn quan tâm, rồi riêng rẽ kích hoạt lỗi mà bạn đã thiết kế: một giai đoạn rảnh rỗi cho trường hợp ánh xạ, một lần khởi động lại hoặc đổi địa chỉ cho trường hợp kết nối lại.

Chặn lưu lượng trực tiếp là một quyết định riêng

Vòng lặp kết nối lại có thể hoàn toàn khỏe mạnh trong khi một ứng dụng lặng lẽ dùng tuyến thường, và đó là rò rỉ chứ không phải lỗi. Nếu yêu cầu là không có gì ra ngoài đường hầm, hãy nói rõ trong cấu hình máy khách và chứng minh bằng cách hạ đường hầm xuống rồi xem còn gì kết nối. Không cơ chế nào ngụ ý hành vi đó, và không mức kỷ luật thử lại nào thiết lập được nó.

Ghi lại cơ chế nào đã chạy và liệu một yêu cầu mới có thành công sau đó. Hai sự thật ấy là thứ kỹ sư tiếp theo cần, và không cái nào hiện ra trong biểu tượng trạng thái. Một dòng log nói rằng máy khách đã kết nối lại không giống một yêu cầu đã chạy được.

Viết chính sách, không chỉ con số

Đặt cặp ấy vào một câu: khoảng rảnh rỗi, ngưỡng sống, điều gì kích hoạt việc dựng lại , và máy khách làm gì trong lúc thử lại. Không có câu đó, mỗi sự cố tương lai lại mở lại cuộc tranh luận keepalive có quá ngắn hay kết nối lại có quá chậm.

Ghi chú của WireGuard về giới hạn là một lời nhắc hữu ích rằng keepalive là giải pháp vòng tránh cho các hộp trung gian chứ không phải thiết kế sống chung. Hãy đọc giới hạn đó trước khi tăng tần suất để đối phó với vấn đề nó không thể giải quyết.