Pantau VPN router tanpa percaya pada satu lampu status
Status peer, rute terpilih, dan uji aplikasi yang diizinkan menjawab pertanyaan berbeda. Beri alarm pada batas yang gagal, bukan pada ikon hijau.
Halaman status menyatakan terhubung, lampunya hijau, tetapi kantor tidak dapat menjangkau server berkas. Salah satu fakta itu tentang terowongan dan yang lain tentang jalur di dalamnya. Memantau keduanya adalah perbedaan antara peringatan yang bisa Anda tindak lanjuti dan yang Anda pelajari untuk diabaikan.
Lima pemeriksaan, berurutan, dari peer ke luar.
Pemeriksaan 1: status peer atau asosiasi
Setiap protokol menampilkan statusnya sendiri. WireGuard menampilkan handshake terakhir dan penghitung transfer per peer melalui wg show. OpenVPN menulis status sesi ke berkas status atau antarmuka manajemennya, dan IPsec menampilkan asosiasi keamanan melalui alat seperti ipsec statusall. Jebakannya adalah membaca stempel waktu sebagai vonis: peer WireGuard yang diam tanpa apa pun untuk dikirim tidak akan melakukan handshake baru-baru ini, dan itu bukan gangguan.
Bandingkan stempel waktu dengan lalu lintas yang diharapkan dan pengaturan keepalive sebelum memanggil siapa pun.
Pemeriksaan 2: rute terpilih
Antarmuka terowongan bisa ada sementara tidak ada yang dirutekan ke dalamnya. Periksa tabel penerusan untuk tujuan yang Anda pedulikan, bukan untuk subnet terowongan itu sendiri. Jika prefiks tidak ada atau menunjuk ke tempat lain, status peer tidak relevan.
Pemeriksaan itu menangkap kegagalan yang tidak pernah ditunjukkan lampu status.
Pemeriksaan kedua yang berguna juga membandingkan alamat sumber. ip route get 10.20.5.10 mengembalikan hop berikutnya, antarmuka, dan sumber pilihan, dan sumber yang salah cukup untuk memutus lalu lintas balik di ujung jauh. Catat tripel yang diharapkan sekali, lalu beri alarm saat elemen apa pun berubah. Satu baris itu menangkap perubahan NAT, ketidakstabilan antarmuka, dan kesalahan perutean berbasis kebijakan.
Pemeriksaan 3: jalur aplikasi yang diizinkan
Uji sesuatu yang mewakili kebutuhan sebenarnya. Ping yang berasal dari router keluar dari alamat dan kebijakan router itu sendiri, yang bisa berbeda dari lalu lintas LAN yang diteruskan, dan banyak host membatasi ICMP. Jika kebutuhannya layanan privat, uji layanan itu pada port aslinya.
Jaga volume uji tetap wajar. Simpul pemantauan tidak boleh menjadi lalu lintas yang diukurnya.
Pemeriksaan 4: apa yang berubah dan kapan
Korelasikan perubahan WAN, pembaruan kunci, penarikan rute, dan kegagalan aplikasi pada satu garis waktu. Bedakan kegagalan terowongan dari rute cadangan yang diam-diam memulihkan akses internet biasa, karena keduanya menghasilkan laporan pengguna yang identik dan diagnosis yang berlawanan. Kesalahan zona waktu akan membalik urutan, jadi normalkan sebelum membandingkan. Garis waktu itulah yang mengubah empat pemeriksaan menjadi penyebab.
Simpan log untuk transisi, bukan untuk muatan.
Pemeriksaan 5: alarm harus menyebut batasnya
Alarm yang menyebut VPN mati mengirim orang ke tempat yang salah separuh waktu. Alarm yang menyebut handshake peer basi selama dua belas menit, rute ke 10.20.0.0/16 tidak ada, atau uji ke port 445 gagal, menunjuk ke pemeriksaan tertentu.
Simpan penghitung operasional alih-alih menjelajahi muatan. Penghitung menjawab pertanyaan pemantauan tanpa mengumpulkan konten yang tidak Anda butuhkan.
Dan biarkan kebijakan failover memutuskan apa yang terjadi selanjutnya. Pemantauan harus mengidentifikasi batas mana yang gagal, bukan mengizinkan jalan pintas luas setiap kali uji gagal. Manual OpenVPN 2.6 mendokumentasikan berkas status dan antarmuka manajemen yang membuat pemeriksaan pertama dapat diskrip.