WireGuard PersistentKeepalive: giữ ánh xạ NAT còn sống
Nếu kết nối ngược chỉ hoạt động ngay sau khi peer gửi lưu lượng, ánh xạ đang hết hạn. Đặt keepalive phía sau bộ định tuyến rồi đọc thời gian chờ thực tế.
Hộp trong nhà mở đường hầm và đến máy chủ đám mây mà không gặp trục trặc. Máy chủ đám mây có thể đến ứng dụng trong nhà trong một hoặc hai phút sau khi hộp trong nhà gửi thứ gì đó lần cuối, rồi dừng lại. Không có gì xuất hiện trong nhật ký WireGuard, không có lỗi bắt tay nào được báo, và khởi động lại đường hầm sẽ sửa nó trong chốc lát. Mẫu đó là một ánh xạ đang hết hạn, không phải đường hầm hỏng, và hướng dẫn bên dưới xác nhận điều đó trước khi thay đổi bất cứ thứ gì.
Xác nhận rằng mẫu là hết hạn khi không hoạt động
Chi tiết phân biệt là thời điểm. Nếu kết nối ngược hoạt động ngay sau khi peer trong nhà gửi lưu lượng và thất bại sau một khoảng lặng, thì đường đi ổn và trạng thái ở giữa thì không. Nếu nó chưa bao giờ hoạt động, kể cả ngay sau lưu lượng, thì đây là chẩn đoán sai.
sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transferChạy hai lệnh đầu ngay sau khi peer trong nhà gửi thứ gì đó, đợi năm phút và chạy lại. Dấu thời gian bắt tay được làm mới theo lịch mà không có điểm cuối mới cho bạn biết đường hầm còn sống. Điều đã thay đổi là khả năng các gói không được yêu cầu đến từ bên ngoài, đó là thuộc tính của đường đi chứ không phải của đường hầm.
Sau đó thử ngược lại và xem các bộ đếm truyền. Nếu phía đám mây gửi byte còn phía trong nhà không nhận được byte nào, gói đã rời đám mây và chết trong một thiết bị lưu trạng thái trên đường. Đó là dấu hiệu bạn đang tìm. Nếu cả hai bộ đếm đều nhúc nhích, đường hầm đã giao gói và ứng dụng là đối tượng bị nghi.
Đặt keepalive trên peer phía sau bộ định tuyến
Keepalive liên tục giữ một ánh xạ NAT và mọi trạng thái tường lửa còn sống bằng cách gửi một gói nhỏ đã xác thực theo lịch. Thiết lập thuộc về máy phía sau bộ định tuyến, trong mục dành cho peer từ xa, vì chính phía đó tạo ra trạng thái bằng gói đi ra của nó.
[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25Gộp nó vào phần peer hiện có. Thêm một khối thứ hai với cùng khóa công khai không phải là cách hợp lệ để thêm tùy chọn, và wg-quick sẽ không gộp chúng cho bạn. 25 giây được tài liệu hóa là một ví dụ được chọn để nằm dưới các thời gian chờ UDP thông thường, không phải một giá trị mang ý nghĩa đặc biệt.
Đặt cùng chỉ thị ở phía đám mây không giúp ích cho vấn đề này. Các gói của peer đó đã đến từ một địa chỉ công cộng, nên không có ánh xạ nào cần giữ theo hướng quan trọng. Nó thêm lưu lượng và không thay đổi gì.
Đọc bộ hẹn giờ thay vì đoán khoảng
Keepalive hoạt động vì chúng đến thường xuyên hơn so với khi trạng thái hết hạn. Điều đó làm cho thời gian chờ trở thành con số bạn thực sự cần, và trên Linux nó có thể đọc được trên thiết bị thực hiện việc dịch:
sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820Giá trị đầu tiên là thời gian chờ cho một luồng UDP chỉ được thấy theo một hướng, và giá trị thứ hai áp dụng sau khi các phản hồi đã được quan sát. Cả hai thường ngắn, và một ánh xạ im lặng sẽ theo cái áp dụng cho luồng của bạn.
So sánh con số đó với khoảng của bạn. Một keepalive 25 giây dưới thời gian chờ 30 giây hoạt động; cùng keepalive đó dưới thời gian chờ 15 giây thì không hoạt động. Không lượng thử lại nào thay đổi phép tính đó. Một số bộ định tuyến tiêu dùng và nhà mạng di động dùng giá trị ngắn hơn nhiều so với mặc định của Linux, đó là lý do một cấu hình hoạt động trên mạng này lại thất bại trên mạng khác.
| Observation | What it means | Reasonable response |
|---|---|---|
| Works after traffic, dies when idle | Mapping or firewall state expiring | Lower the keepalive interval |
| Never works, even immediately | No return route, listener or firewall | Stop tuning keepalive |
| Works for hours, then dies once | Carrier-side translation or address change | Check the endpoint and logs together |
Kiểm tra trình lắng nghe và tường lửa riêng rẽ
Một ánh xạ còn sống là cần thiết và chưa đủ. Ứng dụng trên hộp trong nhà phải lắng nghe đúng địa chỉ, và tường lửa của máy chủ phải cho phép gói sau khi giải mã.
sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/healthNếu socket chỉ gắn với địa chỉ giao diện vật lý mà không gắn với địa chỉ đường hầm, các gói đến trên đường hầm bị bỏ trước cả khi tường lửa được hỏi. Lỗi đó từ phía đám mây trông giống hệt một vấn đề ánh xạ, và nó sống sót qua mọi điều chỉnh keepalive.
Việc kiểm tra danh sách được phép cũng quan trọng không kém theo chiều ngược lại. Peer đám mây phải cho phép địa chỉ đường hầm trong nhà làm nguồn nếu nó sẽ trả lời, và peer trong nhà phải cho phép địa chỉ đám mây làm đích. Các gói keepalive là lưu lượng đã xác thực và chúng áp dụng cùng các quy tắc, vì thế một keepalive trông như đang hoạt động có thể cùng tồn tại với một ứng dụng không hoạt động.
Triển khai thay đổi và biết giới hạn của nó
Áp dụng thiết lập, khởi động lại giao diện nếu đó là cách cập nhật của bạn, rồi lặp lại bài kiểm tra không hoạt động thay vì bài kiểm tra tức thời. Đợi lâu hơn thời gian chờ bạn đã đọc trước đó, thực hiện một yêu cầu ngược và xác nhận các bộ đếm đã nhúc nhích ở cả hai đầu.
Ghi lại khoảng và thời gian chờ đã đo bên cạnh. Một thay đổi trong tương lai đối với phần mềm của bộ định tuyến, hoặc việc chuyển sang kết nối di động, có thể thay đổi thời gian chờ. Ghi chú là thứ cho phép ai đó suy ra lại giá trị thay vì sao chép nó. Hai con số trên một dòng tiết kiệm cả một cuộc điều tra về sau.
Keepalive liên tục bảo vệ trạng thái. Chúng không mở cổng, không thêm mục vào danh sách được phép và không làm xuất hiện trình lắng nghe. Khi kết nối ngược hoàn toàn không hoạt động, lỗi nằm ở một trong ba điều đó, và hướng dẫn nhanh của WireGuard mô tả thiết lập keepalive bằng đúng những thuật ngữ hẹp đó.