NVA olmadan ExpressRoute üzerinden Azure özel IP VPN

Mit, ExpressRoute özel peering üzerinden trafiği şifrelemenin bir sanal ağ cihazı gerektirdiğidir. Gerektirmez. Azure, tünel uç noktası devre üzerinden taşınan özel bir RFC1918 adresi olan Site-to-Site VPN Gateway'i destekler ve cihaz yapısal değil isteğe bağlıdır. Cihaz mitinin gizlediği şey, gerçekten can yakan kısımdır: özel uç noktayı iki nesne yerine bir nesnede etkinleştirmek ve doğrudan bir peering rotasının şifrelenmiş yolu sessizce yenmesine izin vermek.

Mit nereden geldi

İddianın saygın bir kökeni var. Yıllarca özel peering üzerinden IPsec için pratik tarif bir NVA'ydı, çünkü yönetilen ağ geçidi yalnızca genel uç noktaları sunuyordu. Bu değişti ve değişiklikten önce yazılmış yanıtlar hâlâ tarihi kimsenin kontrol etmediği başlıklarda alıntılanıyor. Düzeltme dar: özel adresli bir VPN ağ geçidi var ve bu, uç noktayı değiştirir, çevresindeki yönlendirme mantığını değil.

Bunların hiçbiri NVA'yı emekliye ayırmaz. Emeğe ayırdığı şey, cihazın gereksinime giden tek yol olduğu varsayımıdır.

Özel uç noktayı iki düzeyde etkinleştirin

VPN ağ geçidini barındıran VNet'e bağlı, çalışan bir ExpressRoute özel peering bağlantısıyla başlayın. Şirket içi taraf, ilgili özel adreslere o devre üzerinden zaten ulaşabiliyor olmalıdır, çünkü tünel bu adresleri taşıma olarak kullanacaktır. Ardından ağ geçidi önkoşulu: özel IP VPN için Microsoft yordamı Standard genel IP kaynağı üzerine kurulmuş bir ağ geçidi gerektirir. Özel tünel adreslemesi bu koşulu ortadan kaldırmaz; bu, «özel»in «hiçbir yerde genel IP yok» anlamına geldiğini sananları şaşırtır.

Şimdi bayrağı iki yerde de etkinleştirin. Ağ geçidi yapılandırmasının özel IP'ler için kendi anahtarı vardır ve tek tek Site-to-Site bağlantısının, o bağlantının özel adresi kullanmasını sağlayan ikinci bir anahtarı vardır. Birini ayarlayıp diğerini ayarlamamak en yaygın eksik yapılandırmadır; tünel ya kurulmaz ya da yanlış uç noktaya kurulur.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Özellik adlarını kurulu CLI sürümünüze göre doğrulayın, çünkü portal etiketleri ile CLI özellikleri her zaman aynı ifadeyi paylaşmaz. Aktif-aktif bir ağ geçidi iki özel tünel adresi sunar ve bu yedekliliğin bir anlamı olması için şirket içi cihazda her iki eşin de yapılandırılması gerekir. Yalnızca bu özel adresli tüneli ayağa kaldırmak için BGP gerekmez, ancak genellikle önekleri dağıtma biçiminizin bir parçasıdır.

İkinci mit: kurulmuş bir tünel trafiğinizi şifreler

Artık uygulama ağına iki yol ulaşır: doğrudan özel peering yolu ve VPN üzerinden yol. İkisi de çalışır. Bu IPsec katmanını yalnızca biri uygular. Microsoft, aynı önekler hem ExpressRoute hem VPN üzerinden duyurulduğunda Azure'un doğrudan ExpressRoute yolunu tercih ettiğini belgeler; bu nedenle sağlıklı bir tünel ve sağlıklı sayaçlar, uygulama paketlerinin nereye gittiği konusunda hiçbir şey kanıtlamaz.

Belgelenen yönlendirme yöntemleri, ExpressRoute üzerinde kapsayan bir aralık ile VPN üzerinde daha belirgin korunan bir aralık ya da iki yolda ayrık öneklerdir. Örneğin, özel peering 10.40.0.0/16 taşıyabilirken VPN 10.40.12.0/24 duyurur. Daha belirgin önek kazanır ve aralığın geri kalanı doğrudan kalır.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Aynı kontrolü şirket içi yönde de yapın, çünkü giden trafiğin hangi taraftan çıkacağına yönlendiricinizin tercihi karar verir. Ve tünelin kendi taşımasını ExpressRoute yolunda tutun; ağ geçidinin özel uç noktasını tünelin içine çeken bir rota, tüneli kendine bağımlı hâle getirir.

Tünel düştüğünde ne olacağına karar verin

Tünel düştüğünde daha belirgin VPN rotası kaybolurken daha geniş doğrudan rota kalır. Trafik o zaman şifrelenmeden akar ve her şey sağlıklı görünür; şifrelemeyi garanti etmek için var olan bir gereksinim için en kötü arıza kipidir. Gereksinim bu geri dönüşü yasaklıyorsa, yönlendirme ve erişim ilkesi tünelin kullanılabilirliğine güvenmek yerine bunu açıkça söylemelidir.

Hangi öneklerin doğrudan erişilebilir kalabileceğini ve hangilerinin şifrelenmiş yol yokken durması gerektiğini yazın. Ardından izin verilen durumu gerçek trafikle test edin ve bağlantı sayaçlarını karşılaştırın, çünkü yalnızca rota tablosu şifreleme gereksiniminin hâlâ geçerli olup olmadığını size söylemez.

Bu çerçeve, uç nokta özel olduğu için bir NVA satın almak yerine, onu gerçek özelliklerine göre değerlendirmenize de olanak tanır: birden çok tünel, işleme kapasitesi veya sağlayıcı denetimi gibi.