WireGuard gửi dữ liệu nhưng không nhận lại gì: phía nào?

Các bộ đếm gửi tăng trong khi bộ đếm nhận vẫn ở mức không mô tả một hướng, không phải chẩn đoán. Cùng một kết quả đọc xuất hiện khi peer chưa bao giờ hoàn tất bắt tay, khi đích chọn nhầm peer, khi phía xa không có đường quay lại, và khi một bộ lọc bỏ phản hồi trên đường về. Mỗi trường hợp được sửa ở một nơi khác nhau.

Phép so sánh giúp rút ngắn công việc là giữa một yêu cầu chưa bao giờ rời đường hầm và một phản hồi chưa bao giờ quay về. Một lần bắt gói trên giao diện đúng sẽ phân định hai khả năng.

Bộ đếm mô tả khối lượng, không phải hướng của lỗi

Bộ đếm của WireGuard ghi lại những gì giao diện đã trao cho peer và những gì nó nhận từ peer. Chúng không cho biết đích nào, peer nào hoặc nửa nào của một lần trao đổi đã thất bại. Lưu lượng nền khiến các tổng số càng ít thông tin hơn, vì một số byte có thể là thông điệp giữ kết nối hoặc luồng không liên quan. Hãy đọc chúng như dấu hiệu giao diện đang hoạt động, rồi đừng coi chúng là bằng chứng nữa.

Dữ kiện hữu ích đầu tiên là bắt tay có còn hiện hành hay không. Không có nó thì chưa có gì được mã hóa cho peer này và bộ đếm nhận không có lý do để nhích.

Chọn peer hay đường của phản hồi: hai cách giải thích

Cách giải thích thứ nhất là gói tin chưa bao giờ tới được peer dự định, vì tuyến đường chỉ sang nơi khác hoặc vì tiền tố được phép của peer không bao phủ đích. Cách thứ hai là gói tin đã tới nhưng phản hồi không thể quay về, đây là vấn đề định tuyến ở đầu xa. Bảng phân biệt hai trường hợp theo những gì bạn sẽ quan sát tại mỗi điểm.

Hãy đọc bảng từ trên xuống. Thiếu bắt tay sẽ đưa bạn tới khóa, điểm cuối và đường bên ngoài, vì chưa có gì khác để kiểm tra. Một bắt tay còn hiện hành với yêu cầu hiển thị trên máy chủ sẽ chuyển vấn đề sang hướng quay về, nơi bảng tuyến của chính đích quyết định. Một yêu cầu không bao giờ xuất hiện trên máy chủ là vấn đề chọn lựa, và các tiền tố được phép trên cả hai peer là thứ đầu tiên cần so sánh.

Hai trong bốn hàng đó được sửa ở máy khách và hai ở máy chủ. Biết mình đang ở cặp nào là phần lớn công việc.

Phản hồi biến mất ở đâu

Một phản hồi rời đích, tới giao diện đường hầm của máy chủ và được mã hóa cho peer có địa chỉ được phép khớp với địa chỉ bên trong của máy khách. Nếu sự khớp đó thất bại, phản hồi bị loại bỏ lặng lẽ, điều mà từ phía máy khách trông đúng như một lỗi mạng. Nếu phản hồi đã được mã hóa và bộ lọc của chính máy khách từ chối nó, triệu chứng lại giống hệt. Cả hai trường hợp cần bắt gói chứ không phải bộ đếm.

Dạng mạnh nhất của lỗi này là một máy chủ chuyển tiếp gói cho máy khách nhưng không có tuyến quay lại dải bên trong của máy khách. Nó nhận yêu cầu, gửi phản hồi về phía cổng mặc định của mình, và đường hầm không bao giờ thấy điều đó. Một quy tắc dịch rộng thêm vào máy chủ sẽ che lỗi đó thay vì sửa tuyến.

Thử một đích từ đầu đến cuối

Chọn một đích duy nhất trong dải của peer và thử nó khi bắt tay được chứng minh là còn hiện hành. Các lệnh dưới đây đọc trạng thái peer, tuyến đã chọn và cả hai phía của lần trao đổi. Chạy bắt gói trên giao diện mà các gói đã mã hóa thực sự dùng.

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

Một lần bắt gói cho thấy yêu cầu trên giao diện đường hầm mà không có gì quay về là câu trả lời từ phía máy chủ, và bảng tuyến của đích là nơi tiếp theo cần xem. Nếu không thấy gì cả, gói tin đã đi đường khác, vì vậy tuyến cục bộ là đối tượng bị nghi. Một lần trao đổi thấy được trong cả hai lần bắt gói mà ứng dụng không tiến triển sẽ chuyển câu hỏi sang kích thước gói hoặc sang một bộ lọc mà thống kê giao diện không bao giờ hiển thị. Giữ một đích và một máy khách trong bài thử, vì biến số thứ hai lại biến bằng chứng thành cảm nhận.

Nếu tên truy vấn hỏng trong khi một địa chỉ được phép vẫn chạy, câu trả lời nằm ở DNS chứ không ở đường hầm. Nếu chỉ các lần truyền lớn bị kẹt, hãy xem xét kích thước gói riêng.