VPN qua UDP đứng im khi nhàn rỗi: tường lửa đã quên luồng của bạn

VPN kết nối, chạy được một lúc rồi ngừng truyền lưu lượng trong khi máy khách vẫn hiển thị phiên. Kết nối lại khắc phục được, khiến nó trông như lỗi của máy khách. Thường thì đó là tường lửa hoặc thiết bị NAT đã bỏ ánh xạ UDP không hoạt động và không biết đường hầm vẫn còn tồn tại.

Triệu chứng đủ nhất quán để chẩn đoán: nó xuất hiện sau khi không hoạt động, không phải khi chịu tải.

Đứng im do nhàn rỗi trông như thế nào

Hãy đo chứ đừng mô tả. Ghi lại đường hầm nằm im bao lâu trước khi lưu lượng dừng, một gói đi ra mới có làm nó sống lại không, và giao diện máy khách có còn giữ địa chỉ của nó không. Nếu yêu cầu mới từ máy khách chạy được nhưng phản hồi cho một luồng sẵn có thì không, ánh xạ là đối tượng tình nghi. Nếu không có gì chạy được cho đến khi bạn kết nối lại, trạng thái phiên của máy khách cũng đã mất.

Cả hai đều liên quan đến nhàn rỗi, và chúng cần cách xử lý khác nhau.

Ghi lại thời gian trước khi thay đổi bất cứ điều gì. Báo cáo rằng nó dừng sau khoảng mười phút nhàn rỗi thì kiểm chứng được, còn báo cáo rằng nó rớt ngẫu nhiên thì không. Khác biệt đó quyết định bạn truy bộ đếm thời gian hay truy thay đổi định tuyến.

Tìm thiết bị đã quên

Nhiều thiết bị có thể giữ trạng thái cho cùng một luồng: bộ định tuyến trong nhà, bộ phiên dịch phía trên, ranh giới đám mây và tường lửa của máy chủ. Mỗi thiết bị có bộ đếm thời gian riêng, và cái ngắn nhất thắng. Gián đoạn năm phút thường có nghĩa một thiết bị được cấu hình thấp hơn hẳn các thiết bị còn lại.

Đừng cho rằng giá trị mặc định được ghi trong tài liệu chính là thời gian chờ trên đường đi của bạn. Đó là mặc định của một thiết bị.

• Bộ định tuyến gia đình: thường là vài phút, đôi khi ít hơn nhiều.
• NAT đám mây hoặc bộ cân bằng tải: tra cứu thời gian chờ nhàn rỗi được ghi trong tài liệu dành riêng cho UDP.
• Tường lửa của máy chủ: bộ đếm theo dõi netfilter áp dụng cho từng luồng.

Kiểm tra bộ đếm thời gian trên đường đi thực tế

Trên Linux, bộ đếm theo dõi netfilter hiển thị và điều chỉnh được: sysctl net.netfilter.nf_conntrack_udp_timeout và net.netfilter.nf_conntrack_udp_timeout_stream. Cái thứ hai áp dụng sau khi đã thấy lưu lượng theo cả hai chiều, vì thế một đường hầm đã thiết lập có thể sống lâu hơn một lần thăm dò đơn thuần.

RFC 4787 quy định hành vi NAT cho UDP và các mức tối thiểu được khuyến nghị. Đó là tài liệu tham chiếu cần trích dẫn khi giá trị mặc định của nhà cung cấp trông ngắn bất thường.

Keepalive và kết nối lại là hai công cụ khác nhau

Keepalive giữ cho ánh xạ còn sống; kết nối lại dựng lại một phiên đã chết. Chúng xử lý những hỏng hóc khác nhau và không phải là cài đặt tốc độ thay thế cho nhau. Tùy chọn PersistentKeepalive của WireGuard gửi gói theo khoảng thời gian cố định để giữ ràng buộc NAT mở. Tùy chọn keepalive của OpenVPN làm công việc tương tự theo cách riêng. Không cái nào giúp được nếu thiết bị ở giữa đã quên luồng và đang bỏ cả hai chiều.

Thăm dò quá thường xuyên chỉ thêm việc mà không sửa đúng ranh giới.

Kiểm chứng bằng yêu cầu mới, không phải bằng tải lại trang

Sau khi đổi bộ đếm thời gian hoặc thêm keepalive, hãy lặp lại kịch bản nhàn rỗi đúng như trước. Sau đó gửi một yêu cầu thực sự mới từ ứng dụng được bảo phủ. Một thẻ trình duyệt đã tải sẵn có thể hiển thị từ bộ nhớ đệm và chẳng cho bạn biết gì.

Nếu tình trạng đứng im vẫn tiếp diễn, hãy dịch ra ngoài một bước nhảy và kiểm tra bảng trạng thái của thiết bị đó.