ASA VPN hairpin: merutekan dua tunnel melalui satu antarmuka

Seorang pengguna jarak jauh terhubung ke ASA, meminta host di balik cabang, dan ASA mengirim permintaan itu keluar melalui antarmuka yang sama tempat pengguna tadi masuk. Tidak ada bagian dari itu yang memerlukan port fisik kedua. Yang diperlukan adalah empat keputusan independen yang cenderung digabung orang menjadi satu: izin melakukan hairpin, tunnel yang melindungi alamat yang benar, kebijakan NAT yang mempertahankan sumber yang Anda janjikan, dan kebijakan akses yang mengesahkan layanan.

Satu paket, dua tunnel

Ikuti alurnya dan urutan operasi berhenti menjadi misterius. Paket tiba di dalam tunnel akses jarak jauh, didekripsi, dan menjadi paket IP biasa yang bersumber dari kumpulan klien. ASA lalu merutekannya, mencocokkannya dengan crypto ACL situs-ke-situs, mengenkripsinya lagi, dan mengirimkannya keluar melalui antarmuka luar menuju cabang.

Alamat di bawah ini hanya ilustrasi, tetapi bentuknya penting: sumbernya adalah kumpulan, bukan LAN internal ASA.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

Dua hal mengikuti. Klien memerlukan rute untuk prefiks cabang melalui koneksi akses jarak jannya, yang berarti split-tunnel atau daftar rute yang didorong harus memuatnya. Dan cabang harus tahu cara mengembalikan lalu lintas ke 10.77.0.20 atau ke alamat apa pun yang digantikan oleh desain NAT Anda.

Izin hairpin bersifat global

Perintah yang biasa dipakai orang adalah same-security-traffic permit intra-interface. Perintah ini mengizinkan lalu lintas masuk dan keluar pada antarmuka yang sama, yang persis dibutuhkan jalur ini. Perintah ini juga pengaturan global: mengaktifkannya mengubah perilaku aliran lain yang kebetulan melintasi antarmuka yang sama dua kali.

Itulah sebabnya perintah ini masuk ke catatan perubahan, bukan ke sesi debugging. Tanyakan apa lagi di perangkat yang sekarang dapat menempuh jalur antarmuka yang sama, dan apakah ada yang seharusnya. Di tepi yang sibuk dengan jaringan tamu atau tunnel mitra yang tumpang tindih, jawabannya bukan otomatis tidak. Tulis alasannya di samping pengaturan, karena insinyur berikutnya akan menemukan perintahnya dan bukan percakapannya.

Cakupan perlindungan dan NAT terpisah

Tunnel situs-ke-situs melindungi apa pun yang dipilih crypto ACL-nya. Jika ACL itu menyebut subnet internal ASA sebagai sumber, kumpulan akses jarak jauh tidak terlindungi dan paket akan ditolak atau dikirim tanpa enkripsi, tergantung perilaku platform terhadap lalu lintas yang tidak cocok. Tambahkan kumpulan itu ke aliran yang dilindungi ketika desain mempertahankan alamat kumpulan.

NAT kemudian memutuskan apakah alamat kumpulan bertahan. Identity NAT mempertahankannya, dan cabang melihat 10.77.0.20 sebagai sumber. Penerjemahan mengubah kontrak: cabang sekarang mengembalikan lalu lintas ke alamat hasil terjemahan, dan kebijakannya sendiri harus menerimanya. Urutan aturan menentukan apakah crypto ACL cocok sebelum atau sesudah terjemahan, jadi bacalah aliran efektif alih-alih mengasumsikan mana yang menang.

Jangan hapus aturan PAT internet umum hanya agar satu kasus transit berfungsi. Pengecualian yang terarah atau aturan identity yang disengaja lebih mudah dijelaskan dan dibatalkan daripada lubang pada kebijakan keluar.

Enkripsi bukan otorisasi

Tunnel yang berfungsi hanya membuktikan bahwa dua peer sepakat soal kunci dan selector. Itu tidak mengatakan apa pun tentang apakah pengguna ini boleh mencapai layanan tersebut. Filter VPN atau kebijakan grup yang terpasang pada koneksi akses jarak jauh tetap harus mengizinkan tujuan dan port cabang, dan ACL antarmuka pada jalur luar tetap berlaku.

Uji jawabannya pada kedua arah. Koneksi yang berhasil sementara layanan tetangga seharusnya gagal lebih informatif daripada satu ping yang berhasil, karena menunjukkan bahwa kebijakannya selektif dan bukan terbuka lebar. Jika uji yang seharusnya ditolak berhasil, tunnel bukan penyebabnya; kebijakanlah penyebabnya. Simpan kedua hasil di catatan perubahan agar orang berikutnya tahu perilaku mana yang dimaksudkan.

Hairpin atau antarmuka kedua

Transit hairpin menjaga desain tetap kecil dan berbiaya satu pengaturan global. Antarmuka terpisah, atau tunnel berbasis rute dengan antarmuka virtualnya sendiri, mengisolasi jalur transit dan memberi Anda kebijakan per antarmuka, dengan biaya pengalamatan dan satu crypto map atau profil lagi. Tidak ada yang lebih benar; keduanya gagal dengan cara berbeda.

Desain berbasis rute adalah susunan yang berbeda, bukan kotak centang pada konfigurasi yang sama. Jika Anda beralih ke sana, pembahasan crypto ACL berbasis kebijakan di atas berhenti berlaku dan tabel rute mulai melakukan pekerjaan pemilihan.

Verifikasi dari klien yang sebenarnya

Probe yang dijalankan dari ASA memiliki alamat sumber berbeda dan tidak akan menguji jalur dari kumpulan ke cabang. Gunakan packet-tracer untuk memeriksa lima-tuple, lalu buka koneksi sungguhan dari klien jarak jauh yang nyata, karena pelacak hanya mensimulasikan dan tidak menggantikan perutean dan kebijakan klien sendiri.

Setelah perubahan terencana, hubungkan ke layanan yang seharusnya berfungsi, lalu ke layanan yang seharusnya ditolak, lalu pastikan rute balik cabang. Contoh NAT hairpin VPN dari Cisco menjaga izin intra-interface, NAT, dan ACL terlihat terpisah, dan itulah model mental yang layak ditiru.