ASA hairpin: keluar ke internet atau kaki VPN situs-ke-situs?

Dua pengguna akses jarak jauh di belakang ASA yang sama dapat mengirim lalu lintas keluar dari antarmuka luar yang sama dan mendapat perlakuan yang sangat berbeda. Yang satu menuju situs web publik, sehingga paket memerlukan translasi sumber dan rute internet. Yang lain menuju server di belakang terowongan situs-ke-situs yang juga berakhir di antarmuka itu, sehingga paket memerlukan identitas, selektor terowongan yang cocok, dan jalur balik ke kumpulan klien. Izin antarmuka yang sama adalah prasyarat untuk keduanya dan solusi untuk keduanya bukan.

Dua kaki, satu antarmuka

Putuskan kaki mana yang Anda bangun sebelum mengetik aturan NAT, karena aturannya tidak dapat dipertukarkan. Kaki A adalah klien ke internet: alamat kumpulan masuk, alamat publik hasil translasi keluar, kembali melalui antarmuka yang sama. Kaki B adalah klien ke prefiks privat di sisi jauh rekan IPsec lain: alamat kumpulan dipertahankan, dienkripsi ulang, dan dikirim ke rekan yang harus tahu cara menjawab kumpulan.

Yang dibutuhkan keduanya lebih dulu adalah izin antarmuka yang sama. Tanpanya ASA menolak meneruskan paket keluar dari antarmuka tempat paket itu tiba, dan kegagalannya tampak seperti masalah perutean alih-alih masalah kebijakan:

same-security-traffic permit intra-interface

Satu baris itu mengizinkan susunan penerusan, sebagaimana dijelaskan referensi NAT ASA untuk jalur antarmuka yang sama. Baris itu tidak menambahkan rute klien, tidak mengizinkan sumber daya, tidak mentranslasikan alamat, dan tidak menegosiasikan selektor IPsec, jadi perkirakan menambahkan tiga atau empat hal lagi setelahnya dan jangan membaca penerimaannya sebagai kemajuan.

Kaki A: klien menginginkan internet

Untuk keluar ke internet, alamat kumpulan harus berhenti menjadi privat sebelum paket meninggalkan perangkat. Pada desain PAT biasa, aturan mentranslasikan kumpulan ke alamat antarmuka luar, dan status balik memulihkan aliran ke arah klien:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

Lalu pastikan klien benar-benar meminta ASA membawa lalu lintas itu. Pengecualian terowongan terpisah mengirim tujuan publik melalui koneksi ponsel itu sendiri, yang tidak pernah mencapai ASA, dan tidak ada aturan NAT yang memperbaiki paket yang tidak pernah dikirim. Bandingkan daftar terowongan terpisah kebijakan grup dengan tujuan yang Anda uji.

Sisa kaki itu biasa: rute default atau spesifik yang dapat dipakai keluar dari antarmuka luar, kebijakan akses yang mengizinkan aliran, dan DNS yang ditangani sesuai kebijakan resolver yang Anda pilih. Tambahkan route-lookup di sini untuk alasan yang sama seperti di bawah, karena antarmuka masuk dan keluar identik.

Kaki B: klien menginginkan situs privat

Kaki ini gagal di lebih banyak tempat, jadi tuliskan berurutan. Pertama rute klien: prefiks tujuan harus ada dalam daftar terowongan terpisah, atau klien tidak akan menempatkannya di terowongan. Kedua selektor terowongan: ACL kripto situs-ke-situs harus mencakup alamat kumpulan ke prefiks jauh, bukan hanya LAN lokal ke prefiks jauh. Ketiga identitas, agar alamat kumpulan tidak ditranslasikan ke PAT internet saat lewat.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

Sisi jauh adalah bagian yang orang lupa uji. Rekan memerlukan rute kembali ke kumpulan dan selektor yang mencakupnya, dan kebijakannya sendiri harus mengizinkan alamat sumber yang akan dilihatnya. Jika situs digunakan melalui tampilan hasil translasi, itu desain yang sah, tetapi kedua rekan, kedua selektor, dan kedua tabel rute harus sepakat soal alamat hasil translasi.

Periksa juga urutan aturan. Aturan PAT lebar di atas aturan identitas akan mentranslasikan pertukaran privat sebelum aturan identitas dievaluasi, dan gejalanya adalah terowongan situs tanpa SA yang cocok, bukan kesalahan NAT.

Uji yang memberi tahu Anda kaki mana yang Anda bangun

Gunakan evaluasi jalur ASA sendiri alih-alih membaca konfigurasi dan berharap. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed menampilkan keputusan NAT, rute, dan hasil ACL untuk satu aliran; ulangi dengan tujuan privat. Jika fase NAT menulis ulang aliran privat-ke-privat, Anda membangun kaki A untuk paket yang membutuhkan kaki B.

Dua perintah lagi menutup celahnya. show nat detail mencetak urutan aturan yang diikuti packet-tracer, dan show crypto ipsec sa menunjukkan apakah ada selektor untuk pasangan yang Anda harapkan. SA yang hilang adalah soal konfigurasi selektor atau rekan, bukan sesuatu yang bisa diperbaiki aturan NAT.

Verifikasi setiap kaki dengan lalu lintas yang dilayaninya

Terima kaki A dengan permintaan publik biasa dari klien, dan terima kaki B dengan permintaan ke sumber daya privat yang benar-benar ada. Lalu ulangi masing-masing dengan sumber daya yang ditolak, karena “diizinkan” dan “disetujui kebijakan akses” bukan bukti yang sama, dan ping yang berasal dari hub tidak melatih salah satu jalur klien.

Simpan dua catatan uji secara terpisah di tiket: alamat sumber, tujuan, aturan NAT yang cocok, dan hasil. Saat laporan berikutnya berkata “VPN rusak”, pasangan itu memberi tahu Anda dalam satu menit kaki mana yang mundur, dan jawabannya biasanya rute atau selektor, bukan baris antarmuka yang sama yang semua orang curigai lebih dulu.