Dua situs, satu subnet: buat tampilan alias untuk masing-masing

Dua situs pelanggan sama-sama menjalankan 192.168.50.0/24, dan seorang insinyur jarak jauh harus menjangkau printer di alamat yang sama di masing-masing. Tidak ada trik perutean yang menyelesaikan ambiguitas itu sendirian. Setiap situs memerlukan tampilan alamat yang berbeda, dan gateway harus memilih situs dari tampilan itu sebelum meneruskan apa pun.

Rencana ini punya empat bagian: prefiks alias, kedua arah terjemahan, kebijakan overlay dan nama. Setiap bagian harus selaras dengan yang lain.

Pilih satu prefiks alias per situs

Tetapkan kepada setiap situs prefiks alias utuh yang tidak dimiliki siapa pun lain di lingkungan. Rencana dua situs dapat memetakan 192.168.50.0/24 situs A ke 172.21.10.0/24 dan LAN identik situs B ke 172.21.20.0/24. Periksa kandidat terhadap setiap jaringan yang berpartisipasi, termasuk VPC cloud dan kumpulan VPN lain. Ruang alamat privat dipakai bersama oleh setiap organisasi, jadi sebuah rentang yang RFC 1918 tidak berarti rentang itu kosong di sini.

Terbitkan alias, bukan subnet asli, kepada pengguna jarak jauh. Rentang asli tetap menjadi fakta lokal.

Terjemahkan ke kedua arah

Terjemahkan ke kedua arah. Pemetaan tujuan menulis ulang alamat alias menjadi alamat asli di situs pemilik. Pemetaan sumber menulis ulang pemanggil jarak jauh menjadi alias yang dapat dibedakan situs lain.

Pemetaan statis satu-ke-satu bersifat deterministik, dan itu tidak membuat implementasinya tanpa status. Terjemahan balik dapat bergantung pada status koneksi, dan failover atau jalur asimetris dapat merusak rencana yang mengabaikannya. Dokumentasi platform menentukan mana yang berlaku.

Tahap tepat di mana kebijakan, selektor dan rute diterapkan berbeda antara IPsec berbasis kebijakan, terowongan berbasis rute dan produk lain. Rancang untuk yang Anda jalankan.

Bawa rencana melalui overlay

Di hub, tetapkan setiap prefiks alias ke jalur situs yang memilikinya dan izinkan hanya transit yang dibutuhkan tugas. Di mesh, setiap peer terkait memerlukan prefiks dan pengetahuan kebijakan yang sama. Menambah terowongan tidak memperbaiki pengalamatan ambigu dengan sendirinya.

Publikasi seluruh subnet lebih luas daripada publikasi satu layanan. Jika hanya beberapa mesin atau port yang diperlukan, jaga aturan akses lebih sempit daripada pemetaan.

Terjemahan header tidak menulis ulang muatan aplikasi. Pengalihan, alamat tertanam dalam berkas konfigurasi dan izin berbasis sumber semuanya masih dapat membawa alamat asli. Uji jalur aplikasi, bukan hanya ping. Balasan ICMP yang berfungsi membuktikan pemetaan itu ada dan tidak mengatakan apa pun tentang apakah aplikasi menerima alias tersebut.

Perbaiki nama yang dilihat setiap pemanggil

Beri nama pemeliharaan jawaban yang cocok dengan tampilan pemanggil. Jika insinyur jarak jauh menyelesaikan nama host, hasilnya harus alamat alias untuk situs itu, bukan rentang asli bersama.

Periksa tampilan DNS per situs sebelum jendela pemeliharaan pertama. Nama yang diselesaikan ke subnet asli mengirim pemanggil kembali ke ambiguitas yang seharusnya dihapus rencana.

Catat dan verifikasi per situs

Terima setiap situs secara terpisah dari pemanggil nyata dan konfirmasi mesin mana yang menjawab. Catat alamat asli, alias, gateway pemilik dan layanan yang diizinkan bersama-sama.

Inventaris itulah yang menjaga perbedaan ketika situs ketiga datang dengan LAN bawaan yang sama. Panduan IPsec NAT berbasis kebijakan mendokumentasikan satu model terjemahan konkret; itu bukan kontrak untuk setiap platform.