Handshake vẫn sống, địa chỉ đã mất: ba trạng thái của WireGuard

WireGuard có thể giữ một handshake mới và đồng thời không có địa chỉ, và trạng thái đó là nhất quán chứ không mâu thuẫn. Handshake là sự kiện của peer, địa chỉ thuộc về giao diện, và tuyến đường quyết định gói đi ra qua đường lên nào. Ba tầng, ba chủ sở hữu, và mỗi tầng có thể hỏng trong khi hai tầng kia trông vẫn khỏe.

Đọc chúng như một trạng thái duy nhất chính là điều biến một chẩn đoán hai phút thành cả buổi chiều khởi động lại dịch vụ.

Handshake là sự kiện của peer, không phải sự kiện đánh địa chỉ

Handshake của WireGuard chứng minh peer đã cấu hình trả lời bằng một khóa hợp lệ và các khóa phiên còn hiệu lực. Nó không nói gì về địa chỉ cục bộ trên giao diện, cũng không nói liệu có tuyến nào trỏ tới đó. Địa chỉ do một trình trợ giúp hoặc trình quản lý mạng gán, còn cấu hình giao thức chỉ đặt tên cho peer và khóa. Nhầm lẫn hai thứ này là lý do một handshake khỏe bị đọc thành đường hầm đang hoạt động.

Vì thế wg show có thể báo một handshake vài giây tuổi trên giao diện không nhận nổi một gói nào từ ứng dụng.

Trình quản lý tạo lại giao diện có thể đánh rơi địa chỉ mà không chạm vào cấu hình peer, và handshake tiếp theo thành công ngay vì khóa chưa bao giờ đổi. Dòng nhật ký về một handshake thành công là chính xác và không liên quan đến sự cố.

Địa chỉ của giao diện có chủ sở hữu riêng

Địa chỉ trên thiết bị đường hầm có thể đến từ dòng Address của trình trợ giúp, từ một máy khách DHCP chạy trên giao diện, hoặc từ một daemon quản lý tạo nó khi kết nối. Dù là gì, thành phần đó sở hữu địa chỉ và sẽ khôi phục nó hoặc không theo logic của riêng mình. Đọc địa chỉ mà không nêu tên chủ sở hữu khiến bạn không giải thích được vì sao nó biến mất.

Hai chủ sở hữu trên một giao diện là sự cố kinh điển. Khởi động một trình trợ giúp và một trình quản lý mạng máy tính để bàn trên cùng thiết bị tạo ra một cuộc đua, trong đó cái này xóa thứ cái kia vừa cấu hình, và điểm cuối vẫn trả lời suốt thời gian đó.

Chọn một chủ sở hữu và để công cụ kia quan sát thay vì quản lý. Quyết định đó đáng được ghi lại, vì triệu chứng xuất hiện hàng tuần sau và trông như mất địa chỉ ngẫu nhiên.

Tuyến đường chọn đường lên, không phải giao diện

Một tuyến bên trong trỏ tới wg0 quyết định rằng lưu lượng đi vào đường hầm. Một quyết định riêng gửi các gói bên ngoài đã mã hóa về phía peer, và trên một máy có nhiều đường lên, quyết định đó đến từ bảng chuyển tiếp và các quy tắc chính sách. Chuyển vùng Wi-Fi có thể đổi đường đi bên ngoài mà không chạm vào địa chỉ bên trong.

Vì vậy một đường hầm hoạt động và một peer không tới được là những trạng thái tương thích, cũng như một peer đúng và một tuyến bên trong hỏng. Ba quan sát phải được lấy cùng nhau, tại cùng một thời điểm, nếu không thì so sánh vô nghĩa.

So sánh ba trạng thái trong một lượt

Ba lệnh chỉ đọc trả lời ba câu hỏi theo thứ tự cô lập sự cố nhanh nhất. Chạy chúng mà không thay đổi gì ở giữa.

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

Lệnh đầu cho biết giao diện có địa chỉ hay không, lệnh thứ hai cho biết một đích cụ thể sẽ dùng thiết bị nào ngay lúc này. Lệnh thứ ba báo thời điểm handshake cuối và các bộ đếm byte, và là lệnh duy nhất trong ba mô tả peer chứ không phải máy cục bộ.

Đọc các bộ đếm cùng với dấu thời gian. Một handshake liên tục làm mới trong khi truyền tải đứng yên nghĩa là peer trả lời nhưng không có gì hữu ích đi qua, điều này chỉ về định tuyến hoặc một ACL chứ không phải khóa. Một dấu thời gian ngừng tiến lên khi có địa chỉ lại chỉ về phía thượng nguồn. Cả hai cách đọc đều đến từ cùng một dòng đầu ra, và không cái nào nhìn thấy nếu bạn chỉ kiểm tra rằng có tồn tại một handshake.

Sửa đúng trạng thái cụ thể bị sai, rồi kiểm tra lại ứng dụng chứ không phải đường hầm. Một handshake mới là bằng chứng về peer, và bằng chứng về peer không phải bằng chứng rằng yêu cầu tiếp theo từ trình duyệt của bạn sẽ tìm thấy địa chỉ, tuyến đường và đường lên hoạt động. hướng dẫn wg-quick nói rõ cái nào trong số đó do trình trợ giúp thiết lập và cái nào thuộc về giao thức.