Azure VPN NAT çakışan VNet adreslerini çözmez

Her iki VNet de 10.40.1.0/24 kullanıyor, tüneller açılıyor ve hiçbir şey çalışmıyor. İkinci bir VPN ağ geçidi eklemek bunu değiştirmez, daha düşük bir yol ölçütü de değiştirmez, çünkü sorun yol seçimi değildir. Aynı özel adrese yanıt veren iki iş yükü her paketi belirsiz bir hedef ve doğrulanamayan bir dönüş yoluyla bırakır. Herhangi bir çeviri planlamadan önce gerçekte hangi bağlantı türünü oluşturduğunuzu öğrenin, çünkü bu tek seçim Azure'un NAT özelliğinin hiç mevcut olup olmadığını belirler.

Belirti size gerçekte ne söylüyor

VNet A'daki bir ana bilgisayar 10.40.1.10 adresine gönderdiğinde, yönlendirme tablosu onu yalnızca bir yere yönlendirebilir. VNet B de 10.40.1.10 içeriyorsa, bu adres yolun ayırt edebileceği bir hedef değildir; iki sahibi olan tek bir adrestir.

İnsanların genellikle dağıttığı ikinci ağ geçidi yardımcı olmaz. Size başka bir tünel verir, başka bir adres değil, ve yinelenen aralık tünelin içinde değişmeden yol alır. Ayrıca tutarlı tutmanız gereken yapılandırmayı ikiye katlar. Yapamadığı şey, bir adresin iki ana bilgisayar anlamına gelmesini sağlamaktır.

VPN eşlerinin genel adreslerini değiştirmek de bir şey yapmaz. O adresler tünelin uç noktalarını tanımlar, oysa çakışma içinde taşınan özel aralıktadır.

NAT'ın kullanılabilir olup olmadığına bağlantı türü karar verir

Azure VPN Gateway gerçekten bir NAT yeteneğine sahiptir ve bu, belirli ağ geçidi SKU'larında yol tabanlı IPsec siteler arası bağlantılar için belgelenmiştir. Aynı belge VNet'ten VNet'e ve noktadan siteye bağlantıları hariç tutar, bu nedenle özellik her ağ geçidi ilişkisinde görünen bir onay kutusu değildir.

Yerel VNet'ten VNet'e bağlantı ayrıca VNet ve yerel ağ aralıklarının başlangıçtan itibaren çakışmamasını gerektirir; bu da bu hariç tutmayla tutarlıdır. VNet eşlemesi de aynı nedenle çakışma için bir çözüm değildir.

İnsanların yerel türle karıştırdığı desteklenen bir alternatif vardır: diğer VNet'i yerel ağ olarak modelleyin ve siteler arası bir bağlantı olarak bağlayın. Bu farklı bir kaynak ve farklı bir tasarımdır, bu nedenle yeniden adlandırılmış bir bağlantıyı basit bir ad değişikliği değil, doğrulanması gereken bir değişiklik olarak ele alın.

Yeniden numaralandırın ya da diğer ada sahip bir şeyle çevirin

İki VNet de sizinse, planlanan yeniden numaralandırmayı çevirinin sürekli maliyetiyle karşılaştırın. Yeniden numaralandırma uygulama yapılandırmasına, DNS kayıtlarına, güvenlik kurallarına ve mevcut her bağlantıya dokunur, ama sonrasında normal okunan bir ağ bırakır. Bunu her seferinde bir alt ağ ile yapın, DNS değişikliği en sonda olsun. Yarısı yeniden numaralandırılmış bir aralık iki seçenekten de kötüdür, çünkü o zaman her iki önek de tabloyu bir sonraki okuyan için yetkili görünür.

Yeniden numaralandırmanın pratik olmadığı durumlarda, diğer ad için gerçek bir sahibi olan çevrilmiş bir tasarım kullanın. VNet A'daki çağıranlar VNet B'nin 10.40.1.10 adresine 10.140.1.10 olarak ulaşabilir, ancak bu diğer adın çeviren bir cihaza, ona doğru bir yola ve yanıt için eşleşen davranışa ihtiyacı vardır. Yalnızca DNS'e eklenen bir adres çeviri değildir.

Her iki aralığı iki yönde de kaydedin: çağıranın ne çevirdiğini, hedefin kaynak olarak ne gördüğünü ve hangi tarafın başlatabileceğini. Azure'un kendi NAT kuralları SNAT eşlemeleri için ters çeviriyi içerir, bu nedenle eşleşen bir DNAT kuralını elle yazmazsınız, ancak bu kolaylık özelliğin desteklediği bağlantı türlerinde sona erer.

Ne işe yaramayacak

Kullanıcı tanımlı bir yol veya yol ölçütü eksik adres ayrımını yaratamaz. İkisi de hâlâ belirsiz bir hedef üzerinde çalışır ve paket tablonun tercih ettiği bir sonraki atlama noktasına ulaşır.

Yinelenen aralığı daha belirgin bir önek olarak yol tablosuna eklemek belirsizliği yalnızca bir adım kaydırır. Ayrıca yanıtın artık iki olası kaynağı olduğu ters yönü bozma eğilimindedir.

Tasarımı iki yönlü trafikle kabul edin

Tasarımı tünel durumuyla değil, her taraftan yeni izin verilen bir işlemle kanıtlayın. Bağlı bir IPsec tüneli eşlerin şifreleme konusunda anlaştığını söyler; hedeflerin ayırt edilebilir hale gelip gelmediği hakkında hiçbir şey söylemez.

Ardından reddedilen yolları çalıştırın: erişilemez kalması gereken bir adres ve ilkenin engellemesi gereken bir hizmet. İkisi de hâlâ başarılıysa, çeviri tasarımın amaçladığından daha geniştir.

Kurulumu sonradan açıklayacak olgularla bitirin: özgün aralık, sunulan aralık, çeviren cihaz ve her tarafın başlatabileceği yön. Bunlardan biri eksikse, bir sonraki mühendis iki ana bilgisayarın aynı adı paylaştığı ve kimsenin birinin neden yanıt verdiğini hatırlamadığı bir ağı devralır.