WireGuard lỗi sau thời gian nhàn rỗi: hãy thử hướng trước

Bốn câu hỏi đứng trước mọi thay đổi cài đặt: cùng một tài nguyên có hoạt động khi máy khách đang hoạt động không, giai đoạn nhàn rỗi kéo dài bao lâu, thiết bị có ngủ hay đổi mạng không, và lỗi chỉ xuất hiện ở lưu lượng do phía bên kia khởi tạo. Các câu trả lời tách một ánh xạ NAT hết hạn khỏi một radio đang ngủ và khỏi một ứng dụng cũ. Chúng cũng cho biết keepalive có liên quan hay không. Hãy bắt đầu từ hướng, vì nó chỉ tốn một lệnh và loại bỏ một nửa nguyên nhân có thể.

Hướng nào bị lỗi?

Một yêu cầu ra mới từ máy khách và lưu lượng đi đến nó sau giai đoạn yên tĩnh thử thách thiết bị có trạng thái theo cách khác nhau. Các gói ra xây dựng lại ánh xạ khi rời đi, trong khi gói vào cần ánh xạ cũ còn sống. Sự bất đối xứng đó chính là toàn bộ bài kiểm tra. Nếu máy khách ra ngoài được nhưng không có gì vào, ánh xạ có lẽ đã hết hạn, và nếu cả hai đều không hoạt động, đường hầm hoặc quyền truy cập mạng của máy khách đã mất.

Ghi lại giai đoạn yên tĩnh kéo dài bao lâu và thiết bị có ngủ hay chuyển sang mạng khác trong lúc đó không. Hai sự thật này thay đổi chẩn đoán trước bất kỳ cài đặt nào.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Chạy ba lệnh đó trước và sau giai đoạn yên tĩnh, vì mỗi lệnh trả lời một phần khác của câu hỏi. Một mốc thời gian handshake không nhúc nhích cho biết hai bên đã ngừng nói chuyện, trong khi một điểm cuối đã thay đổi cho biết ánh xạ đã dịch chuyển chứ không chết. Bộ đếm truyền cho biết có thứ gì đến hay không, và đó là khác biệt giữa ánh xạ cũ và ứng dụng im lặng. Ghi các con số ở cả hai điểm, vì so sánh chính là bằng chứng.

Ngủ, radio và trạng thái ứng dụng

Trên điện thoại hay máy tính xách tay, thiết bị đang ngủ có thể đã mất hoàn toàn quyền truy cập mạng, và keepalive không thể khôi phục một radio đã tắt hay hoàn tất một cổng captive chưa được đáp ứng. Các nền tảng di động tạm dừng công việc nền theo chính sách, nên lưu lượng định kỳ có tiếp tục hay không phụ thuộc vào nền tảng và vào những gì ứng dụng đã thương lượng với nó. Một kết nối được lưu trong bộ nhớ đệm là trường hợp thứ ba và dễ gây nhầm lẫn nhất, vì đường hầm quay lại không giống với việc ứng dụng kết nối lại với nó.

Mở lại ứng dụng sau giai đoạn nhàn rỗi thay vì tin vào thẻ vẫn mở. Nếu một yêu cầu mới thành công ở nơi phiên cũ thất bại, đường hầm chưa bao giờ là vấn đề.

keepalive thực sự làm gì

PersistentKeepalive gửi định kỳ một gói rỗng đã xác thực đến một peer, đủ để giữ một ánh xạ NAT sống giữa các peer và giữ điểm cuối của phía bên kia được cập nhật, như khởi động nhanh WireGuard mô tả. Nó không sửa một radio đang ngủ, một tuyến bị mất hay một ứng dụng không bao giờ thử lại. Chọn khoảng thời gian qua cài đặt máy khách được hỗ trợ, và đừng bật một giá trị mạnh ở mọi nơi chỉ vì màn hình trạng thái im lặng.

Hầu hết các giai đoạn nhàn rỗi không phải lỗi. Một đường hầm kết nối lại sau năm phút im lặng đang hoạt động đúng, và vấn đề chỉ là trường hợp lẽ ra phải có thứ gì đó đến từ phía bên kia.

Chờ qua khoảng thời gian từng bị lỗi

Thực hiện một thay đổi được hỗ trợ, rồi để cùng giai đoạn nhàn rỗi trôi qua trước khi thử lại tài nguyên đó. Chờ đợi là một phần của bài kiểm tra chứ không phải thủ tục. Thành công ngay sau khi kết nối lại không nói gì về triệu chứng nhàn rỗi lâu dài, vì kết nối lại chính là sự kiện đặt lại trạng thái. Nếu vấn đề cũng xuất hiện khi đang sử dụng tích cực, hãy quay lại kiểm tra handshake và đường dữ liệu thay vì thêm lưu lượng định kỳ.

Giữ một thay đổi cho mỗi lần kiểm tra và ghi lại thời lượng nhàn rỗi đã dùng. Không có điều đó, mỗi so sánh sau này sẽ trôi đi và không ai có thể nói thay đổi nào quan trọng. Ghi lại bốn sự thật cùng nhau: hướng, thời lượng, trạng thái ngủ và hành vi của ứng dụng.