Terowongan masih hidup, rute hilang: memisahkan dua kegagalan VPN

Satu host menjadi tidak dapat dijangkau sementara antarmuka terowongan masih melaporkan dirinya terbentuk, dan kedua pengamatan itu tidak saling bertentangan. Sesuatu menghapus jalur yang dipakai lalu lintas: tetangga menarik kembali prefiksnya, rute statis yang dilacak dicabut, atau rute lain menjadi lebih disukai. Asosiasi keamanan dapat tetap sepenuhnya sehat pada ketiga kasus. Memisahkan peristiwanya berarti menanyakan lapisan mana yang berubah lebih dulu, bukan apakah VPN gagal.

Tiga tahap yang tampak seperti satu peristiwa

Keputusan perutean punya tiga tahap. Prefiks diterima, dipilih sebagai yang terbaik, dan dipasang di tabel penerusan. Setiap tahap dapat gagal sendiri, dan kegagalan tampak sama dari sisi aplikasi. Prefiks yang dipelajari tetapi kalah dalam pemilihan tidak dapat dibedakan dari prefiks yang tidak pernah datang ketika satu-satunya bukti yang Anda lihat adalah tabel penerusan.

Karena itu pertanyaan pertama adalah tahap mana yang rusak, bukan protokol mana yang bersalah. Jawabannya menentukan siapa pemilik insiden dan alat mana yang dipakai pemeriksaan berikutnya.

Baca rute yang terpasang lebih dulu

Tanyakan kepada kernel ke mana lalu lintas menuju tujuan yang gagal sebenarnya pergi. ip route get mencetak hop berikutnya, antarmuka, dan alamat sumber yang akan dipakai kernel, dan ia menjawab untuk satu tujuan, bukan untuk seluruh tabel. Jika jawabannya menyebut terowongan, tabel penerusan masih percaya jalurnya ada dan masalahnya berada di atasnya.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Jawaban «unreachable» berarti tidak ada rute yang terpasang sama sekali, yang mengarah pada pencabutan atau pemasangan yang hilang. Jawaban yang menyebut antarmuka fisik berarti lalu lintas meninggalkan terowongan tanpa ada yang memutuskannya, dan pemeriksaan berikutnya adalah preferensi yang menang. Jawaban yang menyebut terowongan sementara paket tetap menghilang mengarah lebih jauh ke jalur, ke penyaringan atau ke sisi jauh.

Lalu lihat pandangan protokol itu sendiri

Daemon perutean menyimpan lebih dari satu tabel, dan perbandingan yang menarik ada di antaranya. Untuk BGP, status sesi tetangga, pengumuman yang diterima, dan rute yang terpasang adalah tiga bukti terpisah. Sebuah prefiks dapat duduk di tabel yang diterima dan tidak pernah mencapai kernel karena rute dengan jarak administratif lebih pendek menang. Periksa ketiganya sebelum menyimpulkan bahwa pihak lain berhenti mengumumkan.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Ringkasan memberi tahu apakah sesi terbentuk, tampilan per prefiks memberi tahu apakah prefiks diterima, dan pencarian kernel memberi tahu apakah ia dipasang. Membacanya dalam urutan itu mencegah kedutan sesi disalahartikan sebagai pencabutan, dan pencabutan disalahartikan sebagai penolakan kebijakan.

Ketika jam tidak sepakat

Letakkan log terowongan, log perutean, dan kegagalan aplikasi pertama pada satu garis waktu menggunakan zona waktu aslinya. Jika kehilangan tetangga datang lebih dulu, terowongan menjatuhkan rute bersamanya. Jika pencabutan datang lebih dulu, perutean berubah dan terowongan bereaksi sesudahnya. Itu insiden berbeda dengan pemilik berbeda, dan urutannya adalah seluruh temuannya.

Satu menit penyimpangan jam cukup untuk membalik kesimpulan itu, jadi pastikan zona waktu dan offsetnya sebelum memercayai urutannya. Perangkat yang mencatat dalam waktu lokal tanpa offset adalah sumber biasa dari garis waktu yang yakin tetapi salah.

Pemulihan tanpa lingkaran

Setelah pencabutan, dua jalur dapat memenuhi syarat: yang dipilih protokol dan yang Anda sematkan dengan tangan. Hanya yang pertama adalah keputusan yang terus diambil jaringan untuk Anda, karena itu rute manual adalah tambalan sementara dan bukan rencana pemulihan. Pengumuman alternatif juga tidak mempertahankan status firewall atau NAT untuk sesi yang sudah terbentuk, sehingga aliran baru dapat bekerja sementara aliran asli tetap rusak. Pastikan cadangan mana yang harus aktif dan apakah situs jauh akan menerima jalur balik melaluinya.

Jangan pasang penimpaan statis permanen sebelum Anda memahami mengapa pencabutan terjadi. Jalan pintas itu dapat menyematkan lalu lintas ke jalur yang gagal atau diam-diam melewati kebijakan perutean yang disengaja, dan ia mengubur penyebab asli di bawah konfigurasi baru. Uji ulang aplikasi setelah rute dipulihkan, dan pastikan prefiks yang dipilih punya jalur data yang bekerja, bukan hanya entri di tabel.