WireGuard không hiển thị handshake gần nhất: nên kiểm tra gì trước
Một handshake trống có thể chỉ đơn giản là chưa có gì được gửi. Kích hoạt một gói được phép, rồi kiểm tra tuyến, cặp khóa và đường UDP bên ngoài.
Trường handshake gần nhất trống thường có nghĩa là giao diện chưa hoàn tất handshake nào kể từ khi khởi động, điều này nói về cấu hình ít hơn vẻ ngoài của nó. WireGuard im lặng cho đến khi một gói cần rời khỏi giao diện, nên một peer nhàn rỗi không có gì để gửi sẽ báo đúng như vậy. Xác định xem có thực sự có gì được đề nghị hay chưa trước khi kiểm tra khóa.
Bài kiểm tra là một gói được phép hướng tới đích mà peer phải chuyên chở. Mọi thứ khác trên màn hình trạng thái đó mô tả ý định chứ không phải hoạt động.
Giao diện nhàn rỗi không có gì để báo cáo
WireGuard thực hiện handshake một cách lười biếng: gói đầu tiên cần đường hầm sẽ kích hoạt trao đổi, và giao diện im lặng cho đến lúc đó. Một peer đã được cấu hình mà chưa từng dùng hiển thị handshake trống, không byte nhận được và khoảng cách ngày càng lớn kể từ lần cuối. Trạng thái đó lành mạnh với một máy khách nhàn rỗi và chỉ đáng lo nếu bạn kỳ vọng lưu lượng đã chảy. Cũng kiểm tra bộ đếm truyền, vì chúng phân biệt chưa-gửi-gì với đã-thử-và-thất-bại.
Nếu bộ đếm ở cả hai bên đều bằng không, vấn đề nằm phía trên đường hầm. Không có gì đến được giao diện để kích hoạt bất cứ điều gì.
Kích hoạt lưu lượng mà peer được phép chuyên chở
Chọn một địa chỉ bên trong các tiền tố được phép của peer, trên máy cục bộ, và xác nhận bảng định tuyến sẽ gửi nó qua giao diện. Một đích ngoài các tiền tố đó tạo ra một yêu cầu định tuyến thông thường mà không có bất kỳ sự tham gia nào của WireGuard. Dùng một dịch vụ trả lời nhanh, như ping hoặc một kết nối TCP ngắn, để lần thử có khởi đầu và kết thúc nhìn thấy được. Sau đó đọc lại dòng handshake thay vì nhìn màn hình và chờ.
ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer
Truy vấn tuyến quan trọng hơn ping. Nếu nó nêu giao diện vật lý, gói đã không vào đường hầm và handshake trống là câu trả lời định tuyến, không phải mật mã. Sửa tuyến trước khi gỡ lỗi peer.
So sánh cặp khóa và điểm cuối
Khi lưu lượng thực sự được đề nghị, bước kiểm tra tiếp theo là danh tính. Khóa riêng cục bộ phải khớp với khóa công khai mà phía kia cho phép, khóa công khai từ xa đã cấu hình phải nhận diện đúng peer dự định, và bất kỳ khóa chia sẻ trước nào cũng phải khớp ở cả hai đầu. Chỉ một ký tự khác trong khóa base64 sẽ tạo ra một peer trông như đã cấu hình mà không bao giờ hoàn tất trao đổi. So sánh với hồ sơ cấp phát thay vì tạo lại khóa, vì khóa mới vô hiệu hóa mọi peer đã tin khóa cũ.
Điểm cuối cần sự xem xét tương tự: tên máy chủ, địa chỉ, cổng UDP và họ địa chỉ dùng để đến nó. Một địa chỉ cũ hoặc cổng sai tạo ra im lặng thay vì thông báo.
Theo dõi đường UDP bên ngoài
Handshake đi như UDP về phía điểm cuối, nên đường bên ngoài phải chuyên chở nó. Các lệnh dưới đây kiểm tra xem có trình lắng nghe không, ngăn xếp cục bộ có gửi datagram không, và điểm cuối nào đã được cấu hình. Chạy bắt gói trong khi kích hoạt lưu lượng, không phải trước đó.
ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820
Một bản bắt gói cho thấy khởi tạo mà không có phản hồi chỉ ra bên ngoài máy, vì đầu xa hoặc không lắng nghe, hoặc bị lọc, hoặc bị đánh địa chỉ sai. Một bản bắt gói không cho thấy gì nghĩa là gói chưa từng rời đi, điều này đưa bạn trở lại tuyến và mọi dấu socket đang tham gia. Khi bạn quản trị cả hai đầu, hãy tương quan lần thử theo dấu thời gian với một bản bắt gói hẹp trên máy chủ thay vì bản tổng quát. Bài kiểm tra cổng TCP không chứng minh gì ở đây, vì giao thức chỉ là UDP.
Ngay khi một handshake xuất hiện, hãy thử một ứng dụng qua đường hầm, vì một trao đổi hoàn tất chứng minh danh tính và khả năng đến được, không phải thông lượng dùng được hay DNS đúng. Giữ đầu ra trạng thái trước và sau thay đổi, và khác biệt sẽ trở thành bằng chứng của bạn.