Putus OpenVPN tiap jam: negosiasi ulang atau sambung ulang sungguhan?

Enam puluh menit, atau tiga puluh, atau seratus dua puluh: putus yang jatuh pada interval bulat hampir tidak pernah jaringan. OpenVPN menyegarkan materi kunci yang melindungi kanal data sesuai pengatur waktu, dan pengatur waktu yang lebih pendek daripada yang Anda asumsikan tampak persis seperti tautan yang terus gagal. Pengguna melaporkan koneksi terputus sementara log melaporkan pertukaran kunci yang berhasil. Panduan di bawah memisahkan penyegaran itu dari mulai ulang sungguhan, membaca nilai yang benar-benar berlaku, dan mengubahnya hanya setelah biayanya ada di meja.

Kerjakan langkah-langkah secara berurutan, karena yang pertama menentukan apakah sisa halaman berlaku bagi Anda sama sekali. Lompat ke depan dan Anda akan menghabiskan satu malam menyetel pengatur waktu untuk kesalahan yang tidak ada hubungannya.

Bedakan reset lunak dari mulai ulang

Baris log adalah seluruh diagnosis. Negosiasi ulang menulis reset lunak lalu pertukaran kunci baru di dalam terowongan yang sama: antarmuka mempertahankan alamatnya, rute tidak ditambahkan lagi, dan sesi TCP yang sudah terbentuk biasanya bertahan dengan jeda. Mulai ulang sungguhan merobek sesi, membangun ulang antarmuka, mungkin memberikan alamat klien berbeda, dan membunuh setiap koneksi berumur panjang. Kedua peristiwa itu biasa; hanya satu yang menjelaskan panggilan terputus.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

Baris versi penting karena susunan kata log bergeser antar rilis, dan pesan yang Anda ingat dari 2.3 mungkin dirumuskan berbeda di 2.6. Baca log Anda sendiri, bukan kutipan forum orang lain. Kutip baris persisnya saat meminta bantuan, karena parafrase kehilangan detail yang mengidentifikasi peristiwa. Jika alamat antarmuka tidak berubah selama peristiwa dan daftar sesi bertahan, Anda melihat penyegaran dan bagian selanjutnya berlaku.

Baca pengatur waktu efektif, bukan berkas Anda

reneg-sec adalah jumlah detik antara negosiasi ulang kanal data dan nilai bawaannya 3600. Setiap pihak membawa nilainya sendiri, dan yang lebih kecil dari keduanya adalah yang benar-benar memicu penyegaran. Aturan tunggal itu menjelaskan sebagian besar laporan: profil klien yang menetapkan angka besar tetap direset tiap jam selama server mempertahankan nilai bawaan.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Baca juga konfigurasi efektif server, termasuk semua yang didorongnya, sebelum menarik kesimpulan dari berkas klien. Lalu naikkan verbositas dan amati satu interval dari awal sampai akhir: level 3 sudah menampilkan baris negosiasi ulang, dan stempel waktu memberi tahu apakah peristiwa berulang tiap 3600 detik atau mengikuti aktivitas.

Ubah di tempat yang benar-benar didorong

Obat yang beredar adalah satu baris di profil klien, dan sekitar separuh waktu itu tempat yang salah. Karena nilai pihak yang lebih rendah menang, klien yang menyetel pengatur waktu ke nol tetap dapat dinegosiasi ulang oleh server yang tidak berubah.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Ketika profil dibuat secara terpusat, sunting templatnya, bukan salinan yang diterapkan, atau jalur penyediaan berikutnya akan memulihkan nilai yang baru saja Anda hapus. Verifikasi dengan mengamati dua interval, bukan satu: satu jam yang tenang juga konsisten dengan pengatur waktu yang disetel ke 7200.

Putuskan juga apa yang terjadi pada penerapan campuran. Jika perubahan digulirkan ke klien lebih dulu, tersisa jendela di mana server masih memicu penyegaran; itu tidak berbahaya tetapi membingungkan jika Anda mengamati log untuk konfirmasi. Ubah sisi yang memegang nilai lebih kecil lebih dulu dan gejalanya hilang pada titik yang Anda harapkan.

Apa yang Anda lepaskan dengan menonaktifkan negosiasi ulang

Negosiasi ulang teratur membatasi berapa lama satu set kunci kanal data melindungi lalu lintas. Mematikan pengatur waktu tidak merusak terowongan, dan pada router rumah atau gateway kantor kecil paparan praktisnya sederhana. Ini tetap sebuah pertukaran, dan pertukaran itu layak disebutkan sebelum Anda melakukannya. Yang berubah adalah berapa lama satu set kunci melindungi sesi, bukan apakah terowongan itu bekerja sama sekali.

Kasus wajar untuk menonaktifkannya adalah reset yang merusak sesuatu yang tidak dapat dilanjutkan: panggilan yang terputus, sesi desktop jarak jauh yang harus dibangun ulang, cadangan yang dimulai dari awal. Jika jeda tidak terlihat oleh pengguna, membiarkan nilai bawaan tidak memakan biaya dan mempertahankan rotasi kunci yang diberikan kepada Anda.

Utamakan memperbaiki penyebabnya ketika polanya memungkinkan. Penyegaran yang gagal di tengah jalan sementara jabat tangan pertama berhasil menunjuk ke jalur, bukan ke pengatur waktu: cari masalah ukuran paket pada pertukaran kanal kendali yang lebih besar, firewall stateful yang menjatuhkan aliran, atau proposal yang hanya berhasil pada percobaan pertama. Masing-masing meninggalkan jejak di log yang sama yang baru saja Anda baca. Menonaktifkan pengatur waktu menyembunyikan bukti itu.

Ketika interval menunjuk ke tempat lain

Dua tetangga dalam konfigurasi menghasilkan gejala serupa dan perbaikan berbeda. ping-restart memulai ulang terowongan ketika tidak ada yang tiba selama periode yang dikonfigurasi, sedangkan ping-exit menurunkan klien sepenuhnya. Putus menganggur tanpa negosiasi ulang di mana pun dalam log menjadi milik ini, atau milik perangkat NAT yang membiarkan pemetaan UDP kedaluwarsa sesuai jadwalnya sendiri.

Router konsumen, hotspot seluler, dan NAT tingkat operator semuanya membiarkan sesi UDP menganggur kedaluwarsa tanpa memberi tahu siapa pun. Kegagalan itu mengikuti keadaan menganggur, bukan jam, dan itulah tandanya: sesi yang putus setelah sepuluh menit tenang dan bertahan satu jam lalu lintas stabil tidak sedang menegosiasi ulang.

Tuliskan tiga hal sebelum mengubah yang keempat: interval yang Anda ukur, nilai efektif yang Anda temukan, dan perintah yang menunjukkannya. Jika interval bergerak saat pengatur waktu bergerak, mekanismenya teridentifikasi dan perbaikannya adalah keputusan tentang pertukaran di atas. Jika tidak bergerak, kembalikan pengaturannya dan terus amati keepalive, status NAT, dan kehilangan paket.