Khắc phục tình trạng VPN rớt khi nhàn rỗi: danh sách kiểm tra tiết kiệm điện Wi-Fi

Đường hầm của bạn chết sau khi máy tính xách tay nằm yên một lúc, và nó trở lại ngay khoảnh khắc bạn chạm vào bàn di chuột. Kiểu mẫu đó cho thấy liên kết không dây đang chuyển sang chế độ tiết kiệm điện, chứ không phải cổng VPN đang từ chối thông tin đăng nhập của bạn. Một buổi sáng bận rộn trên cùng hồ sơ là bằng chứng: đường hầm sống khi lưu lượng chảy và rớt khi sóng vô tuyến im lặng. Hãy đi qua các kiểm tra dưới đây theo thứ tự, dừng ở kiểm tra đầu tiên thất bại, và chỉ sau đó mới đổi một cài đặt.

Kiểm tra một: tình trạng rớt có đi theo thời gian nhàn rỗi không?

Bắt đầu bằng việc chứng minh mối tương quan thay vì giả định nó. Ghi lại giờ đồng hồ treo tường của gói cuối cùng bạn gửi, thời điểm ứng dụng khách báo đường hầm đã xuống, và liệu màn hình có tắt trong khoảng đó không. Nếu khoảng cách lần nào cũng như nhau, bạn có vấn đề trên đường nhàn rỗi; nếu các lần rớt xảy ra ngẫu nhiên khi đang dùng, hãy nhảy tới kiểm tra năm.

Một thử nghiệm rẻ tiền không tốn gì để hoàn tác: gửi ping đều đặn tốc độ thấp tới cổng của bạn trong hai mươi phút và để máy yên. Nếu đường hầm trụ suốt thời gian, lưu lượng nhỏ liên tục đang che triệu chứng chứ không sửa nó, đây vẫn là bằng chứng hữu ích. Tôi giữ kết quả ping đó trong một terminal nháp và sau đó so với nhật ký ứng dụng khách, vì hai đồng hồ hiếm khi khớp nhau.

Kiểm tra hai: có phải chỉ lưu lượng VPN?

Trước khi đổ lỗi cho đường hầm, hãy xem bản thân liên kết còn dùng được không. Khi đường hầm đã chết nhưng màn hình vẫn tắt, hãy thử tới địa chỉ điểm truy cập và một máy chủ công cộng bằng IP. Nếu ping thường cũng thất bại, sóng vô tuyến hoặc điểm truy cập đã bỏ bạn, và ứng dụng khách VPN chỉ là người xem.

Nếu lưu lượng thường vẫn chảy trong khi đường hầm im lặng, liên kết khỏe mạnh và vấn đề nằm ở bộ đếm thời gian của chính đường hầm hoặc ở cách ứng dụng khách xử lý việc tiếp tục. Đó là hai cách sửa khác nhau, nên đừng bỏ qua bước này. Trên máy có cả Wi-Fi và Ethernet, hãy rút cáp và lặp lại thử nghiệm nhàn rỗi: một lần rớt khi nhàn rỗi biến mất trên Ethernet có dây là bằng chứng mạnh cho tầng không dây.

Kiểm tra ba: đọc trạng thái tiết kiệm điện

Hầu hết môi trường máy tính để bàn cho bạn một ô đánh dấu, nhưng ô đó không phải trạng thái mà trình điều khiển đang ở. Hãy đọc báo cáo của chính trình điều khiển trước, rồi quyết định. Trên Linux có mac80211, giao diện trả lời trực tiếp:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

Lệnh thứ hai là thử nghiệm, không phải cách sửa. Nó không tồn tại qua lần ngắt kết nối, ngủ hay khởi động lại, điều đó khiến nó thành cách sạch để kiểm chứng giả thuyết mà không để lại thay đổi vĩnh viễn.

