VPN terputus saat unggahan besar: baca antrean lebih dulu

Tunnel stabil sepanjang hari, lalu terputus setiap kali unggahan besar dimulai. Permintaan interaktif tersendat lebih dulu, klien melaporkan waktu tunggu habis, dan koneksi kembali saat transfer selesai. Pola itu menunjuk pada antrean dan pemrosesan, bukan pada server jauh yang mati, karena server tidak pernah diberi kesempatan menjawab tepat waktu. Tugasnya adalah mereproduksi ini di bawah beban terkendali dan membaca penghitung yang tepat.

Ubah satu variabel per percobaan, dan jaga titik akhir tetap.

Bangun perbandingan beban yang dapat diulang

Catat garis dasar saat tautan menganggur: waktu pulang-pergi, beberapa permintaan aplikasi, dan log peristiwa tunnel itu sendiri. Lalu mulai unggahan berukuran diketahui dan ulangi persis pengukuran tersebut selama berjalan. Jaga titik akhir, klien, dan tujuan uji tidak berubah, karena mengubah dua di antaranya sekaligus tidak memberi tahu apa pun.

Perhatikan peristiwa mana yang muncul lebih dulu. Waktu pulang-pergi yang naik sebelum ada galat menandakan antrean; waktu tunggu habis yang keras dengan latensi stabil menandakan hal lain, seperti pergantian kunci atau tindakan pada akun. Kedua pola mengarah ke langkah berikut yang berbeda. Tuliskan pengamatan sebelum mengubah apa pun.

Simpan keluaran dengan cap waktu agar percobaan berbeban dan menganggur dapat dibandingkan baris demi baris.

Baca antreannya, bukan kecepatannya

Tautan konsumen menyangga paket di peralatan penyedia, dan antrean keluar yang penuh menunda segalanya, termasuk paket kendali kecil yang menjaga tunnel tetap hidup. Uji kecepatan yang melaporkan angka tinggi sedikit berbicara tentang penundaan itu, karena itu uji saat menganggur lolos sementara tautan jenuh gagal.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Bandingkan angka latensi berbeban dengan angka saat menganggur. Lonjakan dari puluhan milidetik ke ratusan, tanpa kehilangan paket, adalah antrean; kehilangan dengan latensi stabil menunjuk pada gangguan lain.

Periksa perangkat dan jalur kendali

Enkripsi dan penerusan memakan waktu prosesor, dan router kecil atau laptop yang dibatasi panas dapat menjatuhkan paket saat sibuk. Pantau beban keseluruhan, bukan persentase satu proses, karena penerusan di kernel dan penanganan interupsi tidak muncul di tempat orang biasanya melihat.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Waktu tunggu habis di klien juga bisa bertepatan dengan pergantian kunci terjadwal atau dengan peristiwa kebijakan sesi. Baca log klien itu sendiri untuk urutan peristiwa, bukan hanya pesan galat aplikasi.

Ubah satu hal dan ulangi

Jika platform mendukungnya, batasi laju unggah atau klasifikasikan lalu lintas massal di bawah lalu lintas interaktif agar antrean tidak pernah penuh. Lalu ulangi beban kerja yang sama dan bandingkan tiga angka yang sama seperti sebelumnya. Perubahan yang memperbaiki uji kecepatan tetapi membiarkan waktu tunggu habis tidak memperbaiki apa pun.

Menaikkan waktu tunggu di semua tempat dan melemahkan enkripsi adalah dua perubahan yang membuat gejala hilang tanpa mengidentifikasi batas mana yang gagal. Keduanya bukan perbaikan. Keduanya memindahkan kegagalan ke kemudian, tempat yang lebih sulit untuk diatribusikan.

Akhiri dengan menguji permintaan baru dan perilaku penyambungan ulang yang benar-benar diandalkan pengguna. Stabilitas di bawah beban yang memicu keluhan adalah satu-satunya hasil yang layak dicatat.