VPN terputus di tengah halaman: adakah permintaan latar belakang masih keluar?

Tab masih memaparkan papan pemuka dari sebelum terowong mati. Nombor status membeku, pemutar kecil terus berputar, dan bar alamat masih membawa aplikasi yang anda buka sejam lalu. Anda tidak menyentuh apa-apa selepas terputus, namun halaman itu mungkin masih cuba mencapai pelayan mengikut jadualnya sendiri. Itulah bahagian yang orang terlepas pandang: halaman yang hanya kelihatan dan halaman yang masih menghantar permintaan kelihatan sama dari luar, dan hanya satu daripadanya muncul dalam log rangkaian.

Kerja yang dimulakan halaman tanpa anda

Empat mekanisme memastikan dokumen yang dimuatkan sibuk. Pemasa berulang boleh menjalankan semula panggilan status setiap beberapa saat. Fetch boleh tercetus apabila tab menjadi kelihatan semula selepas anda beralih kembali kepadanya. Saluran langsung yang dibina atas WebSocket atau peristiwa yang dihantar pelayan boleh cuba menyambung semula mengikut jadual backoffnya sendiri. Pekerja perkhidmatan yang didaftarkan oleh laman boleh bangun untuk penyegerakan dalam baris gilir walaupun tiada tab di hadapan anda.

Tiada satu pun memerlukan klik, dan tiada satu pun memuat semula dokumen. Bar alamat, kedudukan tatal dan nilai yang dipaparkan semuanya kekal di tempatnya. Yang berubah hanyalah bahagian rangkaian: setiap cubaan baharu ialah keputusan segar yang dibuat pada saat ia bermula.

Perbezaan itu penting kerana halaman yang kelihatan disimpan secara setempat. Piksel yang sudah dilukis tidak mengatakan apa-apa tentang sama ada permintaan seterusnya berjaya. Carta beku dengan pemutar ialah rupa biasa halaman yang permintaannya kini gagal. Membaca skrin memberitahu anda apa yang pelayan katakan beberapa minit lalu, bukan apa yang pelayar lakukan sekarang.

Mengapa pemuatan halaman terdahulu tidak memegang laluan

Tiada apa-apa dalam pemuatan halaman mengikat dokumen kepada terowong. Penghalaan diselesaikan setiap paket, pada masa penghantaran, daripada jadual yang wujud apabila paket keluar. Apabila antara muka terowong hilang, carian itu tidak lagi sepadan dengan laluan terowong. Ia sama ada jatuh ke penyesuai fizikal atau tidak menemui apa-apa, bergantung pada apa yang klien tinggalkan.

Panggilan balik berulang ialah tugas berjadual biasa. Bahagian pemasa standard HTML menerangkan bagaimana ia dimasukkan ke dalam baris gilir dan menganggap selang itu sebagai kelewatan minimum bukannya janji irama tepat, jadi tab latar belakang boleh mengundi jauh lebih jarang daripada yang diminta kodnya. Cubaan yang lebih sedikit bukan sama dengan tiada cubaan, dan membawa tab kembali ke hadapan ialah saat biasa bagi lonjakan cubaan itu.

Di mana dasar kegagalan mendarat

Sekatan klien dinilai apabila sambungan dicuba, bukan apabila halaman diambil. Jika akses biasa masih dibenarkan, cubaan semula boleh keluar melalui pautan fizikal secara terbuka. Jika dasar itu menahan trafik tersebut sehingga terowong kembali, cubaan gagal pada saat sambungan dan halaman memaparkan ralat yang mungkin dicuba semula beberapa saat kemudian.

Dua butiran menentukan yang mana satu anda dapat. Yang pertama ialah skop penguatkuasaan yang disokong klien: sekatan seluruh peranti, sekatan terhad kepada penyesuai terowong, atau set peraturan dengan pengecualian. Yang kedua ialah sama ada destinasi itu termasuk dalam pengecualian yang anda tambah sebelum ini untuk pencetak setempat, portal tawanan atau perkhidmatan penstriman.

Penyulitan peringkat aplikasi tidak mengubah apa-apa daripada ini. HTTPS melindungi bait antara pelayar dan pelayan; ia tidak mengatakan apa-apa tentang antara muka mana yang membawanya. Halaman boleh disulitkan dengan sempurna dan masih keluar melalui laluan yang salah, dan itulah tepat yang dibenarkan oleh sekatan sempit.

Semakan terkawal dengan halaman sekali guna

Gunakan hos yang anda kawal dan halaman yang tidak melakukan apa-apa selain memanggilnya, supaya tiada data sebenar dipertaruhkan. Dari terminal, ambil sampel laluan sebelum dan selepas terputus:

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

Jalankan dengan terowong menyala, kemudian tutup terowong dan jalankan semula. Balasan dari alamat awam semasa terowong tertutup memberitahu anda laluan terus terbuka. Tamat masa atau sambungan ditolak memberitahu anda dasar sedang menahan. Ulangi sekali lagi selepas klien menyambung semula, supaya anda melihat laluan terowong kembali bukannya menganggapnya.

Dalam pelayar, panel Rangkaian memisahkan kedua-dua soalan. Tapis ke Fetch/XHR, kemudian baca lajur pemula: entri yang dimulakan oleh pemasa atau skrip, tanpa navigasi direkodkan sebelum itu, ialah cubaan latar belakang dan bukan muat semula. Bandingkan masa mula dengan saat terowong terputus. Jika entri masih belum selesai semasa terowong tiada, permintaan itu sedang menunggu laluan yang tidak lagi wujud.

Bukti di pihak pelayan lebih kuat daripada apa-apa yang dipaparkan pelayar. Log permintaan dengan cap masa dan alamat sumber membuktikan paket itu tiba. Entri pelayar boleh membawa kuki, token dan URL penuh, jadi simpan hanya medan yang diperlukan oleh soalan anda dan edit selebihnya sebelum menampalnya di mana-mana.

Apa yang perlu dilakukan dengan jawapannya

Jika cubaan latar belakang terus berjaya semasa terowong tertutup, sekatan itu lebih sempit daripada yang anda sangkakan, dan jurang itu wajar ditutup sebelum anda mempercayai klien untuk kerja sensitif. Jika ia gagal, dasar itu menjalankan tugasnya dan halaman beku itu hanya kosmetik. Walau apa pun, menutup satu tab bukan kawalan seluruh peranti: tab lain, pelayar lain dan aplikasi lain masing-masing menjadualkan kerjanya sendiri.

Langkah seterusnya yang wajar diambil: senaraikan pengecualian yang anda tambah dan mengapa, sahkan sama ada klien menyekat hanya trafik dalam skop terowong atau semua trafik, dan perhatikan satu permintaan latar belakang dari awal hingga akhir dengan log pelayan terbuka. Ketiga-tiga jawapan itu meliputi sebahagian besar daripada apa yang sebenarnya terkandung dalam laporan «VPN terputus dan sesuatu masih bersambung».