VPN tersambung ulang, tetapi sesi aplikasi tetap gagal

Terowongannya kembali, klien mengatakan tersambung, dan peramban masih berputar pada halaman yang sedang dimuatnya sebelum putus. Sambung ulang VPN memulihkan jalur, dan tidak memulihkan status koneksi yang dikumpulkan aplikasi dan sisi jauh pada jalur lama. Keduanya hal berbeda untuk diperbaiki, dan mencampurnya mengirim Anda kembali ke pengaturan VPN tanpa alasan.

Satu uji memisahkan keduanya dengan bersih, dan hanya butuh sepuluh detik. Kirim permintaan baru ke tujuan yang sama selagi yang lama masih menggantung.

Apa yang bertahan dari sambung ulang dan apa yang tidak

Terowongan adalah kumpulan rute, kunci, dan alamat, dan sambung ulang dapat memulihkan ketiganya sementara setiap aliran yang sudah terbentuk tetap mati. Sistem operasi menahan soket tetap terbuka karena aplikasi memintanya, dan batas waktu soket itu bisa beberapa menit atau jam lagi. Di bawahnya, rekan sudah lupa aliran itu, entri terjemahan sudah kedaluwarsa, atau jalur kini melewati titik akhir yang tidak pernah melihat jabat tangan. Tidak ada apa pun dalam urutan sambung ulang yang menelusuri soket aplikasi dan memperbaikinya.

Sebagian klien menambahkan kait yang membuang koneksi basi saat sambung ulang, dan sebagian besar tidak. Perilaku di sini berbeda menurut klien, platform, dan versi.

Sisi jauh juga melupakan Anda

Ujung jauh menyimpan statusnya sendiri: sesi TLS, blok kendali TCP, dan mungkin entri pemetaan yang mengikat alamat dan porta Anda ke aliran itu. Perangkat terjemahan di sepanjang jalur dapat membiarkan pemetaan itu kedaluwarsa selama jeda meski terowongan pulih dengan cepat. Begitu pemetaan hilang, paket datang untuk aliran yang tidak lagi dikenali server, dan balasannya bisa berupa reset yang tidak pernah ditampilkan klien. Aplikasi melaporkan ini sebagai kemacetan, bukan kesalahan, karena mereka masih menunggu soket yang tidak akan pernah menjawab.

Batas waktu diam di sisi server melakukan hal yang sama menurut jadwalnya sendiri, karena itu sesi bisa mati tanpa peristiwa jaringan apa pun. Koneksi yang diam lebih lama daripada yang diharapkan server sudah hilang sebelum Anda menyadari terowongannya bergeser.

Permintaan baru adalah uji yang memisahkan keduanya

Kirim permintaan baru ke host yang sama selagi yang lama masih menggantung, dan amati keduanya. Jika permintaan baru berhasil, terowongan, rute, dan resolusi nama semuanya bekerja, dan kesalahannya terbatas pada aliran basi. Jika permintaan baru juga gagal, Anda punya masalah jalur dan status sesi aplikasi adalah petunjuk palsu.

Biarkan blokir lalu lintas langsung tetap di tempatnya selama uji. Permintaan yang berhasil lewat jalur cadangan yang tidak disengaja tidak membuktikan apa pun tentang terowongan.

Pastikan dengan koneksi baru, bukan yang lama

Perintah di bawah menampilkan soket yang masih terbuka, memulai satu permintaan baru, dan memeriksa apakah tabel sesi masih menyimpan entri untuk aliran itu. Jalankan yang pertama sebelum dan sesudah sambung ulang agar selisihnya terlihat. Ganti host dan porta dengan layanan Anda sendiri.

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

Soket terbentuk tanpa lalu lintas bergerak adalah tanda yang dicari, dan permintaan baru yang mengembalikan kode status menunjukkan jalurnya hidup. Tabel koneksi menjawab apakah masih ada yang memetakan aliran itu, dan itulah bagian yang tidak dapat dilihat klien. Kueri resolver mencakup separuh lain pemuatan halaman, sebab kegagalan nama dan koneksi macet terlihat sama di peramban. Bersama-sama, keempat keluaran itu memisahkan sesi basi dari terowongan rusak.

Catat waktu gangguan, waktu sambung ulang, dan selisih antara permintaan lama dan baru. Catatan itu mengubah keluhan kabur menjadi laporan yang bisa ditindaklanjuti.