Laluan lalai tunneled Cisco ASA: bila ia benar-benar terpakai

Pengguna akses jauh tidak dapat mencapai apa-apa di sebalik ASA sedangkan pelayan yang sama menjawab ping dari LAN dalaman. Terowong naik, klien mendapat alamat daripada pool, dan paket itu masih keluar melalui laluan lalai internet atau hilang. Corak ini biasanya bermaksud trafik yang dinyahsulit tidak menemui laluan sendiri dan jatuh ke laluan lalai biasa. Pembaikannya bukan satu lagi peraturan NAT; pembaikannya ialah laluan lalai tunneled.

Mulakan dengan simptom, bukan konfigurasi

Perhatikan ke mana paket itu pergi, bukan ke mana anda menjangkakan ia pergi. Tangkapan pada antara muka luar semasa sesi yang gagal menunjukkan paket yang dinyahsulit menuju ke gateway ISP dengan alamat pool masih utuh, atau tidak menunjukkan apa-apa kerana carian gagal. Sama ada cara, terowong bukan masalahnya.

Terowong kelihatan sihat dalam show vpn-sessiondb, dan itulah sebabnya orang terus menyahpepijat IKE.

Yang membezakannya daripada kejatuhan ACL ialah arah. Kejatuhan ACL direkod dan dikira, manakala laluan yang hilang menghasilkan kegagalan carian tanpa entri yang sepadan. Jalankan show route untuk destinasi klien dan baca apa yang sebenarnya dipilih oleh ASA, termasuk sama ada laluan lalai dipilih dan yang mana satu.

Bagaimana carian tunneled berbeza

Panduan penghalaan statik ASA 9.23 daripada Cisco mendokumenkan laluan lalai berasingan untuk trafik VPN yang dinyahsulit yang tiada laluan statik atau laluan yang dipelajari. Kata kunci tunneled menandakan laluan itu, jadi paket yang dinyahsulit boleh jatuh ke hop seterusnya yang berbeza daripada yang digunakan ASA untuk pengangkutannya sendiri. Laluan yang lebih spesifik masih menang, itulah sebabnya klien boleh mencapai 10.0.0.0/8 melalui gateway dalaman dan kehilangan semua yang lain.

Susun atur minimum menyimpan dua laluan lalai dengan hop seterusnya yang berbeza. Satu membawa trafik ASA sendiri, satu lagi membawa trafik yang dinyahsulit yang tiada laluan lebih baik. Kedua-dua hop seterusnya masih perlu boleh dicapai daripada antara muka yang anda pasangkan padanya.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

Jika kedua-dua laluan lalai menunjuk ke hop seterusnya yang sama, kata kunci itu tidak mengubah apa-apa dan simptom tidak akan berganjak.

Sekatan yang menentukan sama ada ia berfungsi

Panduan yang sama hanya membenarkan satu laluan lalai tunneled dan menyatakan ECMP tidak disokong untuknya, jadi anda tidak boleh berkongsi beban pada laluan itu. Ia juga menyenaraikan sekatan yang melibatkan penjejakan laluan, pengesahan laluan balik, serta beberapa aliran pemeriksaan dan pengurusan. Bacalah semuanya berbanding keluaran yang dipasang sebelum anda mereka bentuk mengelilingi ciri ini. Reka bentuk yang mengabaikannya biasanya gagal pada satu tempat tertentu, bukan di semua tempat, dan itulah sebabnya simptom kelihatan berselang-seli.

Pengesahan laluan balik ialah yang paling menggigit dalam reka bentuk asimetri. Jika balasan tiba melalui antara muka yang berbeza daripada yang dijangka ASA, paket itu digugurkan sebelum penghalaan menjadi penting. Betulkan topologi atau laluan balik dan bukannya mematikan pengesahan untuk memaksa hop seterusnya.

Penjejakan laluan ialah perangkap berasingan: objek yang dijejaki biasanya melindungi laluan lalai biasa, bukan laluan tunneled.

Apa yang kata kunci tidak lakukan

Ia tidak memilih alamat sumber yang digunakan ASA untuk membina IKE. Titik akhir terowong luar mengikut pemilihan antara muka dan sumber platform itu sendiri, dan laluan lalai tunneled tidak memainkan peranan dalam keputusan itu. Menukarnya tidak akan membaiki phase 1 yang bermula daripada alamat yang salah.

Ia juga tidak menjadikan hop seterusnya sebagai proksi. Jika destinasi menjangka pertukaran HTTP CONNECT, menghantar paket IP mentah ke hos proksi hanya memberi anda hos yang tidak menghalakan paket itu. Konfigurasikan mekanisme proksi yang disokong oleh klien sebaliknya.

Dan ia tidak mencipta penghantaran ke hilir. Gateway yang anda tuju masih memerlukan laluan balik ke pool VPN, serta terjemahan sumber di tempat reka bentuk memerlukannya.

Sahkan laluan dari hujung ke hujung

Selepas laluan dipasang, semak empat perkara mengikut urutan: show route untuk destinasi yang diperlukan oleh pool, tangkapan pada antara muka menuju hop seterusnya yang baharu, tangkapan pada gateway itu sendiri, dan laluan balik dari gateway itu ke alamat pool. Dua yang pertama membuktikan ASA memilih laluan itu, dan dua yang terakhir membuktikan ada pihak yang menjawab di situ.

Jika gateway menjawab tetapi klien tidak pernah melihat balasan, lihat terjemahan sumber dan laluan balasan sebelum menyentuh jadual penghalaan lagi.

Catat keluaran yang anda sahkan, kerana senarai sekatan bergantung pada versi dan reka bentuk yang berfungsi pada satu train mungkin memerlukan laluan berbeza pada train lain. Nota itu hidup lebih lama daripada coretan konfigurasi.