Một peer WireGuard không tới được trong khi peer khác hoạt động: danh sách kiểm tra

Một peer WireGuard truyền lưu lượng và peer thứ hai hoàn tất bắt tay nhưng không bao giờ tới được bất cứ thứ gì phía sau đường hầm. Peer đang hoạt động cho bạn biết giao diện, cổng UDP và khóa của máy chủ có lẽ đều ổn. Nó không nói gì về AllowedIPs của peer thứ hai, địa chỉ nguồn bên trong hay các quy tắc chuyển tiếp ở giữa. Đi hết danh sách theo thứ tự và dừng ở bước đầu tiên có điều kiện không thỏa mãn.

Bước 1: Ghi lại đường đi mà gói tin nên đi

Hai máy khách trên cùng một hub không tự động tới được nhau. Trong thiết kế hub và nan hoa, máy chủ nhận gói trên wg0 và phải chuyển tiếp nó ra khỏi wg0 tới peer kia, việc này cần chuyển tiếp IP và một quy tắc chuyển tiếp. Trong thiết kế trực tiếp peer với peer, mỗi bên cần điểm cuối của bên kia và địa chỉ đường hầm của bên kia trong AllowedIPs. Hãy quyết định bạn đang gỡ lỗi thiết kế nào trước khi đọc bất kỳ cấu hình nào.

Đường đi dự kiến cũng cho bạn biết nên nhìn ở đâu. Nếu gói phải đi qua hub, chặng thất bại là AllowedIPs của nơi gửi, chuyển tiếp ở hub, hoặc AllowedIPs của nơi nhận. Nếu gói phải đi trực tiếp, hub không liên quan và các trường điểm cuối trên cả hai peer mới là điều quan trọng.

Bước 2: So sánh AllowedIPs ở cả hai phía, không phải chỉ một phía

WireGuard dùng AllowedIPs vừa như bảng định tuyến vừa như danh sách truy cập. Khi gửi, địa chỉ đích được tra trong AllowedIPs của peer để chọn đường hầm; khi nhận, địa chỉ nguồn bên trong phải nằm trong AllowedIPs của peer gửi, nếu không gói bị loại bỏ. Thiếu một dải ở bất kỳ phía nào cũng cho triệu chứng tương tự: truyền tải hoạt động, phần dữ liệu biến mất.

Hãy đọc trạng thái thực thay vì tệp, vì lần tải lại có thể đã thất bại trong im lặng: sudo wg show wg0 allowed-ips. Trên máy chủ, mục của peer thất bại phải chứa địa chỉ đường hầm của nó, ví dụ 10.90.0.3/32. Trên máy khách, mục của peer máy chủ phải chứa đích bạn đang kiểm tra, dù đó là địa chỉ đường hầm của hub hay mạng con từ xa. Các dải chồng lên nhau khiến việc tra cứu mơ hồ và có thể chọn một peer bạn không định, vì vậy hãy giữ chúng tách biệt.

Bước 3: Kiểm tra địa chỉ nguồn bên trong

Máy khách định tuyến 10.90.0.3 qua wg0 nhưng gửi gói từ địa chỉ Wi-Fi của mình sẽ bị bên nhận từ chối, vì nguồn không khớp với AllowedIPs của peer. Xác nhận điều kernel thực sự chọn bằng ip route get 10.90.0.3 from 10.90.0.2, và xác nhận địa chỉ được gán cho giao diện đường hầm bằng ip -brief addr show wg0.

Trên máy chủ Linux nhận, lọc đường đi ngược là cổng thứ hai. Một rp_filter nghiêm ngặt trên giao diện sở hữu tuyến quay về có thể loại bỏ lưu lượng đường hầm mà đường quay về không khớp với giao diện nó đi vào. Hãy kiểm tra giá trị hiệu lực trước khi tắt nó; trong nhiều sơ đồ mạng, cách sửa đúng là thêm tuyến đường chứ không phải nới lỏng bộ lọc.

Bước 4: Xem lại chuyển tiếp ở hub và đường quay về

Nếu hub phải chuyển tiếp giữa các peer, kernel cần net.ipv4.ip_forward=1, và tường lửa phải chấp nhận luồng được chuyển tiếp: vào trên wg0, ra trên wg0, từ địa chỉ đường hầm của nơi gửi tới địa chỉ của nơi nhận. Lỗi phổ biến là một quy tắc đầu vào chấp nhận UDP 51820 nhưng không có quy tắc chuyển tiếp], nên bắt tay thành công còn phần dữ liệu thì chết. Hãy liệt kê các quy tắc hiệu lực bằng sudo nft list ruleset hoặc lệnh tương đương cho trình quản lý tường lửa của bạn.

Sau đó kiểm tra phản hồi. Máy chủ đích phải có tuyến đường quay về nơi gửi, hoặc qua hub hoặc qua cổng của chính nó. Nếu hub cũng NAT mạng con của đường hầm, hãy xác nhận rằng việc dịch địa chỉ áp dụng cho luồng được chuyển tiếp và phản hồi tới hub trước khi trạng thái hết hạn. Lỗi một chiều trông như vấn đề khóa thường chỉ là tuyến quay về này.

Cuối cùng, tách bắt tay khỏi dữ liệu. Một peer hoàn tất bắt tay nhưng đứng lại khi truyền lớn thường có vấn đề MTU hoặc MSS trên đúng đường đó, không phải vấn đề AllowedIPs. Hãy thử trước bằng ping nhỏ, rồi bằng ping kích thước đầy đủ, và so sánh hai peer.

Bước 5: Chỉ thay đổi một thứ và giữ nguyên peer đang hoạt động

Thực hiện một thay đổi duy nhất trên đường bị lỗi và kiểm tra lại cả hai peer. Thay AllowedIPs của mọi peer bằng 0.0.0.0/0 là cách nhanh nhất để làm hỏng peer vốn đã hoạt động, vì nó thay đổi quyết định định tuyến cho toàn bộ lưu lượng trên giao diện đó. Chỉ sửa mục đó, tải lại và đọc lại trạng thái thực.

Ghi lại đường nào thành công, đường nào thất bại và đầu ra chính xác của lệnh cho từng trường hợp. So sánh đó có giá trị hơn một báo cáo chung rằng VPN bị hỏng, và đó là điều đầu tiên người tiếp theo sẽ hỏi.