Mengapa Permintaan TACACS+ dari ASA Melewati Tunnel VPN Cabang Anda

Tunnel cabang sudah aktif, pengguna diautentikasi ke server TACACS+ jarak jauh, tetapi login firewall itu sendiri masih timeout. Penyebabnya bukan bug pada tunnel: tunnel LAN-to-LAN membawa lalu lintas yang cocok dengan selectornya, dan lalu lintas manajemen yang dihasilkan ASA tentang dirinya sendiri adalah aliran terpisah dengan alamat sumbernya sendiri. Sebagian besar tim menemukannya saat jendela perubahan, ketika satu-satunya akun administrator justru yang gagal. Perlakukan sesi AAA yang dimulai ASA sebagai aliran yang harus Anda rancang, bukan sebagai efek samping dari konektivitas yang sudah berjalan.

ASA adalah kliennya, dan lalu lintasnya sendiri memerlukan jalurnya sendiri

Saat firewall menghubungi server TACACS+, firewall adalah klien seperti klien lain, hanya saja tidak ada yang sengaja mengonfigurasi rute untuknya. Paketnya berasal dari alamat antarmuka pada perangkat, dibuat secara lokal alih-alih diteruskan, dan harus dirutekan, diterjemahkan, serta dilindungi kebijakan persis seperti lalu lintas pengguna. Tunnel situs-ke-situs yang melindungi subnet pengguna tidak otomatis melindungi sumber manajemen tersebut, karena pemilihan lalu lintas didasarkan pada alamat, bukan pada niat.

Tuliskan alamat yang Anda harapkan dilihat server. Jika Anda tidak dapat menyatakannya dalam satu baris, Anda belum memiliki rancangan.

Antarmuka pada baris aaa-server bukan hiasan

Di ASA, entri host aaa-server mengambil asosiasi antarmuka dalam tanda kurung, dan referensi perintah host AAA dari Cisco menjelaskannya sebagai antarmuka tempat server autentikasi berada. Asosiasi itulah yang mengikat permintaan ke sebuah antarmuka dan ke kebijakan yang diterapkan antarmuka tersebut. Memilihnya berdasarkan antarmuka mana pun yang menghadap internet, atau membiarkan apa yang tersisa dari migrasi terakhir, menghasilkan alamat sumber yang tidak pernah dirancang untuk server jarak jauh dan tunnel itu.

inside hanya jawaban yang benar bila antarmuka yang disebut memegang alamat yang hendak dipakai rancangan Anda sebagai sumber. Pada perangkat cabang sering demikian; pada perangkat dengan beberapa segmen privat mungkin tidak.

Mengubah asosiasi berarti membuat ulang entri

Referensi perintah yang sama mendokumentasikan batasan penyuntingan yang menjebak orang saat cutover: mengubah antarmuka pada host yang ada mengharuskan entri host dihapus dan dibuat ulang. Konfigurasi yang tampak sudah diedit mungkin belum berlaku, dan percobaan login berikutnya tetap keluar dari alamat lama. Rencanakan itu sebagai hapus-dan-tambah dengan salinan entri asli di depan Anda, bukan sebagai perubahan di tempat.

Jika ada beberapa server, ubah satu dan ujilah sebelum menyentuh sisanya, agar satu kesalahan tidak mengunci semua jalur administratif sekaligus.

Periksa selector, terjemahan, dan jalur balik bersama-sama

Tiga hal harus selaras agar permintaan tiba. Selector lalu lintas tunnel, atau perlindungan antarmuka tunnel jika Anda memakainya, harus mencakup sumber milik ASA sendiri dan alamat server; daftar selector yang dibangun untuk subnet pengguna biasanya tidak. Aturan NAT apa pun di jalur harus menerjemahkan sumber itu secara konsisten, karena server mengotorisasi identitas perangkat jaringan yang mencakup alamat yang dilihatnya. Dan jalur balik harus ada, yang pada tunnel berbasis kebijakan berarti ujung jauh memiliki selector yang cocok pada arah sebaliknya.

Di sisi server, pastikan identitas perangkat, secret bersama, dan kebijakan administratif secara terpisah. TACACS+ memelihara autentikasi, otorisasi, dan akuntansi sebagai operasi yang berbeda, jadi penolakan yang datang setelah pertukaran selesai adalah jawaban kebijakan, bukan kegagalan transport. Membacanya sebagai masalah jaringan membuat Anda mencari di tempat yang salah.

Jauhkan secret dari tangkapan paket, tiket, dan transkrip saat men-debug, dan ingat bahwa alamat sumber yang dicatat server adalah alamat yang harus dijelaskan rancangan Anda.

Lakukan perubahan tanpa mengunci diri sendiri

Gunakan konsol atau jalur manajemen independen saat mengubah autentikasi administratif jarak jauh, dan pertahankan fallback lokal yang disetujui sampai jalur baru telah membawa login sungguhan. Lalu validasi secara sempit: satu server, satu perangkat, satu autentikasi berhasil dengan alamat sumber teramati di kedua ujung.

Catat aliran itu di halamannya sendiri: antarmuka dan alamat asal, server jarak jauh, jalur terlindungi, dan orang yang memiliki kebijakan otorisasi. Perubahan antarmuka atau tunnel berikutnya kemudian dapat dinilai tanpa menebak aliran mana dari keduanya yang terpengaruh.