VPN UDP tersekat semasa melahu: firewall terlupa aliran anda

VPN bersambung, berfungsi seketika dan kemudian berhenti menyalurkan trafik sedangkan klien masih memaparkan sesi. Menyambung semula membaikinya, jadi ia kelihatan seperti pepijat klien. Biasanya ia ialah firewall atau peranti NAT yang menggugurkan pemetaan UDP yang melahu dan tidak tahu terowong masih wujud.

Gejalanya cukup konsisten untuk didiagnosis: ia muncul selepas tiada aktiviti, bukan di bawah beban.

Rupa sekatan akibat melahu

Ukur, jangan hanya huraikan. Catat berapa lama terowong melahu sebelum trafik berhenti, sama ada paket keluar baharu menghidupkannya semula, dan sama ada antara muka klien masih memegang alamatnya. Jika permintaan baharu daripada klien berjaya tetapi balasan kepada aliran sedia ada tidak, pemetaan itulah yang disyaki. Jika tiada apa berjaya sehingga anda menyambung semula, keadaan sesi klien juga hilang.

Kedua-duanya berkaitan dengan keadaan melahu, dan kedua-duanya perlukan pembetulan berbeza.

Catat masanya sebelum mengubah apa-apa. Laporan bahawa ia berhenti selepas kira-kira sepuluh minit melahu boleh diuji, manakala laporan bahawa ia terputus secara rawak tidak boleh. Perbezaan itulah yang menentukan sama ada anda mengejar pemasa atau perubahan penghalaan.

Cari peranti yang terlupa

Beberapa peranti boleh menyimpan keadaan untuk aliran yang sama: penghala tempatan, penterjemah di hulu, sempadan awan dan firewall hos. Setiap satu mempunyai pemasa sendiri, dan yang terpendek menang. Gangguan lima minit biasanya bermaksud satu peranti dikonfigurasikan jauh lebih rendah daripada yang lain.

Jangan anggap nilai lalai yang didokumenkan ialah had masa pada laluan anda. Ia nilai lalai satu peranti.

• Penghala rumah: selalunya minit, kadangkala jauh lebih singkat.
• NAT awan atau pengimbang beban: cari had masa melahu yang didokumenkan khusus untuk UDP.
• Firewall hos: pemasa penjejakan netfilter terpakai bagi setiap aliran.

Periksa pemasa pada laluan sebenar

Pada Linux, pemasa penjejakan netfilter boleh dilihat dan dilaraskan: sysctl net.netfilter.nf_conntrack_udp_timeout dan net.netfilter.nf_conntrack_udp_timeout_stream. Yang kedua terpakai apabila trafik telah dilihat dalam kedua-dua arah, sebab itulah terowong yang sudah terbentuk boleh bertahan lebih lama daripada kuar biasa.

RFC 4787 menetapkan tingkah laku NAT UDP dan minimum yang disyorkan. Itulah rujukan untuk dipetik apabila nilai lalai vendor kelihatan luar biasa pendek.

Keepalive dan sambung semula ialah alat yang berbeza

Keepalive mengekalkan pemetaan hidup; sambung semula membina semula sesi yang mati. Kedua-duanya menyelesaikan kegagalan berbeza dan bukan tetapan kelajuan yang boleh ditukar. Pilihan PersistentKeepalive dalam WireGuard menghantar paket pada selang tetap untuk memastikan ikatan NAT terbuka. Pilihan keepalive dalam OpenVPN melakukan kerja yang sama dengan caranya sendiri. Kedua-duanya tidak membantu jika peranti di tengah sudah terlupa aliran itu dan menggugurkan kedua-dua arah.

Kuar yang terlalu kerap menambah kerja tanpa membaiki sempadan yang salah.

Sahkan dengan permintaan baharu, bukan muat semula halaman

Selepas menukar pemasa atau menambah keepalive, ulangi senario melahu betul-betul seperti sebelum ini. Kemudian buat permintaan yang benar-benar baharu daripada aplikasi yang dilindungi. Tab pelayar yang sudah dimuatkan boleh dipaparkan daripada cache dan tidak memberitahu anda apa-apa.

Jika sekatan berterusan, bergerak satu hop ke luar dan periksa jadual keadaan peranti itu.