VPN rớt giữa trang: các yêu cầu nền có còn đi ra không?

Tab vẫn hiển thị bảng điều khiển từ trước khi đường hầm chết. Các con số trạng thái đóng băng, một vòng xoay nhỏ vẫn quay, và thanh địa chỉ vẫn mang ứng dụng bạn mở cách đây một giờ. Bạn không chạm vào gì sau khi mất kết nối, vậy mà trang có thể vẫn đang cố liên lạc với máy chủ của nó theo lịch riêng. Đó là phần mọi người bỏ sót: một trang chỉ hiển thị và một trang vẫn gửi yêu cầu trông giống hệt nhau từ bên ngoài, và chỉ một trong hai xuất hiện trong nhật ký mạng.

Công việc một trang tự bắt đầu khi không có bạn

Bốn cơ chế giữ một tài liệu đã tải luôn bận. Một bộ hẹn giờ lặp lại có thể chạy lại cuộc gọi trạng thái vài giây một lần. Một fetch có thể kích hoạt khi tab hiển thị trở lại sau khi bạn quay về. Một kênh trực tiếp dựng trên WebSocket hoặc sự kiện do máy chủ gửi có thể thử kết nối lại theo lịch lùi riêng. Một service worker do trang đăng ký có thể thức dậy cho một lần đồng bộ đang xếp hàng ngay cả khi không có tab nào trước mặt bạn.

Không cái nào cần nhấp, và không cái nào tải lại tài liệu. Thanh địa chỉ, vị trí cuộn và các giá trị hiển thị đều ở nguyên chỗ cũ. Thứ thay đổi chỉ là phía mạng: mỗi lần thử mới là một quyết định mới đưa ra ngay tại thời điểm nó bắt đầu.

Sự khác biệt đó quan trọng vì trang hiển thị được lưu cục bộ. Các pixel đã vẽ không nói gì về việc yêu cầu tiếp theo có thành công hay không. Một biểu đồ đóng băng kèm vòng xoay là dáng vẻ bình thường của một trang mà các yêu cầu đang thất bại. Đọc màn hình cho bạn biết máy chủ đã nói gì vài phút trước, không phải trình duyệt đang làm gì lúc này.

Vì sao lần tải trang trước đó không giữ một tuyến

Không có gì trong lần tải trang ràng buộc tài liệu với đường hầm. Việc định tuyến được giải quyết theo từng gói, tại thời điểm gửi, từ bảng tồn tại khi gói rời đi. Khi giao diện đường hầm biến mất, tra cứu đó không còn khớp với tuyến đường hầm nữa. Nó hoặc rơi xuống bộ điều hợp vật lý hoặc không tìm thấy gì cả, tùy vào những gì ứng dụng khách để lại.

Các lệnh gọi lại lặp lại là những tác vụ đã lên lịch thông thường. Phần hẹn giờ của chuẩn HTML mô tả cách chúng được xếp hàng và coi khoảng thời gian là độ trễ tối thiểu chứ không phải lời hứa về nhịp chính xác, nên một tab nền có thể thăm dò ít hơn nhiều so với mã của nó yêu cầu. Ít lần thử không giống như không lần thử nào, và việc đưa một tab trở lại phía trước là thời điểm phổ biến để chúng bùng phát.

Chính sách thất bại hạ cánh ở đâu

Việc chặn của ứng dụng khách được đánh giá khi một kết nối được thử, không phải khi trang được tải về. Nếu truy cập thông thường vẫn được phép, lần thử lại có thể đi ra qua liên kết vật lý một cách công khai. Nếu chính sách giữ lưu lượng đó cho đến khi đường hầm trở lại, lần thử thất bại ngay lúc kết nối và trang hiển thị một lỗi mà nó có thể thử lại vài giây sau.

Hai chi tiết quyết định bạn nhận được cái nào. Đầu tiên là phạm vi thực thi mà ứng dụng khách hỗ trợ: chặn toàn bộ thiết bị, chặn giới hạn ở bộ điều hợp đường hầm, hoặc một bộ quy tắc có ngoại lệ. Thứ hai là liệu đích đến có nằm trong ngoại lệ bạn đã thêm trước đó cho máy in cục bộ, cổng bắt giữ hay dịch vụ phát trực tuyến hay không.

Mã hóa ở tầng ứng dụng không thay đổi bất cứ điều gì trong số này. HTTPS bảo vệ các byte giữa trình duyệt và máy chủ; nó không nói gì về việc giao diện nào mang chúng. Một trang có thể được mã hóa hoàn hảo mà vẫn đi ra sai đường, và đó chính là điều mà một khối chặn hẹp cho phép.

Một kiểm tra có kiểm soát với trang dùng một lần

Dùng một máy chủ bạn kiểm soát và một trang không làm gì ngoài việc gọi nó, để không có dữ liệu thật nào bị đem ra thử. Từ terminal, lấy mẫu đường đi trước và sau khi mất kết nối:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

Chạy nó khi đường hầm bật, sau đó hạ đường hầm xuống và chạy lại. Một câu trả lời từ địa chỉ công cộng khi đường hầm đã hạ cho bạn biết đường trực tiếp đang mở. Hết thời gian hoặc kết nối bị từ chối cho bạn biết chính sách đang giữ. Lặp lại một lần nữa sau khi ứng dụng khách kết nối lại, để thấy đường hầm quay lại thay vì cho rằng nó đã quay lại.

Trong trình duyệt, bảng Mạng tách hai câu hỏi. Lọc sang Fetch/XHR, rồi đọc cột người khởi tạo: một mục do bộ hẹn giờ hoặc script bắt đầu, không có điều hướng nào được ghi trước đó, là một lần thử nền chứ không phải tải lại. So sánh thời điểm bắt đầu của nó với lúc đường hầm rớt. Nếu mục vẫn đang chờ khi đường hầm đã mất, yêu cầu đang chờ một đường đi không còn tồn tại.

Bằng chứng phía máy chủ mạnh hơn bất cứ thứ gì trình duyệt hiển thị. Nhật ký yêu cầu có dấu thời gian và địa chỉ nguồn chứng minh gói đã đến. Các mục trong trình duyệt có thể mang cookie, token và URL đầy đủ, nên chỉ giữ những trường câu hỏi của bạn cần và che phần còn lại trước khi dán chúng ở bất cứ đâu.

Làm gì với câu trả lời

Nếu các lần thử nền tiếp tục thành công khi đường hầm đã hạ, khối chặn hẹp hơn bạn tưởng, và khoảng trống đó đáng để bịt lại trước khi giao cho ứng dụng khách những việc nhạy cảm. Nếu chúng thất bại, chính sách đang làm việc của nó và trang đóng băng chỉ là hình thức. Dù thế nào, đóng một tab không phải là kiểm soát toàn thiết bị: các tab khác, trình duyệt khác và ứng dụng khác đều tự lên lịch công việc của mình.

Những bước tiếp theo đáng làm: liệt kê những ngoại lệ bạn đã thêm và lý do, xác nhận ứng dụng khách chỉ chặn lưu lượng trong phạm vi đường hầm hay toàn bộ lưu lượng, và theo dõi một yêu cầu nền từ đầu đến cuối với nhật ký máy chủ mở. Ba câu trả lời đó bao quát phần lớn nội dung thật sự của một báo cáo kiểu «VPN rớt và có gì đó vẫn kết nối».