VPN terputus pada interval yang sama? Cocokkan timer
Putus pada interval tetap adalah sidik jari. Bandingkan rekey terowongan, timer menganggur NAT, sewa DHCP, dan batas akun sebelum mengubah apa pun.
Terowongan yang mati setiap lima belas menit, atau setiap jam pada menit yang sama, memberi tahu Anda bahwa ada timer yang kedaluwarsa, bukan bahwa jaringan tidak stabil. Langkah yang berguna adalah mencatat intervalnya dan membandingkannya dengan empat timer yang menghasilkan pola ini. Mengubah batas waktu sebelum perbandingan itu biasanya memindahkan kegagalan tanpa menjelaskannya, yang membuat kejadian berikutnya lebih sulit dibaca daripada yang pertama. Pengukurannya memakan sepuluh menit dan menggantikan sepekan dugaan.
Ubah interval menjadi angka
Kumpulkan lima atau enam kejadian dan hitung jarak di antaranya, bukan jarak dari awal hari. Putus pada 09:12, 10:12, dan 11:12 adalah batas per jam; putus pada 09:12, 09:27, dan 09:42 adalah lima belas menit sejak koneksi berhasil terakhir. Bulatkan hasilnya ke timer yang paling masuk akal, bukan ke menit terdekat.
Catat dua momen per kejadian: kapan lalu lintas terakhir bergerak dan kapan klien melaporkan pemutusan. Keduanya berbeda ketika terowongan mati diam-diam dan klien baru menyadarinya pada pengiriman berikutnya, dan perbedaan itulah yang memisahkan batas waktu menganggur dari kegagalan keras. Klien yang terlambat menyadari membengkakkan jendela menganggur yang Anda ukur.
Perhatikan apakah penyambungan ulang otomatis. Klien yang menyambung ulang dalam hitungan detik menjaga interval tetap terlihat di log dan di luar laporan pengguna, itulah sebabnya kegagalan ini sering digambarkan sebagai kadang-kadang bukan berkala. Ini juga menyembunyikan kejadian dari orang yang menggunakan laptop.
Empat timer yang tampak serupa
Hampir setiap penurunan terowongan yang berulang berasal dari salah satu ini: rekey protokol, kedaluwarsanya pemetaan menganggur, kejadian DHCP atau antarmuka, atau kebijakan akun. Mereka berbeda dalam apakah lalu lintas mengalir dan dalam apa yang dikatakan log di batas.
Tanda tangan di bawah ini layak dipelajari, karena memungkinkan Anda menolak tiga penjelasan dari satu baris log:
| Timer | Typical trigger | What the log shows at the boundary |
|---|---|---|
| Protocol rekey | Traffic present, fixed interval | Negotiation lines, sometimes a failure |
| NAT or firewall idle | No traffic for minutes | Silence, then a timeout on send |
| DHCP lease or link change | Half the lease, or a radio event | Address or interface churn |
| Account session limit | Wall-clock hours since login | Clean disconnect, server-side reason |
Baris pertama adalah mekanisme keamanan yang menjalankan tugasnya, dan yang kedua adalah perangkat perantara yang lupa keadaan. Mencampur keduanya mengarah pada melemahkan rekey atau mengejar aturan firewall yang tidak pernah terlibat.
Sibuk versus menganggur memberi tahu Anda paruh mana
Lakukan perbandingan terkendali dengan lalu lintas berkelanjutan, seperti aliran panjang ke host di dalam terowongan, dan amati apakah intervalnya berubah. Jika pemutusan hilang saat data mengalir, timernya berbasis menganggur.
Jika bertahan terhadap lalu lintas berkelanjutan, penyebabnya termasuk rekey, sewa, atau kebijakan. Satu uji ini menyingkirkan separuh kandidat dalam sekitar satu jam pengamatan, dan tidak memakan biaya selain perhatian.
Jaga jaringan akses tetap tidak berubah selama uji. Berpindah antara Wi-Fi dan Ethernet di tengah perbandingan memasukkan tepat kejadian antarmuka yang ingin Anda bedakan dari timer.
Cocokkan baris log dengan batas
Baca log klien dan server di sekitar momen yang dicatat, bukan seluruh berkas. Rekey menunjukkan negosiasi; kedaluwarsa menganggur tidak menunjukkan apa pun sampai paket berikutnya; perubahan sewa menunjukkan kerja alamat; batas kebijakan biasanya menunjukkan pemutusan administratif yang bersih.
Perintah ini menarik jendela yang relevan dari setiap sumber:
grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg showJika ketiga sumber setuju pada stempel waktu, Anda tahu pemilik timernya. Jika hanya log klien yang berisi sesuatu, server kemungkinan bukan yang mengakhiri sesi.
Perbaiki tahapnya, bukan ikonnya
Setiap pemilik punya satu perbaikan yang didukung. Kegagalan rekey membutuhkan proposal yang kompatibel di kedua ujung. Kedaluwarsa menganggur membutuhkan keepalive atau ekspektasi menganggur yang lebih pendek, dalam batas yang diizinkan jalur. Kejadian sewa membutuhkan pengaturan antarmuka atau daya yang dibenahi. Batas akun adalah keputusan kebijakan, bukan bug.
Mematikan rekey atau autentikasi demi ikon tetap hijau menukar pemutusan yang terlihat dengan kelemahan yang tak terlihat, dan membuat Anda tidak bisa mengatakan kapan terowongan terakhir menegosiasikan kunci baru. Uji ulang durasi aslinya setelah itu dan simpan stempel waktunya, agar kejadian berikutnya dapat dibandingkan dengan yang ini alih-alih mulai dari awal.