Deteksi rekan mati IKEv2 tidak menguji aplikasi Anda

Pemeriksaan keaktifan IKEv2 mengajukan satu pertanyaan: apakah rekan lain masih menjawab pada hubungan kontrol yang dilindungi. Pemeriksaan ini tidak mengukur apakah aplikasi internal sehat, apakah ada rute di balik gateway, atau apakah menjelajah terasa cepat. Pemeriksaan bisa lolos sementara semua yang berguna di balik terowongan gagal.

Baca kedua jenis bukti secara terpisah sebelum mengubah pengatur waktu.

Apa yang sebenarnya ditanyakan pemeriksaan keaktifan

Pertukaran keaktifan dikirim di dalam asosiasi keamanan IKE yang sudah terbentuk dan mengharapkan jawaban dalam jendela yang dikonfigurasi. Keberhasilan berarti implementasi IKE rekan masih ada dan masih bersedia berbicara. Itu tidak mengatakan apa pun tentang asosiasi keamanan anak yang membawa lalu lintas, tidak tentang perutean di luar gateway, dan tidak tentang layanan yang membuat Anda membuka terowongan. Itu tiga pertanyaan terpisah dengan tiga mode kegagalan terpisah.

Perbedaan itulah yang menentukan ke mana Anda melihat saat sesi menjadi sunyi. Rekan yang terus menjawab sementara jalur data rusak menunjuk pada kebijakan, perutean, atau layanan hilir. Rekan yang berhenti menjawab menunjuk pada keterjangkauan atau keadaan ujung jauh itu sendiri.

Baca asosiasi keamanan sebelum peramban

Keadaan kontrol dan keadaan data dicantumkan terpisah begitu Anda bertanya kepada daemon, dan penghitung memberi tahu apakah ada upaya sama sekali. Asosiasi anak yang tidak pernah dipasang sama sekali berbeda dari yang dipasang lalu berhenti melewatkan paket, meskipun keduanya menghasilkan keluhan pengguna yang sama.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Catat nama keadaan apa adanya di tiket, bersama penghitung pada saat keluhan. Deskripsi seperti terowongan mati menyembunyikan asosiasi mana dari keduanya yang berakhir, dan biasanya itulah satu-satunya fakta yang layak disimpan.

Kegagalan rute terlihat persis seperti rekan mati

Gateway dapat menjawab pertukaran kontrol sementara server privat sedang offline, rute yang diteruskan hilang, atau resolusi nama internal gagal total. Dari sisi klien, setiap kasus itu tampak sebagai sesi yang hidup dan tujuan yang tidak hidup. Periksa jalur kembali seceermat jalur maju, karena perutean asimetris di sisi jauh hanya menghasilkan kesunyian pada satu arah.

Uji aplikasi yang dimaksud secara langsung dan sebutkan alamat yang dicobanya, bukan menguji apakah terowongan hidup. Ping ke gateway membuktikan gateway menjawab; itu tidak pernah membuktikan aplikasi menjawab. Catat alamat persis yang dicoba aplikasi. String itu mempersempit pencarian nanti, dan itulah satu-satunya fakta yang biasanya dilewatkan tiket.

Jauhkan pengatur waktu dari diagnosis

Memperpendek interval deteksi bukanlah perubahan kinerja dan tidak menambah kapasitas. Di bawah kehilangan paket, itu mengubah seberapa cepat kegagalan dikenali, yang dapat membuat gejala tampak berbeda tanpa membuat apa pun lebih baik. Catat waktu kegagalan yang sebenarnya lebih dulu, lalu putuskan apakah toleransi itu salah untuk tautan yang benar-benar Anda miliki.

Penyegaran pemetaan NAT termasuk kategori yang sama. Itu menjaga jalur yang diterjemahkan tetap dapat dipakai, dan itu bukan bukti bahwa aplikasi jarak jauh berfungsi.

Kebijakan pemulihan yang lengkap menyatakan apa yang harus dilakukan klien ketika rekan dinyatakan mati: mulai ulang, tutup, atau tahan, dan apa yang boleh dilakukan lalu lintas lain selama itu terjadi. Tanpa itu, insiden yang sama didiagnosis ulang dari awal setiap kuartal.