Baru-baru ini saya mengalami masalah: klien memiliki dua Cisco ASA 5512-x, yang beroperasi dalam mode aktif / siaga. Klien lupa memperbarui kata sandi, dan semua pengguna telah kedaluwarsa kata sandi. Saat mencoba masuk, ASA hanya melaporkan tanggal kedaluwarsa dan tidak memungkinkan Anda untuk mengubah kata sandi. Karena semua pengguna kedaluwarsa, tidak mungkin menghubungkan dan mengubah kata sandi dengan cara apa pun. Selalu ada opsi ironis untuk mengatur ulang kata sandi dengan mengubah register, tetapi di sini Anda tidak dapat melakukannya tanpa downtime. Opsi ini tidak cocok. Diputuskan untuk menggunakan ASA siaga untuk menghindari downtime. Namun ada beberapa nuansa:
1) Jika Anda cukup me-restart ASA siaga, masuk ke mode ROMMON, ganti case dan boot, maka kami akan mendapatkan akses dan akan dapat mengubah kata sandi, tetapi segera setelah kami menjalankan
copy startup-config running-config
maka segera siaga ASA akan menemukan node aktif dan sudah akan menyinkronkan konfigurasi dari sana.
2) Jika Anda mematikan sinkronisasi dan hanya mengunduh konfigurasi, maka ASA siaga akan mengambil alamat ip aktif dan kami akan mengalami konflik.
Setelah refleksi, rencana berikut diciptakan:
1. Reboot ASA siaga, buka ROMMON, ubah register menjadi 0x41 dan boot:
rommon
rommon
2. Sekarang kita putuskan semua antarmuka ASA siaga (ada kemungkinan pada saklar di mana ASA terhubung atau cukup tarik semua kabel jaringan dari ASA itu sendiri).
3. Kami memasuki mode EXEC istimewa:
hostname> enable
dan muat konfigurasi kerja:
hostname# copy startup-config running-config
Di sini siaga ASA tanpa antarmuka aktif tidak dapat menyinkronkan data atau membahayakan konflik alamat ip jika menganggap dirinya node aktif. Kami masuk ke konfigurasi dan menambahkan pengguna baru untuk akses lebih lanjut:
hostname# configure terminal hostname(config)# username test password test
4. Di sini Anda dapat melakukan berbagai hal secara berbeda, jangan menghubungkan kabel, hanya pada akhirnya sambungkan kabel yang kami putuskan secara fisik, atau sambungkan, tetapi sebelum itu lepaskan semua antarmuka dari konfigurasi. Pada tahap ini, diputuskan untuk menonaktifkan semua antarmuka melalui konfigurasi dan mempersiapkan inklusi.
hostname(config)# interface interface_id hostname(config-if)# shutdown
5. Kembalikan register default, simpan konfigurasi dan reboot.
hostname(config)# no config-register hostname(config)# write
Sekarang siaga ASA setelah restart akan boot dengan konfigurasi dan tes pengguna yang kami butuhkan. ASA tidak akan dapat menemukan simpul aktif untuk sinkronisasi dengan siaga, karena antarmuka dimatikan, dan menjadi aktif tidak akan merusak apa pun untuk alasan yang sama.
6. Sekarang, setelah memuat dengan konfigurasi yang diinginkan, kita dapat terhubung dengan pengguna uji. Kami terhubung dan kami memasuki mode EXEC istimewa. Selanjutnya, aktifkan antarmuka atau antarmuka yang dimaksudkan untuk failover. Setelah itu, ASA siaga kami akan menemukan simpul aktif, menyinkronkan konfigurasi dan beralih ke mode siaga. Dalam hal ini, uji pengguna kami akan dihapus, tetapi karena pada saat itu kami sudah dalam mode EXEC istimewa, sesi kami akan tetap. Jika kita pergi pada saat ini, maka kita tidak akan bisa masuk, jadi kita harus sangat berhati-hati di sini. Semua antarmuka lain juga akan menyala karena sinkronisasi konfigurasi dari node aktif.
Kami dapat mengubah kata sandi pengguna hanya pada simpul aktif, tetapi kami masih tidak memiliki akses ke sana. Jalan keluarnya adalah membuat ASA stanby kami aktif dengan akses kami yang ada. Ketika ASA siaga kami memasuki status siap siaga setelah sinkronisasi dengan simpul aktif, kami dapat beralih. Anda dapat melihat status menggunakan perintah:
hostname(config)# show failover state
Dan dengan perintah kedua, kita beralih dari ASA Aktif ke Siaga ASA:
hostname(config)# failover active
7. Sekarang, kita memiliki akses pada node aktif. Di sini sudah mungkin untuk mengubah kata sandi pengguna dan beralih kembali jika perlu (jika ini sangat penting).
Dengan demikian, kami dapat mengatur ulang kata sandi tanpa downtime dalam skema ini. Anda hanya perlu mempertimbangkan penundaan saat beralih dari node aktif ke node cadangan.