Memantau antarmuka tunnel IPsec: apa yang perlu dibaca

Desain IPsec berbasis rute memasang antarmuka virtual, dan antarmuka itu memberikan objek konkret kepada pemantauan: sesuatu dengan nama, penghitung, dan rute yang terpasang padanya. Itu bukan sinyal kesehatan dengan sendirinya. Antarmuka dapat ada sementara tidak ada asosiasi yang dapat digunakan terpasang, dan asosiasi dapat sehat sementara tidak ada rute yang mengarahkan lalu lintas menarik ke sana. Membaca empat keadaan bersama-sama adalah yang mengubah penghitung paket menjadi diagnosis.

Telusuri secara berurutan dan berhenti pada keadaan pertama yang gagal.

Apa yang ditambahkan antarmuka ke gambaran

Dalam desain berbasis kebijakan, pemilihan berada di tabel kebijakan IPsec dan kernel memutuskan apa yang dilindungi berdasarkan pemilih lalu lintas. Desain berbasis rute menambahkan antarmuka dan rute, sehingga tcpdump dan penghitung antarmuka melihat satu batas alih-alih sekumpulan pemilih. Ini adalah keuntungan nyata bagi diagnosis dan bagi protokol perutean yang memerlukan antarmuka untuk peering.

Keuntungannya bersifat administratif, bukan kriptografis. Antarmuka melaporkan lalu lintas yang dibawanya dan tidak mengatakan apa pun tentang apakah perlindungan pihak lawan dapat digunakan saat ini.

Baca keempat keadaan sebelum menyalahkan tunnel

Mulai dari antarmuka dan rute, lalu asosiasi, lalu aplikasi. Masing-masing punya perintahnya sendiri dan tanda kegagalannya sendiri. Hasil bersih di satu lapisan bukan hasil bersih di lapisan berikutnya. Jalankan keempatnya sebelum menarik kesimpulan. Satu baris hijau jarang menyelesaikan apa pun.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Antarmuka dengan penghitung yang naik tetapi tanpa entri keadaan yang cocok menggambarkan lalu lintas yang masuk ke jalur yang tidak dilindungi apa pun, dan itu lebih buruk daripada tunnel yang sekadar mati. Entri keadaan tanpa rute yang memilih antarmuka berarti kriptografi siap dan tidak terpakai.

Uji aplikasi datang terakhir dan sengaja: ping yang berhasil ke sisi lain tunnel tidak membuktikan bahwa layanan di belakangnya menerima koneksi.

Bandingkan penghitung dalam dengan penghitung luar

Penghitung pada antarmuka tunnel mengukur lalu lintas dalam; penghitung dan tangkapan pada antarmuka fisik menunjukkan pertukaran yang dienkapsulasi. Keduanya tidak akan cocok satu-satu, karena enkapsulasi menambah header, pengiriman ulang menduplikasi sebagian paket, dan pembukuan implementasi mengikuti aturannya sendiri. Harapkan rasio, bukan kesamaan.

Penempatan tangkapan juga menentukan data pribadi apa yang Anda kumpulkan, jadi gunakan filter sempit dan alamat uji yang tidak berbahaya alih-alih menangkap seluruh lalu lintas produksi.

Jika penghitung dalam naik dan yang luar tidak, langkah yang hilang biasanya adalah rute atau kebijakan yang mengirim paket ke tunnel, bukan tunnel itu sendiri.

Pantau melalui pembaruan kunci dan failover

Amati pembaruan kunci, peristiwa deteksi peer mati, dan failover tautan sambil memantau keempat keadaan yang sama. Antarmuka dapat tetap ada selama pembaruan kunci yang tidak pernah selesai, dan failover dapat meninggalkan entri keadaan yang menunjuk ke alamat peer yang tidak lagi dapat dijangkau.

Berikan peringatan pada jalur layanan yang benar-benar Anda andalkan, dengan keadaan asosiasi sebagai konteks, bukan pada satu bendera naik atau turun. Simpan nama antarmuka, alamat peer, dan rute di muatan peringatan agar penanggap tidak perlu membangunnya ulang.

strongSwan mendokumentasikan model antarmuka XFRM miliknya sendiri, dan platform lain menamai serta mengimplementasikan objek yang setara secara berbeda. Baca perbandingan berbasis rute untuk perangkat di depan Anda sebelum memindahkan asumsi dari implementasi lain. Templat pemantauan yang cocok untuk penghitung satu vendor akan menyesatkan secara diam-diam pada vendor lain.