SSH ke ASA Jauh melalui VPN Tapak: Langkah demi Langkah

Anda arahkan klien SSH ke alamat dalaman ASA jauh dan sesi mati semasa menyambung. Firewall menjawab dari tapaknya sendiri, terowong muncul, namun tiada apa yang mendengar pada port 22. Dalam kebanyakan kes ini paket tidak pernah sampai ke penerimaan pengurusan, kerana laluan yang diuji tidak pernah direka sebagai laluan pengurusan. Ikut aliran di bawah mengikut urutan dan kegagalan berhenti berpindah.

Pilih alamat yang benar-benar anda uruskan

Tiga reka bentuk kelihatan serupa dan berkelakuan berbeza: mencapai alamat awam ASA yang menghadap VPN, mencapai antara muka dalaman melalui IPsec, dan mencapai antara muka pengurusan khusus. Catat alamat sumber pentadbir, alamat destinasi tepat dan TCP 22 sebelum menyentuh sebarang kebenaran. Semua yang berikutnya bergantung pada pasangan itu.

Terowong yang membawa dua VLAN pelayan mungkin tidak membawa langsung alamat antara muka firewall atau subnet pengurusan pentadbir. Semak senarai trafik menarik untuk dasar tapak-ke-tapak dan sahkan bahawa alamat ASA sendiri muncul sebagai destinasi, bukan hanya subnet yang melaluinya.

Oleh kerana destinasi ialah firewall itu sendiri, penerimaan pengurusan berasingan daripada peraturan untuk trafik yang dipanjangkan. ACL yang membenarkan klien mencapai pelayan di belakang ASA tidak menghidupkan pentadbiran SSH peranti secara berasingan, dan membaiki peraturan pemajuan tidak akan mengalihkan kegagalan ini.

management-access khusus antara muka

Perintah management-access memberitahu ASA supaya menerima sambungan pengurusan ke antara muka yang dinamakan apabila ia tiba melalui VPN. Ia tidak mencipta laluan, tidak menambah kebenaran SSH, dan tidak terpakai kepada setiap antara muka serentak. Jika antara muka destinasi bukan yang dinamakan, sambungan dibuang sebelum pengesahan.

Dua pengecualian menggigit di sini. Antara muka khusus pengurusan berada di luar mekanisme ini, dan panduan pengurusan ASA 9.20 menyatakan bahawa tindanan CiscoSSH lalai tidak menyokong SSH merentas antara muka melalui VPN manakala tindanan ASA SSH menyokongnya. Sahkan tindanan aktif pada keluaran yang digunakan sebelum menghabiskan masa pada laluan.

Empat pintu sebelum gesaan log masuk

Antara klien dan gesaan nama pengguna berdiri empat pintu bebas: padanan laluan dan terowong untuk pasangan pengurusan, ACL antara muka yang membenarkan TCP 22 ke alamat ASA, kebenaran ssh yang meliputi sumber pentadbir, dan pengesahan AAA untuk pengguna itu. Setiap satu boleh menjatuhkan paket tanpa memberitahu klien pintu mana yang tertutup.

Gunakan packet-tracer untuk melihat pintu mana yang gagal sebelum mengubah apa-apa: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Jejak menamakan ACL, peringkat NAT dan keputusan to-the-box, yang biasanya cukup untuk memisahkan masalah penghalaan daripada masalah penerimaan.

Tulis kebenaran sempit, bukan yang luas

Hadkan kebenaran kepada subnet pentadbiran yang diluluskan dan antara muka yang menerima trafik terowong: ssh 10.10.5.0 255.255.255.0 inside. Pasangkannya dengan kaedah pengesahan seperti aaa authentication ssh console LOCAL dan akaun tempatan bernama, bukannya membuka setiap sumber pada antara muka luar.

Pastikan ACL antara muka dan kebenaran ssh konsisten. Kebenaran untuk subnet yang disekat ACL masih gagal, dan ACL yang membenarkan subnet tanpa entri ssh yang sepadan gagal di pintu seterusnya. Kedua-dua pernyataan menerangkan laluan yang sama dari lapisan berbeza, jadi semak keduanya bersama dalam konfigurasi yang berjalan.

Sahkan dari hos bernama, kemudian sempitkan lagi

Buka sesi baharu dari hos pengurusan bernama dan bukan dari meja anda, dan sahkan pada ASA alamat sumber dan antara muka mana yang digunakan oleh sambungan. Semak sesi aktif dan bahagian SSH konfigurasi yang berjalan semasa sesi dibuka, kemudian tutup dan buang sebarang kebenaran sementara yang anda tambah untuk ujian. Jika sesi muncul tetapi jatuh sejurus selepas log masuk, masalah yang tinggal ialah kebenaran, bukan kebolehcapaian. Catat antara muka dan sumber dalam rekod perubahan supaya orang seterusnya tidak mengulangi diagnosis.

Kekalkan konsol atau laluan pemulihan lain yang diluluskan secara bebas tersedia sepanjang perubahan. Setelah laluan peribadi berfungsi, sahkan sumber awam dan pengguna VPN tidak berkaitan tidak mendapat akses yang sama, kerana laluan pengurusan yang berfungsi untuk semua ialah masalah berbeza daripada yang anda mulakan.