Failback di ASA: apa yang sebenarnya berpindah saat rute kembali
Rute yang kembali ke jalur utama tidak berarti aliran lama ikut berpindah. Amati uplink, tunnel, tabel koneksi, dan hasil aplikasi secara bersamaan.
Pada ASA dengan dua uplink, failback bukan kebalikan dari failover. Rute ke peer berubah, lalu platform harus menyelaraskan tiga mesin status yang terpisah: tabel rute, asosiasi keamanan IKE dan IPsec, serta tabel koneksi. Masing-masing bisa tertinggal dari yang lain, dan keterlambatan itulah yang biasanya orang sebut tunnel yang tidak kembali.
Apa yang sebenarnya diubah failback
Pencarian rute adalah bagian yang terlihat. Saat objek yang dipantau pulih, rute terpantau ke alamat luar peer kembali, dan paket berikutnya yang dikirim ASA mengikuti jalur utama lagi. Semua yang setelah itu bergantung pada apakah status yang ada sesuai dengan jalur baru.
ARP dan NAT adalah ketergantungan yang senyap. Next hop baru membutuhkan gateway yang bisa diresolusi dan terjemahan yang masih cocok dengan ujung jauh, jika tidak paket pertama setelah failback tidak ke mana-mana dan rute tampak baik-baik saja sementara tidak ada yang bekerja.
Empat sudut pandang pada satu garis waktu
Catat empat hal yang sama sebelum, selama, dan setelah transisi, karena satu cuplikan tidak bisa memberi tahu lapisan mana yang bergerak.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
Rute yang tidak pernah berubah dan rute yang berubah sementara koneksi lama mempertahankan status penerusannya menghasilkan keluhan yang sama dan bukti yang sama sekali berbeda.
Mengapa koneksi lama tetap di jalur cadangan
ASA tidak memutus aliran karena rute berubah. Koneksi yang sudah terbentuk mempertahankan keputusan penerusan yang dipakai saat dibuat, dan platform menyediakan kontrol terpisah untuk berapa lama itu diizinkan: floating-connection timeout dan connection holddown. Panduan pengaturan koneksi ASA 9.24 dari Cisco memperlakukannya sebagai dua pertanyaan berbeda, dan memang begitulah perilakunya. Satu mengatur kelangsungan aliran yang ada; yang lain mengatur kapan aliran baru boleh memakai jalur pilihan.
Baca nilai efektif untuk rilis Anda sebelum mengubah salah satunya. Menurunkannya menutup sesi yang masih dipakai orang. Menaikkannya membuat failback tampak tidak pernah terjadi, karena koneksi baru terus memakai jalur lama selama periode itu.
Tunnel tidak menegosiasikan ulang kunci karena rute kembali
Asosiasi keamanan IPsec membawa masa hidup hasil negosiasi sendiri dan bertahan melewati perubahan rute yang membawanya. Karena itu tunnel bisa tetap hidup saat failback sementara pengalamatan luarnya tidak lagi cocok dengan jalur yang dipakai, dan inilah alasan DPD serta desain yang mematok alamat peer alih-alih membiarkannya mengambang.
Desain crypto-map dan VTI berperilaku berbeda di sini, dan dokumentasi Cisco untuk 9.24 VTI menjelaskan opsi berbasis rute. Klaim lama yang menyeluruh bahwa ASA tidak bisa menjalankan VPN berbasis rute tidak berlaku untuk rilis yang didukung.
Baca bukti dalam urutan ini
Mulailah dari bidang kontrol: show route untuk jalur terpilih, show interface untuk status link, dan penghitung monitor SLA untuk objek yang dipantau. Lalu baca show crypto ikev2 sa, atau padanan IKEv1, untuk melihat peer mana yang hidup, diikuti show crypto ipsec sa untuk aliran yang dilindungi. Kemudian persempit tabel koneksi dengan show conn address <host> dan bandingkan kolom antarmuka pada entri lama dan baru. Tuliskan keluaran dengan stempel waktu, karena urutannya adalah diagnosis.
Akhiri dengan uji aplikasi: satu aliran yang sudah ada dan satu yang dibuat setelah rute kembali. Jika aliran lama gagal dan yang baru bekerja, Anda punya cerita status koneksi. Jika keduanya gagal, tunnel atau kebijakannya salah dan tabel koneksi hanyalah pengalih perhatian.
Jaga catatan itu dalam bentuk yang sama pada ketiga fase, dan catat rilis yang tepat. Bila garis waktu terus menunjuk satu transisi saja, kirim catatan ke dukungan daripada menebak ID bug.