VPN putus di tengah halaman: apakah permintaan latar belakang masih keluar?

Tab masih menampilkan dasbor dari sebelum tunnel mati. Angka status membeku, pemutar kecil terus berputar, dan bilah alamat masih membawa aplikasi yang Anda buka satu jam lalu. Anda tidak menyentuh apa pun setelah putus, namun halaman mungkin masih mencoba menjangkau servernya sesuai jadwalnya sendiri. Itulah bagian yang orang lewatkan: halaman yang sekadar terlihat dan halaman yang masih mengirim permintaan tampak sama dari luar, dan hanya satu di antaranya muncul di log jaringan.

Pekerjaan yang dimulai halaman tanpa Anda

Empat mekanisme membuat dokumen yang dimuat tetap sibuk. Timer berulang dapat menjalankan ulang panggilan status setiap beberapa detik. Fetch dapat terpicu saat tab kembali terlihat setelah Anda beralih kembali ke sana. Kanal langsung berbasis WebSocket atau event yang dikirim server dapat mencoba menyambung ulang sesuai jadwal backoff-nya sendiri. Service worker yang didaftarkan situs dapat terbangun untuk sinkronisasi dalam antrean bahkan saat tidak ada tab di depan Anda.

Tidak satu pun membutuhkan klik, dan tidak satu pun memuat ulang dokumen. Bilah alamat, posisi gulir, dan nilai yang dirender semuanya tetap di tempatnya. Yang berubah hanya sisi jaringan: setiap upaya baru adalah keputusan segar yang diambil pada saat ia mulai.

Perbedaan itu penting karena halaman yang terlihat disimpan secara lokal. Piksel yang sudah dilukis tidak mengatakan apa pun tentang apakah permintaan berikutnya berhasil. Grafik beku dengan pemutar adalah tampilan biasa halaman yang permintaannya kini gagal. Membaca layar memberi tahu Anda apa yang server katakan beberapa menit lalu, bukan apa yang browser lakukan sekarang.

Mengapa pemuatan halaman sebelumnya tidak memegang rute

Tidak ada apa pun dalam pemuatan halaman yang mengikat dokumen ke tunnel. Perutean diselesaikan per paket, pada saat pengiriman, dari tabel yang ada ketika paket pergi. Saat antarmuka tunnel hilang, pencarian itu tidak lagi cocok dengan rute tunnel. Ia entah jatuh ke adaptor fisik atau tidak menemukan apa pun, tergantung apa yang ditinggalkan klien.

Callback berulang adalah tugas terjadwal biasa. Bagian timer pada standar HTML menjelaskan bagaimana mereka diantrekan dan memperlakukan interval sebagai penundaan minimum alih-alih janji irama yang tepat, sehingga tab latar belakang dapat melakukan polling jauh lebih jarang daripada yang diminta kodenya. Upaya lebih sedikit tidak sama dengan tidak ada upaya, dan membawa tab kembali ke depan adalah momen umum bagi ledakan upaya itu.

Ke mana kebijakan kegagalan mendarat

Blokir klien dievaluasi ketika koneksi dicoba, bukan ketika halaman diambil. Jika akses biasa masih diizinkan, upaya ulang dapat keluar lewat tautan fisik secara terbuka. Jika kebijakan menahan lalu lintas itu sampai tunnel kembali, upaya gagal pada saat koneksi dan halaman menampilkan galat yang mungkin dicoba ulang beberapa detik kemudian.

Dua detail menentukan mana yang Anda dapatkan. Yang pertama adalah cakupan penegakan yang didukung klien: blokir seluruh perangkat, blokir terbatas pada adaptor tunnel, atau set aturan dengan pengecualian. Yang kedua adalah apakah tujuan berada di dalam pengecualian yang Anda tambahkan sebelumnya untuk printer lokal, portal tawanan, atau layanan streaming.

Enkripsi tingkat aplikasi tidak mengubah semua ini. HTTPS melindungi byte antara browser dan server; ia tidak mengatakan apa pun tentang antarmuka mana yang membawanya. Halaman dapat terenkripsi sempurna dan tetap keluar lewat jalur yang salah, dan itulah tepatnya yang diizinkan blokir sempit.

Pemeriksaan terkendali dengan halaman sekali pakai

Gunakan host yang Anda kendalikan dan halaman yang tidak melakukan apa pun selain memanggilnya, agar tidak ada data nyata yang dipertaruhkan. Dari terminal, ambil sampel jalur sebelum dan sesudah putus:

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

Jalankan dengan tunnel menyala, lalu matikan tunnel dan jalankan lagi. Balasan dari alamat publik saat tunnel mati memberi tahu Anda bahwa jalur langsung terbuka. Waktu habis atau koneksi ditolak memberi tahu Anda bahwa kebijakan menahan. Ulangi sekali lagi setelah klien menyambung ulang, agar Anda melihat jalur tunnel kembali alih-alih menganggapnya.

Di browser, panel Jaringan memisahkan kedua pertanyaan. Saring ke Fetch/XHR, lalu baca kolom inisiator: entri yang dimulai timer atau skrip, tanpa navigasi yang tercatat sebelumnya, adalah upaya latar belakang dan bukan muat ulang. Bandingkan waktu mulainya dengan saat tunnel putus. Jika entri masih tertunda saat tunnel hilang, permintaan menunggu jalur yang tidak lagi ada.

Bukti sisi server lebih kuat daripada apa pun yang ditunjukkan browser. Log permintaan dengan stempel waktu dan alamat sumber membuktikan paket tiba. Entri browser dapat membawa cookie, token, dan URL lengkap, jadi simpan hanya bidang yang dibutuhkan pertanyaan Anda dan sunting sisanya sebelum menempelkannya di mana pun.

Apa yang harus dilakukan dengan jawabannya

Jika upaya latar belakang terus berhasil saat tunnel mati, blokir lebih sempit dari yang Anda duga, dan celah itu layak ditutup sebelum Anda mempercayai klien untuk pekerjaan sensitif. Jika gagal, kebijakan menjalankan tugasnya dan halaman beku hanyalah kosmetik. Bagaimanapun, menutup satu tab bukan kendali seluruh perangkat: tab lain, browser lain, dan aplikasi lain masing-masing menjadwalkan pekerjaannya sendiri.

Langkah berikutnya yang layak diambil: daftar pengecualian apa yang Anda tambahkan dan mengapa, pastikan apakah klien memblokir hanya lalu lintas dalam cakupan tunnel atau semua lalu lintas, dan amati satu permintaan latar belakang dari awal sampai akhir dengan log server terbuka. Ketiga jawaban itu mencakup sebagian besar isi laporan «VPN putus dan sesuatu masih terhubung».