NAT Azure VPN tidak menyelesaikan alamat VNet yang bertindih

Kedua-dua VNet menggunakan 10.40.1.0/24, terowong naik, dan tiada apa yang berfungsi. Menambah gateway VPN kedua tidak mengubahnya, begitu juga metrik laluan yang lebih rendah, kerana masalahnya bukan pemilihan laluan. Dua beban kerja yang menjawab alamat peribadi yang sama meninggalkan setiap paket dengan destinasi kabur dan laluan balik yang tidak dapat disahkan. Sebelum merancang sebarang terjemahan, ketahui jenis sambungan yang sebenarnya anda buat, kerana pilihan tunggal itu menentukan sama ada ciri NAT Azure tersedia sama sekali.

Apa yang sebenarnya dikatakan oleh gejala ini

Apabila hos dalam VNet A menghantar ke 10.40.1.10, jadual laluan hanya boleh menghalakannya ke suatu tempat. Jika VNet B juga mengandungi 10.40.1.10, alamat itu bukan destinasi yang laluan boleh bezakan; ia satu alamat dengan dua pemilik.

Gateway kedua yang biasa digunakan orang tidak membantu. Ia memberi terowong lain, bukan alamat lain, dan julat pendua bergerak tanpa berubah di dalam terowong. Ia juga menggandakan konfigurasi yang perlu anda kekalkan konsisten. Apa yang tidak dapat dilakukannya ialah menjadikan satu alamat bermaksud dua hos.

Menukar alamat awam rakan sebaya VPN juga tidak melakukan apa-apa. Alamat itu mengenal pasti titik hujung terowong, manakala perlanggaran berada dalam julat peribadi yang dibawa di dalamnya.

Jenis sambungan menentukan sama ada NAT tersedia

Azure VPN Gateway memang mempunyai keupayaan NAT, dan ia didokumenkan untuk sambungan IPsec antara premis berasaskan laluan pada SKU gateway tertentu. Dokumen yang sama mengecualikan sambungan VNet-to-VNet dan point-to-site, jadi ciri ini bukan kotak semak yang muncul pada setiap hubungan gateway.

VNet-to-VNet asli juga memerlukan julat VNet dan rangkaian setempat tidak bertindih sejak awal, yang selaras dengan pengecualian itu. Peering VNet juga bukan penyelesaian pertindihan atas sebab yang sama.

Ada alternatif yang disokong yang sering dikelirukan orang dengan jenis asli: modelkan VNet yang lain sebagai rangkaian setempat dan sambungkannya sebagai sambungan tapak-ke-tapak. Itu sumber dan reka bentuk yang berbeza, jadi anggap sambungan yang dilabel semula sebagai perubahan yang perlu disahkan, bukan sekadar penukaran nama.

Nombor semula, atau terjemah dengan sesuatu yang memiliki alias itu

Jika kedua-dua VNet milik anda, bandingkan penomboran semula yang dirancang dengan kos terjemahan yang berterusan. Penomboran semula menyentuh konfigurasi aplikasi, rekod DNS, peraturan keselamatan dan setiap sambungan sedia ada, tetapi meninggalkan rangkaian yang dibaca secara normal selepas itu. Lakukan satu subnet pada satu masa, dengan perubahan DNS paling akhir. Julat yang separuh dinomborkan semula lebih teruk daripada kedua-dua pilihan, kerana kedua-dua awalan kemudian kelihatan berwibawa kepada sesiapa yang membaca jadual seterusnya.

Di mana penomboran semula tidak praktikal, gunakan reka bentuk terjemahan dengan pemilik sebenar untuk alias itu. Pemanggil dalam VNet A mungkin mencapai 10.40.1.10 VNet B sebagai 10.140.1.10, tetapi alias itu memerlukan peranti yang menterjemah, laluan ke arahnya dan tingkah laku sepadan untuk balasan. Alamat yang ditambah hanya pada DNS bukan terjemahan.

Rekod kedua-dua julat dalam kedua-dua arah: apa yang didail pemanggil, apa yang dilihat destinasi sebagai sumber, dan pihak mana yang boleh memulakan. Peraturan NAT Azure sendiri menyertakan terjemahan terbalik untuk pemetaan SNAT mereka, jadi anda tidak menulis peraturan DNAT yang sepadan secara manual, tetapi kemudahan itu berhenti pada jenis sambungan yang disokong ciri ini.

Apa yang tidak akan berkesan

Laluan yang ditentukan pengguna atau metrik laluan tidak boleh mencipta pembezaan alamat yang hilang. Kedua-duanya beroperasi pada destinasi yang masih kabur, dan paket tiba di hop seterusnya yang diutamakan jadual.

Menambah julat pendua ke jadual laluan sebagai awalan yang lebih khusus hanya mengalihkan kekaburan satu langkah. Ia juga cenderung merosakkan arah bertentangan, di mana balasan kini mempunyai dua sumber yang munasabah.

Terima reka bentuk dengan trafik dalam kedua-dua arah

Buktikan reka bentuk dengan operasi dibenarkan yang baharu dari setiap pihak, bukan dengan status terowong. Terowong IPsec yang bersambung mengatakan rakan sebaya bersetuju tentang kriptografi; ia tidak mengatakan apa-apa tentang sama ada destinasi menjadi boleh dibezakan.

Kemudian jalankan laluan yang ditolak: alamat yang sepatutnya kekal tidak tercapai, dan perkhidmatan yang sepatutnya disekat oleh dasar. Jika kedua-duanya masih berjaya, terjemahan itu lebih luas daripada yang dimaksudkan reka bentuk.

Tutup dengan fakta yang menjelaskan persediaan itu kemudian: julat asal, julat yang dibentangkan, peranti yang menterjemah, dan arah yang boleh dimulakan setiap pihak. Jika mana-mana satu hilang, jurutera seterusnya mewarisi rangkaian di mana dua hos berkongsi nama dan tiada siapa ingat mengapa salah satu menjawab.