VPN UDP macet saat menganggur: firewall lupa alur Anda

VPN terhubung, bekerja beberapa saat, lalu berhenti meneruskan lalu lintas sementara klien masih menampilkan sesi. Menyambung ulang memperbaikinya, sehingga terlihat seperti bug klien. Biasanya ini firewall atau perangkat NAT yang membuang pemetaan UDP yang menganggur dan tidak tahu bahwa terowongan masih ada.

Gejalanya cukup konsisten untuk didiagnosis: muncul setelah tidak ada aktivitas, bukan di bawah beban.

Seperti apa kemacetan karena menganggur

Ukur, jangan hanya mendeskripsikan. Catat berapa lama terowongan menganggur sebelum lalu lintas berhenti, apakah paket keluar baru menghidupkannya lagi, dan apakah antarmuka klien masih memegang alamatnya. Jika permintaan baru dari klien berhasil tetapi balasan ke alur yang ada tidak, pemetaan itulah tersangkanya. Jika tidak ada yang berhasil sampai Anda menyambung ulang, status sesi klien juga hilang.

Keduanya terkait dengan keadaan menganggur, dan keduanya butuh perbaikan berbeda.

Catat waktunya sebelum mengubah apa pun. Laporan bahwa berhenti setelah sekitar sepuluh menit menganggur bisa diuji, sedangkan laporan bahwa putusnya acak tidak bisa. Perbedaan itulah yang menentukan apakah Anda mengejar timer atau perubahan perutean.

Temukan perangkat yang lupa

Beberapa perangkat dapat menyimpan status untuk alur yang sama: router lokal, penerjemah di hulu, batas cloud, dan firewall host. Masing-masing punya timer sendiri, dan yang terpendek menang. Pemadaman lima menit biasanya berarti satu perangkat dikonfigurasi jauh di bawah yang lain.

Jangan menganggap nilai bawaan yang terdokumentasi adalah batas waktu di jalur Anda. Itu bawaan satu perangkat.

• Router rumah: sering hitungan menit, kadang jauh lebih singkat.
• NAT cloud atau penyeimbang beban: cari batas waktu menganggur yang terdokumentasi khusus untuk UDP.
• Firewall host: timer pelacakan netfilter berlaku per alur.

Periksa timer di jalur sebenarnya

Di Linux, timer pelacakan netfilter terlihat dan bisa disesuaikan: sysctl net.netfilter.nf_conntrack_udp_timeout dan net.netfilter.nf_conntrack_udp_timeout_stream. Yang kedua berlaku setelah lalu lintas terlihat di kedua arah, itulah sebabnya terowongan yang sudah terbentuk bisa bertahan lebih lama daripada probe biasa.

RFC 4787 menetapkan perilaku NAT UDP dan minimum yang disarankan. Itu rujukan yang dikutip ketika nilai bawaan vendor tampak tidak biasa pendeknya.

Keepalive dan sambung ulang adalah alat yang berbeda

Keepalive menjaga pemetaan tetap hidup; sambung ulang membangun sesi mati dari awal. Keduanya mengatasi kegagalan berbeda dan bukan pengaturan kecepatan yang bisa ditukar. Opsi PersistentKeepalive di WireGuard mengirim paket pada interval tetap untuk menjaga ikatan NAT tetap terbuka. Opsi keepalive di OpenVPN melakukan pekerjaan yang sama dengan caranya sendiri. Keduanya tidak membantu jika perangkat di tengah sudah lupa alurnya dan membuang kedua arah.

Probe yang sangat sering menambah pekerjaan tanpa memperbaiki batas yang salah.

Verifikasi dengan permintaan baru, bukan memuat ulang halaman

Setelah mengubah timer atau menambahkan keepalive, ulangi skenario menganggur persis seperti sebelumnya. Lalu buat permintaan yang benar-benar baru dari aplikasi yang tercakup. Tab peramban yang sudah dimuat bisa dirender dari cache dan tidak memberi tahu apa pun.

Jika kemacetan berlanjut, bergerak satu hop ke luar dan periksa tabel status perangkat itu.