Rute default tunneled Cisco ASA: kapan sebenarnya berlaku

Pengguna akses jarak jauh tidak dapat menjangkau apa pun di balik ASA, padahal server yang sama menjawab ping dari LAN internal. Tunnel terbentuk, klien mendapat alamat dari pool, tetapi paket tetap keluar lewat default internet atau hilang. Pola ini biasanya berarti lalu lintas yang didekripsi tidak menemukan rute sendiri dan jatuh ke default biasa. Perbaikannya bukan aturan NAT lain; perbaikannya adalah default tunneled.

Mulai dari gejala, bukan dari konfigurasi

Perhatikan ke mana paket pergi, bukan ke mana Anda mengharapkannya pergi. Capture pada antarmuka luar selama sesi yang gagal menunjukkan paket yang didekripsi menuju gateway ISP dengan alamat pool masih utuh, atau tidak menunjukkan apa pun karena pencarian gagal. Bagaimanapun, tunnel bukan masalahnya.

Tunnel tampak sehat di show vpn-sessiondb, dan itulah tepatnya alasan orang terus men-debug IKE.

Yang membedakannya dari drop ACL adalah arah. Drop ACL dicatat dan dihitung, sedangkan rute yang hilang menghasilkan kegagalan pencarian tanpa entri yang cocok. Jalankan show route untuk tujuan klien dan baca apa yang sebenarnya dipilih ASA, termasuk apakah sebuah default dipilih dan yang mana.

Bagaimana pencarian tunneled berbeda

Panduan perutean statis ASA 9.23 dari Cisco mendokumentasikan default terpisah untuk lalu lintas VPN yang didekripsi yang tidak memiliki rute statis atau rute yang dipelajari. Kata kunci tunneled menandai rute tersebut, sehingga paket yang didekripsi dapat jatuh ke hop berikutnya yang berbeda dari yang dipakai ASA untuk transportnya sendiri. Rute yang lebih spesifik tetap menang, itulah sebabnya klien dapat menjangkau 10.0.0.0/8 melalui gateway internal dan kehilangan semua yang lain.

Tata letak minimal mempertahankan dua default dengan hop berikutnya yang berbeda. Satu membawa lalu lintas ASA sendiri, satu membawa lalu lintas yang didekripsi yang tidak punya rute lebih baik. Kedua hop berikutnya tetap harus dapat dijangkau dari antarmuka tempat Anda memasangnya.

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 default menunjuk ke hop berikutnya yang sama, kata kunci tidak mengubah apa pun dan gejalanya tidak akan bergeser.

Batasan yang menentukan apakah ini berhasil

Panduan yang sama hanya mengizinkan satu default tunneled dan menyatakan bahwa ECMP tidak didukung untuk itu, jadi Anda tidak dapat berbagi beban pada jalur tersebut. Panduan itu juga mencantumkan batasan seputar pelacakan rute, verifikasi jalur balik, serta beberapa alur inspeksi dan manajemen. Bacalah terhadap rilis yang Anda pasang sebelum merancang di sekitar fitur ini. Rancangan yang mengabaikannya biasanya gagal di satu titik tertentu, bukan di mana-mana, itulah sebabnya gejalanya tampak intermiten.

Verifikasi jalur balik adalah yang paling menggigit pada rancangan asimetris. Jika balasan tiba melalui antarmuka yang berbeda dari yang diharapkan ASA, paket dijatuhkan sebelum perutean menjadi relevan. Perbaiki topologi atau jalur balik, bukan menonaktifkan verifikasi untuk memaksakan hop berikutnya.

Pelacakan rute adalah jebakan tersendiri: objek yang dilacak biasanya menjaga default biasa, bukan yang tunneled.

Apa yang tidak dilakukan kata kunci ini

Kata kunci ini tidak memilih alamat sumber yang dipakai ASA untuk membangun IKE. Endpoint tunnel luar mengikuti pemilihan antarmuka dan sumber milik platform itu sendiri, dan default tunneled tidak punya bagian dalam keputusan itu. Mengubahnya tidak akan memperbaiki phase 1 yang berasal dari alamat yang salah.

Kata kunci ini juga tidak mengubah hop berikutnya menjadi proxy. Jika tujuan mengharapkan pertukaran HTTP CONNECT, mengirim paket IP mentah ke host proxy hanya memberi Anda host yang tidak merutekannya. Konfigurasikan mekanisme proxy yang didukung klien sebagai gantinya.

Dan kata kunci ini tidak membuat penerusan hilir. Gateway yang Anda tuju tetap memerlukan rute balik ke pool VPN, ditambah terjemahan sumber di tempat rancangan memintanya.

Verifikasi jalur dari ujung ke ujung

Setelah rute terpasang, periksa empat hal secara berurutan: show route untuk tujuan yang dibutuhkan pool, capture pada antarmuka menuju hop berikutnya yang baru, capture pada gateway itu sendiri, dan jalur balik dari gateway tersebut ke alamat pool. Dua yang pertama membuktikan ASA memilih jalur itu, dan dua yang terakhir membuktikan ada yang menjawab di sana.

Jika gateway menjawab tetapi klien tidak pernah melihat balasan, periksa terjemahan sumber dan rute balasan sebelum menyentuh tabel rute lagi.

Catat rilis tempat Anda memvalidasi, karena daftar batasan spesifik per versi dan rancangan yang berfungsi pada satu train mungkin memerlukan jalur berbeda pada train lain. Catatan itu bertahan lebih lama daripada cuplikan konfigurasi.