Azure UDR'den VPN ağ geçidine: tek hedef, tüm çıkış değil

Bir dış önek için kullanıcı tanımlı bir yol eklersiniz, onu VPN ağ geçidine yönlendirirsiniz ve trafik yine de Azure'un internet yolundan çıkar. Ya da doğru çıkar ve yanıt asla geri dönmez. Her iki sonuç da aynı hatadan gelir: Azure'daki sonraki atlamayı tasarımın tamamı saymak. Yol tablosu yalnızca bir paketin Azure içinde hangi çıkışı alacağına karar verir. Tünelden sonra ona ne olduğu ve yanıtın nasıl döndüğü, inşa etmeniz gereken ikinci yarıdır.

Sonraki atlama bir ağ geçididir, cihazın IP'si değil

Bir UDR, eşleşen öneki bir sonraki atlama türüne gönderir ve VirtualNetworkGateway bir türdür, adres değil. İnsanlar ağ geçidinin özel IP'sini bir VirtualAppliance yoluna yapıştırır ve sonra neden hiçbir şeyin eşleşmediğini merak eder, çünkü bu tür bunun yerine bir NIC veya iç yük dengeleyici bekler. Microsoft'un yönlendirme belgeleri de ağ geçidi sonraki atlamasını ağ geçidi VPN ağ geçidi olan bir sanal ağla sınırlar. ExpressRoute, Route Server ve bir Virtual WAN hub'ı bu seçenekle adreslenmez.

Yolu yazmadan önce sanal ağın gerçekte neye sahip olduğunu kontrol edin. Tasarım bir hub üzerinden yönlendiriyorsa, yol düzenlediğiniz spoke'un değil hub'ın yönlendirme sahibinindir.

Herhangi bir şeyi değiştirmeden önce geçerli yolu okuyun

Azure sistem yollarını, BGP ile öğrenilen önekleri ve UDR'ları her NIC için geçerli bir yol tablosunda birleştirir ve en uzun eşleşen önek nereden geldiğine bakılmaksızın kazanır. Aynı önek için UDR, BGP yolunu yener. Bu sıralama, önceki bir deneyden kalan eski bir UDR'nin tünelden yeni öğrendiğiniz öneki sessizce geçersiz kılabilmesinin nedenidir.

Önce geçerli tabloya bakın, sonra yol ekliyor musunuz yoksa değiştiriyor musunuz karar verin:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Yalnızca öneki değil kaynak sütununu da okuyun. Doğru öneke ve yanlış kaynağa sahip bir yol, hangi nesneyi düzenleyeceğinizi söyler ve birinciye kaybeden ikinci bir yol eklemekten kurtarır.

Yolu gerçek önek ve alt ağa göre yazın

Forum gönderisinden kopyalanmış bir genel aralık yerine gerçekten ulaştığınız hizmetten alınan gerçek hedef önekini kullanın. Tüm çıkışı taşıyan varsayılan bir yolu düşünmeden önce onaylanmış tek bir hizmetle başlayın. Ardından yol tablosunu iş yükünün alt ağına bağlayın. Ağ geçidi alt ağının kendi gereksinimleri vardır ve tablonuzu oraya bağlamak iş yükünü yönlendirmek yerine ağ geçidini bozar.

Yolu oluşturun, sonra tabloyu iş yükünü barındıran alt ağa bağlayın:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Yayma da önemlidir. Bu tabloda BGP yayma açıkken, öğrenilen önekler sizin yazdıklarınızın yanında görünür ve daha belirgin bir öğrenilmiş önek daha geniş bir UDR'yi yenebilir. Yaymayı yalnızca UDR kümesinin o alt ağ için yetkili olmasını istediğinizde kapatın.

Şirket içi yarıyı tamamlayın, yoksa akış orada ölür

Şirket içi ağ geçidi Azure kaynağını kabul etmeli, hedefe iletmeli ve uygulamaya izin vermelidir. Devam yolu bir internet çıkışı ya da başka bir özel atlama olabilir, ancak bu karar Azure yol tablosuna değil plana aittir. Olağan başarısızlık dönüş yoludur. Bir internet hedefi özel bir Azure kaynağını size geri yönlendirmez, bu yüzden yanıt kendi varsayılan ağ geçidine gider ve ölür ya da hiç çıkmaz.

İki tasarım bunu çözer ve birbirlerinin yerine kullanılamazlar. Kaynağı çıkışta çevirin, böylece hedef şirket içi ağın sahip olduğu bir genel adrese yanıt verir. Ya da kaynağı koruyun ve yanıtların tünelden dönmesi için yönlendirilmiş bir dönüş ilişkisi kurun. Birini seçin ve uygulamanın hangi adresi göreceğini yazın.

Seçiciler ve izin listeleri tüm bunlardan ayrıdır. Azure sonraki atlamasını seçmek VPN trafik seçicilerini genişletmez ve bir dış hizmetin kaynak izin listesini değiştirmez.

Hedefin gözlemlediği kaynakla doğrulayın

İsteği başka bir alt ağdaki atlama ana bilgisayarından değil gerçek iş yükünden gönderin, sonra hedefin gözlemlediği kaynak adresini okuyun. Bu tek değer, iki dönüş tasarımından hangisinin yürürlükte olduğunu söyler. Ardından yanıt yolunu kontrol edin ve VM'ye giden olağan yönetim trafiğinin hâlâ çalıştığını doğrulayın, çünkü yanlışlıkla eklenen varsayılan bir yol, uygulama bozulmadan çok önce bozuk bir SSH oturumu olarak görünür.

Seçilmiş bir önek üzerinden geçiş, zorunlu tünellemeden çok daha dar bir değişikliktir. Dar tutun ve geri alma tek bir yolu silmektir.