SSH ke ASA Jarak Jauh melalui VPN Situs: Langkah demi Langkah

Anda mengarahkan klien SSH ke alamat dalam ASA jarak jauh dan sesi mati saat menghubungkan. Firewall menjawab dari situsnya sendiri, terowongan muncul, namun tidak ada yang mendengarkan pada port 22. Pada sebagian besar kasus ini paket tidak pernah mencapai penerimaan manajemen, karena jalur yang diuji tidak pernah dirancang sebagai jalur manajemen. Ikuti alur di bawah secara berurutan dan kegagalan berhenti berpindah.

Pilih alamat yang benar-benar Anda kelola

Tiga desain terlihat serupa dan berperilaku berbeda: menjangkau alamat publik ASA yang menghadap VPN, menjangkau antarmuka internal melalui IPsec, dan menjangkau antarmuka manajemen khusus. Catat alamat sumber administrator, alamat tujuan yang tepat, dan TCP 22 sebelum menyentuh izin apa pun. Semua yang berikutnya bergantung pada pasangan itu.

Terowongan yang membawa dua VLAN server mungkin sama sekali tidak membawa alamat antarmuka firewall atau subnet manajemen administrator. Periksa daftar lalu lintas menarik untuk kebijakan situs-ke-situs dan pastikan alamat ASA sendiri muncul sebagai tujuan, bukan hanya subnet yang melewatinya.

Karena tujuannya adalah firewall itu sendiri, penerimaan manajemen terpisah dari aturan untuk lalu lintas yang diteruskan. ACL yang memungkinkan klien menjangkau server di belakang ASA tidak dengan sendirinya mengaktifkan administrasi SSH perangkat, dan memperbaiki aturan penerusan tidak akan menggeser kegagalan ini.

management-access bersifat khusus antarmuka

Perintah management-access memberi tahu ASA untuk menerima koneksi manajemen ke antarmuka bernama ketika datang melalui VPN. Perintah ini tidak membuat rute, tidak menambahkan izin SSH, dan tidak berlaku untuk semua antarmuka sekaligus. Jika antarmuka tujuan bukan yang disebutkan, koneksi dibuang sebelum autentikasi.

Dua pengecualian menggigit di sini. Antarmuka khusus manajemen berada di luar mekanisme ini, dan panduan manajemen ASA 9.20 mencatat bahwa tumpukan CiscoSSH bawaan tidak mendukung SSH antar-antarmuka melalui VPN sedangkan tumpukan ASA SSH mendukungnya. Pastikan tumpukan aktif pada rilis yang dipasang sebelum menghabiskan waktu pada rute.

Empat gerbang sebelum prompt login

Antara klien dan prompt nama pengguna berdiri empat gerbang independen: kecocokan rute dan terowongan untuk pasangan manajemen, ACL antarmuka yang mengizinkan TCP 22 ke alamat ASA, izin ssh yang mencakup sumber administrator, dan autentikasi AAA untuk pengguna itu. Masing-masing dapat menjatuhkan paket tanpa memberi tahu klien gerbang mana yang tertutup.

Gunakan packet-tracer untuk melihat gerbang mana yang gagal sebelum mengubah apa pun: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Pelacakan menyebutkan ACL, tahap NAT, dan keputusan to-the-box, yang biasanya cukup untuk memisahkan masalah perutean dari masalah penerimaan.

Tulis izin yang sempit, bukan yang luas

Batasi izin ke subnet administratif yang disetujui dan antarmuka yang menerima lalu lintas terowongan: ssh 10.10.5.0 255.255.255.0 inside. Pasangkan dengan metode autentikasi seperti aaa authentication ssh console LOCAL dan akun lokal bernama, alih-alih membuka setiap sumber pada antarmuka luar.

Jaga konsistensi ACL antarmuka dan izin ssh. Izin untuk subnet yang diblokir ACL tetap gagal, dan ACL yang mengizinkan subnet tanpa entri ssh yang cocok gagal di gerbang berikutnya. Kedua pernyataan menggambarkan jalur yang sama dari lapisan berbeda, jadi tinjau keduanya bersama dalam konfigurasi yang berjalan.

Verifikasi dari host bernama, lalu sempitkan lagi

Buka sesi baru dari host manajemen bernama, bukan dari meja Anda, dan pastikan di ASA alamat sumber dan antarmuka mana yang digunakan koneksi. Periksa sesi aktif dan bagian SSH pada konfigurasi yang berjalan selama sesi terbuka, lalu tutup dan hapus izin sementara yang Anda tambahkan untuk pengujian. Jika sesi muncul tetapi jatuh tepat setelah login, masalah yang tersisa adalah otorisasi, bukan keterjangkauan. Catat antarmuka dan sumber di catatan perubahan agar orang berikutnya tidak mengulangi diagnosis.

Pertahankan konsol atau jalur pemulihan lain yang disetujui secara independen tersedia sepanjang perubahan. Setelah jalur privat berfungsi, pastikan sumber publik dan pengguna VPN yang tidak terkait tidak memperoleh akses yang sama, karena jalur manajemen yang berfungsi untuk semua adalah masalah yang berbeda dari yang Anda mulai.