VPN rớt khi tắt màn hình: vòng đời nào?

Việc truyền dừng ngay khi màn hình tối đi, và huy hiệu xuất hiện vài giây sau đó. Ba thứ khác nhau tạo ra bức tranh ấy: tiến trình ứng dụng khách bị hạn chế, đường đi rảnh rỗi và mất ánh xạ, hoặc ứng dụng mất một phiên mà đường hầm chưa từng nhận ra. Mỗi cái có bằng chứng riêng, và mỗi cách sửa thuộc một lớp khác. Thứ tự dưới đây phân tách chúng bằng một bài kiểm tra có kiểm soát thay vì rà soát mọi cài đặt.

Ba lỗi trông giống hệt nhau

Một tiến trình nền bị hạn chế ngừng gửi keepalive, và phía bên kia cuối cùng tuyên bố đường hầm đã chết. Ánh xạ rảnh rỗi trên đường đi có thể hết hạn trong khi thiết bị ngủ, nên lưu lượng quay về không bao giờ đến được một ứng dụng khách vẫn còn sống hoàn toàn. Ứng dụng có thể mất kết nối của chính nó trong khi đường hầm vẫn đứng, tạo ra hộp thoại lỗi với huy hiệu VPN khỏe mạnh phía sau. Từ góc nhìn người dùng, cả ba đều được đọc là VPN rớt khi tắt màn hình.

Sự phân biệt quan trọng vì các cách khắc phục mâu thuẫn nhau trên thực tế. Miễn trừ ứng dụng khách khỏi giới hạn năng lượng sửa trường hợp đầu và không làm gì cho ánh xạ đã hết hạn. Kéo dài keepalive sửa trường hợp thứ hai và lãng phí pin ở trường hợp thứ ba, nơi vốn dĩ không có gì về mạng bị sai.

So sánh trạng thái hoạt động và rảnh rỗi trong điều kiện kiểm soát

Giữ mọi thứ cố định: cùng thiết bị, cùng mạng, cùng điểm cuối, cùng ứng dụng. Khóa màn hình trong một khoảng ngắn cố định và ghi ba quan sát: ứng dụng khách có báo ngắt kết nối không, một yêu cầu mới có hoạt động khi mở khóa không, và việc truyền hiện có có tiếp tục không. Sau đó lặp lại với keepalive hoặc yêu cầu định kỳ đang chạy và so sánh hai lần chạy. Một biến thay đổi giữa hai lần chạy đáng giá hơn một tuần báo cáo giai thoại.

Thời điểm thuộc về biên bản. Rớt sau chín mươi giây gợi đến ánh xạ hoặc khoảng keepalive, trong khi rớt ngay lúc khóa chỉ ra việc tạm dừng tiến trình. Ghi lại cả nguyên nhân kích hoạt và khoảng thời gian, vì lần thử tiếp theo cần thứ gì đó để so sánh.

Đọc chính sách nền của nền tảng

Trên Android, vòng đời dịch vụ VPN là một phần của nền tảng, và always-on cùng block-without-VPN là các công tắc riêng với hiệu ứng riêng. Một ứng dụng khách không phải always-on có thể bị dừng khi hệ thống thu hồi tài nguyên, và không cài đặt nào trong ứng dụng thay đổi điều đó. iOS áp đặt giới hạn nền của riêng nó lên nhà cung cấp đường hầm, và hành vi được ghi nhận khác với một daemon máy tính để bàn chỉ tiếp tục chạy. Hãy đọc tài liệu nền tảng cho thành phần liên quan, không phải hướng dẫn tối ưu pin chung chung.

Thiết bị được quản lý thêm một lớp nữa. Chính sách có thể ghi đè cài đặt cá nhân, nên một thay đổi trông như hoạt động sẽ quay lại ở lần làm mới chính sách tiếp theo. Dùng quy trình ngoại lệ được tổ chức hỗ trợ nếu yêu cầu là thật, và ghi lại vì sao ngoại lệ tồn tại.

Thiết bị làm gì sau khi thức dậy

Kết nối lại tự động không giống với chặn lưu lượng trong khoảng trống. Kiểm tra cả hai: đường hầm có quay lại không, và một ứng dụng đã cố gửi trong khoảng trống có đi ra mà không được bảo vệ không. Một ứng dụng khách kết nối lại trong hai giây nhưng rò rỉ truy vấn DNS trong giây đầu tiên có chính sách lỗi sai cho thiết bị làm việc. Hãy thử với các yêu cầu vô hại và một điểm đến bạn kiểm soát.

Phục hồi ứng dụng là câu hỏi thứ ba. Một đường hầm quay lại không sửa được phiên SSH đã hết thời gian, và người dùng thường báo mất phiên đó như lỗi VPN. Giữ cùng nhau trong báo cáo nguyên nhân kích hoạt, bản dựng ứng dụng khách và thời điểm chính xác, vì sự kết hợp đó phân tách một vòng đời tắt màn hình có thể dự đoán khỏi một máy chủ hỏng độc lập với thiết bị.