Bisakah satu antarmuka WAN melayani VPN antar-situs dan akses jarak jauh?

Satu alamat publik bisa melayani terowongan cabang dan kumpulan pengguna bergerak pada saat yang sama. Tetapi alamat itu tidak bisa melayani satu aturan penerimaan bersama. Peer cabang dan pengguna bergerak berbeda dalam hal siapa yang mereka klaim, bagaimana bukti itu diperiksa, alamat apa yang mereka terima, dan prefiks mana yang boleh menjawab mereka. Begitu Anda memperlakukan alamat luar sebagai detail transportasi dan bukan identitas, desainnya menjadi jauh lebih sederhana.

Uji kewajaran cepat: coba tulis kedua catatan penerimaan sebelum Anda menyentuh router. Jika satu kondisi pencocokan harus mencakup keduanya, kebijakannya sudah ambigu, dan gejala pertamanya akan tampak seperti kesalahan routing atau firewall padahal sebenarnya kesalahan identitas.

Dua catatan sebelum konfigurasi apa pun

Catatan cabang singkat dan stabil. Catatan itu mendaftar alamat peer atau nama sertifikat, kunci yang dibagikan sebelumnya atau trustpoint sertifikat, subnet yang dilindungi di kedua sisi, antarmuka terowongan, dan rute statis yang mengirim lalu lintas menuju cabang ke terowongan itu. Setiap bidang menyangkut satu peer yang dikenal dan satu set prefiks tetap.

Catatan bergerak lebih luas dan lebih personal. Catatan itu mendaftar protokol dan porta klien, bagaimana pengguna atau perangkat melakukan autentikasi, kumpulan alamat yang diberikan saat terhubung, sumber daya yang boleh dijangkau kumpulan itu, prefiks tunnel terbelah, server DNS yang didorong ke klien, dan faktor kedua apa pun. Setiap bidang menjawab pertanyaan tentang jumlah pengguna yang tidak diketahui, bukan tentang satu gateway.

Perbedaan granularitas itulah seluruh alasan kedua peran itu menyimpang. Profil cabang bisa tepercaya memakai satu kunci karena kunci itu milik satu perangkat di satu lokasi. Profil bergerak yang memercayai satu kunci grup untuk semua orang meruntuhkan akuntabilitas per pengguna, dan itu biasanya baru ditemukan belakangan, saat tinjauan insiden dan bukan saat peluncuran.

Di mana pencocokan peer dan autentikasi menyimpang

Di IOS XE profil IKEv2 membawa parameter yang tidak dapat dinegosiasikan dan kondisi yang dipakai untuk memilih peer. Artinya sisi cabang dan sisi bergerak masing-masing perlu profil sendiri, bahkan ketika keduanya berakhir di antarmuka yang sama dan bahkan ketika keduanya berbagi satu PKI kripto. Cisco mendokumentasikan peran profil, autentikasi, dan pencocokan dalam panduan konfigurasi IKEv2 untuk IOS XE 17.

Profil cabang biasanya mencocokkan identitas sempit: alamat jauh, FQDN, atau subjek sertifikat. Sesuatu seperti match identity remote address 198.51.100.10 255.255.255.255 memaku satu peer, dan authentication remote pre-share dengan kunci yang disimpan per situs sudah cukup. Jaga pencocokan sespesifik yang diizinkan inventaris peer, karena wildcard yang tumpang tindih lebih tinggi dalam urutan pemilihan bisa menarik lalu lintas cabang ke profil yang salah.

Profil bergerak tidak bisa memaku alamat, jadi profil itu mencocokkan grup, key-id, atau bidang sertifikat, lalu menyerahkan pemeriksaan pengguna yang sebenarnya ke AAA atau ke kebijakan otorisasi yang dilekatkan pada profil. Pemisahan itu penting: autentikasi peer menjawab apakah klien boleh membangun terowongan, dan otorisasi per pengguna menjawab kumpulan serta sumber daya mana yang didapatnya. Memakai kunci cabang sebagai login universal membuang jawaban kedua.

Penerusan dan penerjemahan perlu pemisahan yang sama

Penerimaan dan keterjangkauan adalah masalah terpisah. Pertukaran IKE dan IPsec yang berhasil membuktikan kedua pihak sepakat soal kunci; itu tidak membuat rute ke kumpulan alamat yang diterima klien. Karena itu kumpulan akses jarak jauh perlu jalur balik, entah rute statis yang menunjuk antarmuka terowongan atau protokol routing yang menyuntikkan ringkasan kumpulan. Prefiks cabang biasanya datang lewat proses routing yang sama yang melayani sisa lokasi.

Penerjemahan adalah tempat kedua peran paling sering bertabrakan. Lalu lintas antar-situs yang harus mempertahankan alamat privatnya perlu pengecualian NAT yang dibatasi pada dua prefiks itu, di kedua arah. Klien bergerak biasanya juga perlu pengecualian untuk lalu lintasnya di dalam terowongan, tetapi lalu lintasnya ke internet entah melewati terowongan lewat tunnel terbelah atau keluar di hub setelah NAT. Mengecualikan semua yang datang dari terowongan adalah kesalahan klasik, karena itu juga menghapus penerjemahan dari lalu lintas yang benar-benar membutuhkannya.

Jaga aturan pengecualian seketat aturan penerimaan. Jika ringkasan kumpulan dan prefiks cabang tumpang tindih, jalur balik menjadi ambigu jauh sebelum ada paket yang dibuang, dan gejalanya muncul sebagai satu situs yang kadang kehilangan subnet, bukan sebagai kegagalan terowongan yang bersih.

Kasus penerimaan yang membongkar kebijakan bersilangan

Bangun empat kasus dan jalankan berurutan. Sebuah host di cabang mencapai sumber daya khusus cabang. Klien bergerak mencapai sumber daya yang sama lewat alamat kumpulannya. Klien bergerak mencoba prefiks cabang yang tidak boleh disentuhnya. Peer cabang mencoba memperoleh alamat dari kumpulan akses jarak jauh. Dua yang terakhir itulah yang menangkap profil bersama, karena keduanya gagal diam-diam dalam pemantauan normal.

Lalu pastikan bidang data, bukan konfigurasi. show crypto ikev2 sa dan show crypto ipsec sa memberi tahu profil dan selektor mana yang membawa setiap aliran, sementara show ip nat translations dan penghitung terowongan menunjukkan apakah jalur balik dan pengecualian benar-benar cocok. Tracer atau tangkapan paket di antarmuka terowongan menutup lingkaran.

Tulis identitas yang teramati, alamat kumpulan, dan kebijakan yang dipilih di samping setiap hasil. Putaran selesai ketika setiap kasus memetakan ke tepat satu catatan, dan tidak ada kasus yang perlu pengecualian sementara untuk lulus.