NAT Azure VPN tidak memperbaiki alamat VNet yang tumpang tindih

Kedua VNet memakai 10.40.1.0/24, terowongannya naik, dan tidak ada yang berfungsi. Menambahkan gateway VPN kedua tidak mengubahnya, begitu pula metrik rute yang lebih rendah, karena masalahnya bukan pemilihan jalur. Dua beban kerja yang menjawab alamat privat yang sama membuat setiap paket memiliki tujuan yang ambigu dan jalur balik yang tidak dapat diverifikasi. Sebelum merencanakan terjemahan apa pun, cari tahu jenis koneksi apa yang sebenarnya Anda buat, karena pilihan tunggal itu menentukan apakah fitur NAT Azure tersedia sama sekali.

Apa yang sebenarnya dikatakan gejala ini

Ketika host di VNet A mengirim ke 10.40.1.10, tabel rute hanya bisa mengarahkannya ke suatu tempat. Jika VNet B juga memuat 10.40.1.10, alamat itu bukan tujuan yang bisa dibedakan oleh jalur; itu satu alamat dengan dua pemilik.

Gateway kedua yang biasanya dipasang orang tidak membantu. Gateway itu memberi terowongan lain, bukan alamat lain, dan rentang duplikatnya berjalan tanpa perubahan di dalam terowongan. Gateway itu juga menggandakan konfigurasi yang harus Anda jaga tetap konsisten. Yang tidak bisa dilakukannya adalah membuat satu alamat berarti dua host.

Mengubah alamat publik rekan VPN juga tidak melakukan apa pun. Alamat-alamat itu mengidentifikasi titik ujung terowongan, sedangkan tabrakannya ada di rentang privat yang dibawa di dalamnya.

Jenis koneksi menentukan apakah NAT tersedia

Azure VPN Gateway memang memiliki kemampuan NAT, dan itu didokumentasikan untuk koneksi IPsec lintas lokasi berbasis rute pada SKU gateway tertentu. Dokumentasi yang sama mengecualikan koneksi VNet-to-VNet dan point-to-site, jadi fitur ini bukan kotak centang yang muncul pada setiap hubungan gateway.

VNet-to-VNet asli juga mengharuskan rentang VNet dan jaringan lokal tidak tumpang tindih sejak awal, yang sejalan dengan pengecualian itu. Peering VNet juga bukan solusi tumpang tindih karena alasan yang sama.

Ada alternatif yang didukung yang sering dikacaukan dengan jenis asli: modelkan VNet lain sebagai jaringan lokal lalu hubungkan sebagai koneksi site-to-site. Itu sumber daya yang berbeda dan desain yang berbeda, jadi perlakukan koneksi yang diganti label sebagai perubahan yang harus divalidasi, bukan sekadar penggantian nama.

Lakukan penomoran ulang, atau terjemahkan dengan sesuatu yang memiliki alias

Jika kedua VNet milik Anda, bandingkan penomoran ulang yang direncanakan dengan biaya terjemahan yang berkelanjutan. Penomoran ulang menyentuh konfigurasi aplikasi, catatan DNS, aturan keamanan, dan setiap koneksi yang ada, tetapi meninggalkan jaringan yang terbaca normal setelahnya. Lakukan satu subnet pada satu waktu, dengan perubahan DNS paling akhir. Rentang yang baru separuh dinomori ulang lebih buruk daripada kedua opsi, karena kedua prefiks lalu tampak berwenang bagi siapa pun yang membaca tabel berikutnya.

Bila penomoran ulang tidak praktis, gunakan desain terjemahan dengan pemilik nyata untuk alias tersebut. Pemanggil di VNet A mungkin menjangkau 10.40.1.10 milik VNet B sebagai 10.140.1.10, tetapi alias itu memerlukan perangkat yang menerjemahkan, rute menuju perangkat itu, dan perilaku yang cocok untuk balasannya. Alamat yang hanya ditambahkan ke DNS bukan terjemahan.

Catat kedua rentang di kedua arah: apa yang dipanggil pemanggil, apa yang dilihat tujuan sebagai sumber, dan sisi mana yang boleh memulai. Aturan NAT Azure sendiri menyertakan terjemahan balik untuk pemetaan SNAT mereka, jadi Anda tidak menulis aturan DNAT yang cocok secara manual, tetapi kemudahan itu berhenti pada jenis koneksi yang didukung fitur tersebut.

Apa yang tidak akan berhasil

Rute yang ditentukan pengguna atau metrik rute tidak dapat menciptakan pembedaan alamat yang hilang. Keduanya bekerja pada tujuan yang masih ambigu, dan paket tiba di hop berikutnya yang disukai tabel.

Menambahkan rentang duplikat ke tabel rute sebagai prefiks yang lebih spesifik hanya menggeser ambiguitas satu langkah. Itu juga cenderung merusak arah sebaliknya, di mana balasannya kini memiliki dua sumber yang masuk akal.

Terima desainnya dengan lalu lintas di kedua arah

Buktikan desainnya dengan operasi yang diizinkan yang baru dari setiap sisi, bukan dengan status terowongan. Terowongan IPsec yang terhubung mengatakan para rekan sepakat soal kriptografi; itu tidak mengatakan apa pun tentang apakah tujuannya menjadi dapat dibedakan.

Lalu jalankan jalur yang ditolak: alamat yang seharusnya tetap tak terjangkau, dan layanan yang seharusnya diblokir kebijakan. Jika keduanya masih berhasil, terjemahannya lebih luas daripada yang dimaksudkan desain.

Tutup dengan fakta yang menjelaskan penyetelan itu nanti: rentang asli, rentang yang disajikan, perangkat yang menerjemahkan, dan arah yang boleh dimulai setiap sisi. Jika salah satunya hilang, insinyur berikutnya mewarisi jaringan di mana dua host berbagi nama dan tidak ada yang ingat mengapa salah satunya menjawab.