Identity NAT di ASA versus pengecualian NAT IOS untuk lalu lintas VPN

Sebuah cabang menjalankan PAT internet dan VPN site-to-site pada gateway Cisco yang sama, dan VPN berhenti bekerja begitu NAT ditambahkan. Alamat di dalam terowongan tidak lagi cocok dengan yang dilindungi crypto ACL, atau peer melihat alamat hasil terjemahan yang tidak memiliki rute. Cisco menyelesaikannya di dua tempat: ASA memilih aturan NAT yang memetakan alamat ke dirinya sendiri, sedangkan IOS menjaga aliran tetap di luar aturan penerjemahan melalui deny di ACL. Keduanya mempertahankan alamat asli, dan tidak satu pun merupakan jalan pintas pemrosesan NAT.

Catat aliran sebelum memilih aturan

Mulailah dengan menuliskan aliran yang ingin Anda lindungi: sumber LAN, tujuan jarak jauh, dan pasangan alamat persis yang dilindungi kebijakan IPsec. Lakukan sebelum menyunting aturan, karena tupel ini menunjukkan pengklasifikasi atau aturan NAT mana yang seharusnya cocok.

Lalu temukan aturan yang benar-benar cocok, bukan yang Anda maksudkan. Pada kedua platform NAT dievaluasi dalam urutan tertentu, dan aturan yang lebih awal bisa menang sebelum pengecualian Anda diperiksa. Pengecualian yang tampak benar tetapi kalah dari aturan lain tidak pernah menyerahkan paket yang diharapkan kepada kebijakan perlindungan. Gejalanya sama dengan pengecualian yang hilang, karena itu urutan aturan harus dibaca sebelum konfigurasi diubah.

Identity NAT di ASA adalah aturan, bukan jalan pintas

Pada ASA, identity NAT adalah aturan NAT yang alamat terjemahannya sama dengan alamat asli. Aturan ini dipilih seperti aturan lain dan tetap memasang entri penerjemahan, sehingga paket tidak melewati pemrosesan NAT. Yang berubah adalah alamat di jaringan tetap sama, dan itulah yang dibutuhkan kebijakan IPsec.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

Antarmuka aturan dan pengaturan route-lookup-nya harus sesuai dengan desain penerusan. Aturan yang memetakan alamat dengan benar tetapi diterapkan pada pasangan antarmuka yang salah tidak akan dipilih untuk aliran Anda. Route-lookup menentukan apakah paket terjemahan dirutekan atau tujuan asli digunakan, dan itu menentukan apakah lalu lintas balasan kembali melalui terowongan.

Akses manajemen ke ASA sendiri adalah kasus terpisah. Jika Anda memakai identity NAT untuk lalu lintas manajemen, persyaratan route-lookup yang bergantung pada rilis berlaku, dan pengecualian luas yang disalin dari contoh VPN tidak akan memperbaiki SSH.

Deny di ACL NAT IOS berarti tidak dipilih di sini

Pada IOS, NAT internet dikendalikan oleh daftar sumber, dan ACL itu adalah pengklasifikasi, bukan penyaring. Baris permit memilih lalu lintas untuk diterjemahkan; baris deny berarti paket tidak dipilih di sini. Deny itu bukan perintah membuang paket seperti deny pada ACL antarmuka.

Tidak dipilih di sini juga lebih sempit daripada tidak pernah diterjemahkan di mana pun. Aturan NAT lain, antarmuka lain, atau route-map masih dapat menerjemahkan aliran, jadi seluruh tabel NAT harus dibaca. Paket juga masih memerlukan rute, crypto ACL yang cocok, dan izin pada batas kendali akses yang sebenarnya.

Susunan IOS minimal menempatkan deny di atas permit dalam daftar yang sama dan mengarahkan aturan overload ke daftar itu. Crypto ACL kemudian melindungi pasangan yang sama dengan yang dikecualikan deny dari penerjemahan.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

Satu pertanyaan yang dapat diuji untuk kedua model

Kedua model menjawab pertanyaan yang sama: aturan mana yang cocok dengan aliran ini, dan alamat mana yang meninggalkan antarmuka? Tangkap pada antarmuka luar dan bandingkan alamat sumber sebelum dan sesudah gateway. Lalu periksa pandangan peer tentang terowongan, karena SA bisa aktif sementara aliran yang dilindungi diterjemahkan di tempat lain.

Pada ASA tampilkan nat detail dan tabel penerjemahan; pada IOS tampilkan ip nat translations dan penghitung ACL yang sesuai. Aturan yang tidak pernah bertambah tidak pernah dipilih, dan itu menunjuk pada urutan, antarmuka, atau arah, bukan konfigurasi crypto.

Di mana konfigurasi biasanya salah

Kegagalan yang umum bersifat mekanis. Deny berada di bawah permit dan tidak pernah cocok. Pengklasifikasi diterapkan pada arah yang salah, sehingga aliran balasan diterjemahkan. Aturan identity mencakup alamat yang benar tetapi pasangan antarmuka yang salah. Crypto ACL melindungi subnet yang tidak lagi cocok dengan yang disajikan aturan NAT.

Catat pasangan alamat asli dan yang disajikan di samping pemilik aturan, agar insinyur berikutnya melihat mengapa pengklasifikasi menolak penerjemahan sementara firewall mengizinkan aplikasi. Simpan itu di tiket perubahan, bukan catatan pribadi. Lalu jalankan ulang aliran setelah setiap perubahan NAT, karena urutan aturan adalah bagian dari konfigurasi meskipun teks aturannya tidak berubah. Terowongan yang naik bukan bukti alamat selamat; hanya paket yang ditangkap dan pandangan peer setelah dekapsulasi.