VPN chết sau khi ngủ: mất đường hầm hay ứng dụng cũ?

Nắp máy mở ra, biểu tượng không dây trở lại, và VPN vẫn hiển thị là đã kết nối. Trang nội bộ đầu tiên sau đó treo cho đến khi hết thời gian chờ, và một thẻ mới cũng làm như vậy. Ba thứ khác nhau có thể tạo ra hình ảnh đó và chúng cần ba cách sửa khác nhau: một đường hầm không sống sót qua giấc ngủ, một hồ sơ mà không ai yêu cầu kích hoạt lại, hoặc một ứng dụng vẫn giữ phiên đã chết từ nhiều giờ trước. So sánh chúng nhanh hơn cài đặt lại bất cứ thứ gì.

Ba thứ có thể hỏng sau khi thức dậy

Ứng viên đầu tiên là chính đường hầm. Giao diện có thể vẫn tồn tại với một địa chỉ trong khi liên kết với đối tác đã mất, vì vậy đèn chỉ báo không phải là bằng chứng của một đường đi hoạt động. Một lần bắt tay cũ hơn giấc ngủ là dấu hiệu, và chỉ cần một lệnh để thấy nó.

Thứ hai là kích hoạt. Nhiều ứng dụng khách tự kết nối lại; một số thì không, và một hồ sơ không được ai yêu cầu quay lại sẽ ngồi đó trông như đã được cấu hình. Lỗi đó im lặng theo thiết kế, vì không có gì báo lỗi.

Thứ ba là ứng dụng. Một thẻ trình duyệt, một phiên SSH hay một kết nối cơ sở dữ liệu có thể sống sót qua thay đổi mạng như một bộ mô tả tệp trong khi tầng truyền bên dưới đã chết. Sau đó một phiên mới hoạt động hoàn hảo, điều này cho bạn biết đường hầm vẫn ổn suốt thời gian.

So sánh cả ba trước khi thay đổi bất cứ điều gì, vì các cách sửa không chồng lên nhau. Khởi động lại một ứng dụng khách chưa từng được yêu cầu chạy lại sẽ lãng phí bằng chứng bạn cần. Ghi lại triệu chứng khớp với ứng viên nào trước khi chạm vào cấu hình. Một câu đó thường quyết định phần còn lại của cuộc điều tra.

Thứ nhất: đường hầm có trở lại không?

Hãy nhìn giao diện và trạng thái đối tác thay vì văn bản trạng thái của ứng dụng khách. Một giao diện có địa chỉ mà không có lần bắt tay gần đây là đường hầm chỉ tồn tại trên danh nghĩa.

ip -brief addr show
wg show
ip route show table all | head -20

Nếu giao diện hoàn toàn không có, đường hầm không sống sót và câu hỏi trở thành ai lẽ ra phải đưa nó trở lại. Nếu nó có nhưng lần bắt tay đã cũ, liên kết với đối tác cần được thiết lập lại, và ứng dụng khách có thể đang chờ lưu lượng để kích hoạt nó.

Cũng kiểm tra các tuyến và cấu hình DNS. Đường hầm có thể trở lại mà không có các tuyến của nó, tạo ra trạng thái khó hiểu khi giao diện hoạt động mà các tên nội bộ vẫn được phân giải qua máy chủ sai.

Thứ hai: có gì đã yêu cầu nó trở lại không?

Đây là nơi phép so sánh đáng giá. NetworkManager xử lý hồ sơ plugin OpenVPN và kết nối WireGuard gốc theo cách khác nhau, và tài liệu tham chiếu cài đặt kết nối nói rõ rằng connection.autoconnect không kích hoạt hồ sơ VPN; cơ chế để dựng VPN cùng với một kết nối là connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Nếu việc kết nối lại bằng tay sửa được vấn đề mỗi lần, đó là dấu hiệu của việc thiếu kích hoạt chứ không phải đường hầm hỏng. Nhật ký thường sẽ cho thấy giao diện đi xuống và không có gì đưa nó trở lại.

Hãy chống lại mong muốn thêm ngay một hook ngủ. Một hook kích hoạt trước khi mạng hồi phục sẽ chạy đua với chính tiến trình mà nó muốn giúp, và biến một vấn đề có thể tái hiện thành vấn đề chập chờn.

Thứ ba: ứng dụng có giữ trạng thái cũ không?

Mở một phiên hoàn toàn mới đến cùng đích trước khi chạm vào VPN. Nếu phiên mới hoạt động mà phiên cũ không, đường hầm vẫn ổn và ứng dụng đang giữ một kết nối đã chết.

Đây là kiểm tra rẻ nhất trong ba và là cái hay bị bỏ qua nhất, vì cửa sổ lỗi nằm ngay trên màn hình. Đóng nó, mở lại, và ghi nhận liệu vấn đề có tồn tại. Nếu phiên mới hoạt động, hãy dừng hoàn toàn việc điều tra đường hầm. Nếu nó cũng thất bại, ứng dụng là triệu chứng chứ không phải nguyên nhân.

Một số ứng dụng tự phục hồi sau khi hết thời gian chờ, vì vậy triệu chứng có thể trông như tự khỏi sau vài phút. Hành vi đó chỉ về ứng dụng chứ không phải đường hầm, và đáng ghi lại riêng. Một đồng nghiệp nói rằng nó tự khỏi là đang mô tả kiểu này, không phải may mắn.

Làm cho phép so sánh có thể tái hiện

Giữ các biến nhỏ: một mạng truy cập, một thời lượng ngủ và cùng một yêu cầu đầu tiên mỗi lần. Sau đó ghi lại hai kết quả: liệu kết nối lại bằng tay có sửa được nó, và liệu một giấc ngủ nữa có đưa lỗi trở lại.

Chính quan sát cuối cùng là thứ phân tách ba ứng viên một cách đáng tin cậy nhất. Một phiên mới hoạt động sau một phiên cũ thất bại không phải là vấn đề đường hầm, và không lần cài đặt lại ứng dụng khách nào sẽ thay đổi điều đó.

Keepalive liên tục của WireGuard chỉ xuất hiện trong bức tranh này với vai trò keepalive ánh xạ NAT. Nó gửi gói để giữ một ánh xạ mở; nó không ngăn máy đi ngủ và không thể tiếp tục gửi khi tiến trình bị treo.

Ghi vào phiếu những gì bạn tìm thấy: thứ nào trong ba bị hỏng, cái gì đã sửa nó và bạn đã tái hiện thế nào. Người tiếp theo mở nắp vào thứ Hai sẽ cảm ơn bạn, và câu trả lời sẽ không phải được khám phá lại từ đầu.