Trên Windows powercfg /q SCHEME_CURRENT in ra sơ đồ đang hoạt động, và nhánh con của bộ điều hợp không dây cho biết có thể ra lệnh cho bộ điều hợp tiết kiệm điện hay không; lựa chọn tương tự cũng có trong Device Manager ở tab quản lý nguồn của bộ điều hợp. Trên macOS, tiết kiệm điện 802.11 theo từng giao diện không được hiển thị cho bạn, nên hãy xem thay vào đó pmset -g hành vi ngủ và chờ. Ở đó lỗi thường hóa ra là đường ngủ và thức dậy chứ không phải hành vi nhàn rỗi của sóng vô tuyến.

Kiểm tra bốn: đổi một thứ, rồi kiểm tra lại

Đổi đúng một biến mỗi lần chạy và lặp lại cùng khối lượng công việc. Nếu đường hầm giờ chịu được một giờ nhàn rỗi với tiết kiệm điện đã tắt, bạn đã học được điều thật. Nếu nó vẫn rớt, hãy hoàn nguyên trước khi thử ý tưởng tiếp theo, nếu không bạn sẽ còn lại ba cài đặt chồng chéo và không biết cái nào quan trọng.

Giữ kết nối sống là biến độc lập còn lại và nó liên tục bị nhầm với tiết kiệm điện. Giá trị PersistentKeepalive = 25 của WireGuard giữ một ánh xạ NAT ấm;OpenVPN ở cả hai đầu keepalive và ping-restart sử dụng. Cả hai đều tạo lưu lượng trên một đường hầm mà nếu không sẽ im lặng, nên một cơ chế giữ sống có vẻ sửa được tình trạng rớt có thể đang che một vấn đề sóng vô tuyến thay vì giải quyết nó. Hãy thử chúng riêng rẽ, từng cái một:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

Kiểm tra năm: khi sóng vô tuyến vô can

Nếu các lần rớt khi nhàn rỗi vẫn tiếp diễn với tiết kiệm điện đã tắt và giữ kết nối sống đã bật, hãy nhìn ra ngoài máy tính. Các điểm truy cập và router gia đình để các mục NAT hoặc phiên nhàn rỗi hết hạn theo lịch riêng của chúng, và máy chủ VPN có thể bỏ một phiên không có lưu lượng.Chuyển vùng giữa các điểm truy cập dùng chung một SSID cũng có thể đặt lại liên kết mà ứng dụng khách không nói rõ.

Sau đó so sánh với thiết bị thứ hai trên cùng mạng thực hiện cùng thử nghiệm nhàn rỗi. Hai thiết bị rớt cùng một khoảng là câu chuyện về đường đi hoặc máy chủ; một thiết bị rớt là câu chuyện về trình điều khiển hoặc nguồn cục bộ. Việc so sánh đó tốn mười phút và cứu bạn khỏi viết lại cấu hình sai.

Trước khi biến nó thành vĩnh viễn

Hãy quyết định bạn sẵn sàng giữ lại gì. Một script theo hồ sơ chỉ tắt tiết kiệm điện trên những mạng nơi bạn đã thấy rớt là hợp lý. Một tinh chỉnh toàn cục tắt mọi thứ và trả giá bằng thời lượng pin trên mọi mạng thường thì không.

• Ghi lại giá trị tiết kiệm điện ban đầu bên cạnh script để có thể khôi phục.
• Lặp lại thử nghiệm nhàn rỗi sau mỗi lần cập nhật trình điều khiển hoặc ứng dụng khách; giá trị mặc định thay đổi.
• Giữ nhật ký ping và nhật ký ứng dụng khách cùng nhau khi bạn báo cáo vấn đề.
• Nếu bước hai thất bại, hãy ngừng đổi cài đặt VPN và coi đó là lỗi liên kết cục bộ.

Nếu bạn chỉ làm một việc, hãy làm kiểm tra hai. Đó là thứ quyết định phần còn lại của danh sách này có áp dụng cho bạn hay không, và cũng là bước người ta bỏ qua sau khi đã quyết rằng câu trả lời là tiết kiệm điện.