Backtrack pemutaran ulang OpenVPN di log: apa yang tidak dibuktikan baris itu

Baris itu berbunyi PID_ERR replay-window backtrack occurred, dan semua hasil pencarian menjelaskannya sebagai paket yang dibuang dan terowongan yang rusak. Di jalur UDP Community OpenVPN 2.6, pesan itu ditulis saat fungsi penerimaan masih memutuskan apa yang harus dilakukan dengan paket. Pesan itu mencatat maksimum backtrack yang baru, lalu fungsi yang sama membandingkan jarak dengan jendela dan keadaan tercatat sebelum menerima atau menolak. Membaca label log sebagai putusan adalah kesalahan yang hendak dicegah daftar periksa ini.

Perhentian satu: kenali apa baris itu

Ini adalah diagnostik tentang jarak urutan, bukan keputusan tentang koneksi. Pesan ini muncul dalam implementasi ID paket pada titik ketika maksimum backtrack yang baru diamati dicatat. Titik itu berada sebelum cabang terima-atau-tolak, karena itu paket yang memicunya masih dapat dikirim.

Pastikan host mana yang menulisnya dan pada tingkat kerincian apa. Server dan klien sama-sama dapat memancarkan pesan ID paket, dan pesan dari satu pihak tidak mengatakan apa pun tentang keadaan penerimaan pihak lain.

Perhentian dua: temukan hasil untuk paket itu

Baca baris-baris setelah diagnostik, bukan hanya diagnostiknya. Fungsi yang sama berlanjut ke pemeriksaan jendela dan duplikatnya, jadi hasil untuk paket tertentu itu diputuskan beberapa instruksi kemudian dan bisa saja berupa penerimaan. Kutipan log yang berakhir pada baris menakutkan tidak memberi tahu apa pun tentang hasilnya. Cari jendela di sekitarnya, bukan barisnya sendiri:

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

Jika log tidak menunjukkan penolakan untuk peer itu pada waktu itu, berhentilah memperlakukan baris ini sebagai penyebab gangguan. Lanjutkan ke jalur aplikasi, karena di sanalah sebagian besar laporan terhubung tetapi tanpa lalu lintas sebenarnya berakhir.

Perhentian tiga: putuskan apakah pengurutan ulang itu nyata

Pengurutan ulang adalah sifat jalur, dan satu diagnostik hanyalah satu sampelnya. Cari pesan berulang untuk peer yang sama dalam jendela singkat, dan bandingkan dengan tangkapan di kedua ujung sebelum menyimpulkan bahwa jaringan mengurutkan ulang secara agresif.

Beberapa pesan selama penyambungan ulang bukan hal luar biasa. Aliran terus-menerus bersama batas waktu aplikasi yang nyata layak diselidiki, dan kombinasi itu adalah bukti, bukan label.

Perhentian empat: parameter jendela, dan apa yang bukan

replay-window mengambil ukuran urutan dan nilai waktu opsional, jadi memperlebarnya mengubah dua toleransi berbeda sekaligus. Menaikkan angkanya mengizinkan paket yang lebih jauh dari urutan; nilai waktu membatasi berapa lama paket masih boleh dipertimbangkan. Memperlebar adalah perubahan kebijakan dengan biaya keamanan, dan itu tidak memperkuat sandi atau menonaktifkan deteksi duplikat. Kedua toleransi bergerak bersama, entah Anda menghendakinya atau tidak.

Paket terautentikasi lama tetap bisa menjadi pengulangan yang tidak diinginkan, karena itu penerima mempertahankan pemeriksaan ini. Menerima lebih banyak pengurutan ulang berarti menerima lebih banyak risiko itu.

Membisukan peringatan dengan mute mengubah apa yang Anda lihat, bukan apa yang dilakukan daemon. Jika tujuannya log yang lebih tenang selama peristiwa yang diketahui, itu pilihan operasional yang sah; jika tujuannya memperbaiki terowongan, membisukan menyembunyikan bukti.

mute 20
replay-window 64 15

Mengalihkan transportasi luar ke TCP mengubah perilaku pengiriman dan pemulihan serta menambah biaya pemblokiran kepala antreannya sendiri. Itu keputusan desain, bukan respons pertama terhadap satu label log. Memasang ulang server lebih buruk, karena menghapus perbedaan antara statistik dan batas yang benar-benar gagal.

Perhentian lima: uji jalur yang penting bagi pengguna

Dengan terowongan terhubung, jalankan uji milik aplikasi itu sendiri dan baca rute yang dipilihnya, keadaan penerusan, dan jalur kembalinya. Terowongan yang hanya membawa paket ke satu arah tidak menghasilkan pesan backtrack sama sekali, dan itu jauh lebih umum daripada pengurutan ulang parah.

Catat apa yang Anda ukur di setiap perhentian. Catatan itulah yang mencegah laporan berikutnya memulai lagi dari baris menakutkan dan bekerja ke luar dari sana.

Implementasi ID paket menunjukkan urutan statistik dan keputusan, dan manualnya menjelaskan cakupan urutan dan waktu jendela. Membaca keduanya bersama-sama itulah yang mengubah baris log menakutkan menjadi besaran yang diketahui. Tidak satu pun dari keduanya mengatakan apa pun tentang jalur khusus Anda, karena itu pengukuran di atas tetap penting.