VPN rớt khi màn hình tối đi: khóa, màn hình tắt hay ngủ đông?
Một phiên bị khóa, một màn hình tối và một máy đang ngủ là ba sự kiện khác nhau. Hãy đối chiếu chúng với journalctl trước khi đổ lỗi cho cơ chế giữ kết nối của VPN.
Khi ai đó nói VPN chết khi màn hình tối đi, câu hỏi hữu ích đầu tiên là sự kiện nào trong ba sự kiện thực sự đã xảy ra: phiên bị khóa, bảng hiển thị bị tắt, hay toàn bộ máy đi vào giấc ngủ. Đó là những cơ chế riêng trên những bộ đếm thời gian riêng, và chỉ một trong số chúng có thể ngăn hoàn toàn việc một tiến trình được lập lịch. Hãy đi qua các kiểm tra dưới đây theo thứ tự. Dừng ở kiểm tra đầu tiên trả lời câu hỏi, vì mọi kiểm tra sau đó đang trả lời một việc khác.
Kiểm tra một: tách khóa ra khỏi màn hình tắt và khỏi giấc ngủ
Khóa thay đổi ai được phép dùng phiên; trình kết hợp vẫn tiếp tục vẽ, ngăn xếp mạng vẫn tiếp tục chạy và ứng dụng khách VPN không nhận ra gì. Việc tắt màn hình sẽ tắt bảng hiển thị sau một khoảng không hoạt động và để máy hoàn toàn tỉnh. Ngủ đông dừng các CPU, nghĩa là không tiến trình nào trong không gian người dùng được lập lịch, nên không tín hiệu giữ kết nối nào có thể kích hoạt, dù bạn đặt khoảng thời gian ngắn đến đâu.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
Chính bảng đó là lý do «màn hình tối đi» không phải là chẩn đoán. Một máy để bàn đặt tắt màn hình sau năm phút và ngủ sau ba mươi sẽ cho thấy màn hình tối ở phút thứ sáu với đường hầm hoàn toàn khỏe mạnh. Sự cố ở phút thứ ba mươi là sự kiện khác với cách khắc phục khác, và cả hai trông giống nhau từ phía bên kia căn phòng.
Kiểm tra hai: đặt các sự kiện nguồn và mạng trên một dòng thời gian
Đọc nhật ký cho một cửa sổ giới hạn thay vì toàn bộ quá trình khởi động, và bao gồm cả trình quản lý đăng nhập lẫn chủ sở hữu kết nối:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listLệnh đầu tiên cho thấy các yêu cầu ngủ, việc thức dậy và các chuyển đổi mạng theo sau chúng. Lệnh thứ hai cho thấy hiện tại cái gì đang giữ một khóa ức chế, điều này cho bạn biết có gì đó đang chặn giấc ngủ một cách có chủ ý và đó là chương trình nào. Hãy chỉnh tên đơn vị nếu chủ sở hữu kết nối của bạn không phải NetworkManager, và nhớ rằng việc đọc đơn vị của người dùng khác hoặc nhật ký hệ thống phụ thuộc vào chính sách cục bộ.
Một dòng thiếu không phải là kết quả phủ định. Nếu nhật ký của đơn vị đã chọn không hiển thị với tài khoản của bạn, việc không có bản ghi ngủ không chứng minh điều gì, và kết luận «nó chưa bao giờ ngủ» từ một bộ lọc rỗng chính là cách người ta dành một tuần để chỉnh tín hiệu giữ kết nối.
Kiểm tra ba: nếu nó đã ngủ, hãy quyết định xem đó có phải là chủ ý
Ngay khi một chuyển đổi giấc ngủ xuất hiện trên dòng thời gian, câu hỏi chuyển từ vì sao VPN hỏng sang liệu máy có nên ngủ hay không. Trên máy tính xách tay câu trả lời thường là có, và việc đứt đường hầm là hành vi mong đợi mà ứng dụng khách phải phục hồi khi thức dậy. Trên một máy trạm phải luôn truy cập được, chính sách ngủ là thứ cần thay đổi. Để quyết định bạn đang nhìn máy nào trong hai máy này cần một câu hỏi, và đó không phải câu hỏi mà nhật ký có thể trả lời thay bạn.
Hãy thay đổi nó qua các điều khiển thuộc về phiên đã đăng nhập, hoặc qua một cơ chế được quản trị viên hỗ trợ nếu yêu cầu áp dụng cho toàn máy. Việc sửa một cài đặt của trình quản lý hiển thị khi bạn đang đăng nhập bằng tài khoản khác không phải cùng một hành động và sẽ trông như đã có tác dụng cho đến khi phiên tiếp theo bắt đầu. Tắt hoàn toàn quản lý nguồn là phản ứng đầu tiên quá rộng, tốn tuổi thọ pin và che giấu câu hỏi chính sách thực sự.
Kiểm tra bốn: nếu nó vẫn thức, hãy xem mạng và ứng dụng khách
Một máy đang thức mà mất đường hầm có một trong ba câu chuyện: mạng truy cập rớt, ứng dụng khách VPN dừng hoặc khởi động lại, hoặc phía máy chủ để liên kết hết hạn trong khi ứng dụng khách vẫn tin rằng nó đang kết nối. Hãy so sánh dấu thời gian của sự kiện liên kết bên dưới với sự kiện đường hầm, và nói chính xác cái nào đến trước.
Sau đó hãy thử đường phục hồi riêng, tách khỏi phiên ban đầu. Một yêu cầu mới qua đường hầm đã phục hồi có thể thành công trong khi phiên ứng dụng dài hạn được mở trước khi đứt vẫn hỏng, vì ứng dụng đang giữ một socket cũ hoặc một địa chỉ đã lưu trong bộ nhớ đệm. Đó là vấn đề của ứng dụng, không phải bằng chứng rằng đường hầm không trở lại.
Một báo cáo hữu ích gồm những gì
Hãy viết trình tự kèm dấu thời gian và người phụ trách: phiên bị khóa khi nào, màn hình tối khi nào, có ghi nhận yêu cầu ngủ hay không, liên kết rớt và trở lại khi nào, đường hầm đổi trạng thái khi nào và ứng dụng thực sự đã làm gì. Mỗi mục đều có người phụ trách, nên mỗi mục có thể được giao cho đúng người thay vì trở thành một lời phàn nàn chung về Linux.
Nếu thiếu bất kỳ dòng nào trong số đó, đó là việc tiếp theo cần đo chứ không phải việc tiếp theo cần thay đổi. Một dòng thời gian có lỗ hổng cho biết nhiều hơn một thay đổi cài đặt dựa trên phỏng đoán.