VPN đã kết nối lại nhưng phiên của ứng dụng vẫn hỏng

Đường hầm quay lại, ứng dụng khách báo đã kết nối, và trình duyệt vẫn quay trên một trang mà nó đang tải trước khi mất kết nối. Việc kết nối lại VPN khôi phục một đường đi, và nó không khôi phục trạng thái kết nối mà các ứng dụng và phía đầu xa đã tích lũy trên đường cũ. Đây là hai thứ khác nhau cần sửa, và nhầm lẫn giữa chúng đưa bạn trở lại phần cài đặt VPN mà không có lý do.

Một phép thử phân biệt chúng rõ ràng, và nó mất mười giây. Gửi một yêu cầu mới đến cùng đích trong khi yêu cầu cũ vẫn treo.

Điều gì sống sót qua kết nối lại và điều gì không

Đường hầm là một tập hợp các tuyến, khóa và địa chỉ, và kết nối lại có thể khôi phục cả ba trong khi mọi luồng đã thiết lập vẫn chết. Hệ điều hành giữ một socket mở vì ứng dụng đã yêu cầu, và thời gian chờ của socket đó có thể còn vài phút hoặc vài giờ. Bên dưới, đối tác đã quên luồng, một mục dịch đã hết hạn, hoặc đường đi giờ qua một điểm cuối chưa từng thấy bắt tay. Không có gì trong trình tự kết nối lại đi qua các socket của ứng dụng và sửa chúng.

Một số ứng dụng khách thêm một móc để bỏ các kết nối cũ khi kết nối lại, và phần lớn thì không. Hành vi ở đây khác nhau theo ứng dụng khách, nền tảng và phiên bản.

Phía đầu xa cũng đã quên bạn

Đầu xa giữ trạng thái riêng: một phiên TLS, một khối điều khiển TCP và có thể một mục ánh xạ buộc địa chỉ và cổng của bạn với luồng. Một thiết bị dịch trên đường đi có thể để mục ánh xạ đó hết hạn trong khoảng gián đoạn dù đường hầm được lập lại nhanh. Khi ánh xạ mất, các gói đến cho một luồng mà máy chủ không còn nhận ra, và phản hồi có thể là một reset mà ứng dụng khách không bao giờ hiển thị. Các ứng dụng báo điều này như một sự đình trệ chứ không phải lỗi, vì chúng vẫn đang chờ một socket sẽ không bao giờ trả lời.

Thời gian chờ không hoạt động ở phía máy chủ làm điều tương tự theo lịch riêng của chúng, đó là lý do một phiên có thể chết mà không có sự kiện mạng nào. Một kết nối không hoạt động lâu hơn mức máy chủ mong đợi đã biến mất trước khi bạn nhận ra đường hầm đã dịch chuyển.

Yêu cầu mới chính là phép thử phân biệt chúng

Gửi một yêu cầu mới đến cùng máy chủ trong khi yêu cầu cũ vẫn treo, và quan sát cả hai. Nếu yêu cầu mới thành công thì đường hầm, tuyến và phân giải tên đều hoạt động, và lỗi chỉ nằm ở luồng cũ. Nếu yêu cầu mới cũng hỏng thì bạn có vấn đề về đường đi và trạng thái phiên của ứng dụng là manh mối sai.

Giữ nguyên mọi chặn lưu lượng trực tiếp trong lúc thử. Một yêu cầu thành công qua một đường dự phòng tình cờ không chứng minh gì về đường hầm.

Xác nhận bằng kết nối mới, không phải kết nối cũ

Các lệnh dưới đây cho thấy các socket còn mở, khởi động một yêu cầu mới và kiểm tra xem bảng phiên còn giữ mục nào cho luồng không. Chạy lệnh đầu tiên trước và sau khi kết nối lại để thấy khác biệt. Thay máy chủ và cổng bằng dịch vụ của bạn.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

Một socket đã thiết lập mà không có lưu lượng chuyển động là dấu hiệu cần tìm, và một yêu cầu mới trả về mã trạng thái cho thấy đường đi còn sống. Bảng kết nối trả lời liệu còn gì ánh xạ luồng, và đó là phần ứng dụng khách không thể thấy. Truy vấn trình phân giải bao phủ nửa còn lại của việc tải trang, vì lỗi tên và kết nối bị kẹt trông giống nhau trên trình duyệt. Cùng nhau, bốn đầu ra đó tách một phiên cũ khỏi một đường hầm hỏng.

Ghi lại thời điểm gián đoạn, thời điểm kết nối lại và khác biệt giữa yêu cầu cũ và mới. Bản ghi đó biến một phàn nàn mơ hồ thành báo cáo mà ai đó có thể xử lý.