Uç sanal ağlarında varsayılan yol ekleme

Azure'daki en yaygın mimarilerden biri, uç sanal ağına (VNet) dağıtılan iş yüklerinin trafiği merkez sanal ağında bulunan paylaşılan ağ cihazları aracılığıyla gönderdiği merkez-uç tasarımıdır. Kullanıcı tanımlı yolların (UDR) trafiği merkezdeki güvenlik cihazlarına yönlendirmek için uç sanal ağlarında yapılandırılması gerekir. Ancak, bu tasarım yöneticilerin bu yolları birçok uçta yönetmesini gerektirir.

Azure Route Server, ağ sanal gereçlerinin (NVA) uç sanal ağlarına eklediği yolları tanıtabileceği merkezi bir nokta sunar. Bu şekilde yöneticilerin uç sanal ağlarda rota tabloları oluşturması ve güncelleştirmesi gerekmez.

Topoloji

Aşağıdaki diyagramda merkez sanal ağı ve iki uçlu sanal ağ ile basit bir merkez-uç tasarımı gösterilmiştir. Hub'da bir ağ sanal gereci ve Rota Sunucusu dağıtıldı. Route Server olmadan, kullanıcı tanımlı yolların her uçta yapılandırılması gerekir. Bu UDR'ler genellikle 0.0.0.0/0 için uç sanal ağlarından gelen tüm trafiği NVA üzerinden gönderen varsayılan bir yol içerir. Bu senaryo, örneğin trafiği güvenlik amacıyla incelemek için kullanılabilir.

Diagram showing a basic hub and spoke topology.

Merkez VNet'indeki Rota Sunucusu ile kullanıcı tanımlı yolları kullanmanız gerekmez. NVA, ağ ön eklerini Yönlendirme Sunucusu'na tanıtarak uzak sanal ağın ağ geçidini veya Yönlendirme Sunucusunu kullan ayarıyla merkez sanal ağında veya uç sanal ağında dağıtılan tüm sanal makinelerin etkin yollarında görünmelerini sağlar.

NVA aracılığıyla şirket içi Bağlan

NVA, IPsec VPN'leri veya SD-WAN teknolojileri aracılığıyla şirket içi ağa bağlantı sağlamak için kullanılıyorsa, aynı mekanizma uçlardan NVA'ya trafiği çekmek için de kullanılabilir. Ayrıca NVA, Azure Route Server'dan Azure ön eklerini dinamik olarak öğrenebilir ve bunları şirket içinde dinamik yönlendirme protokolüyle tanıtabilir. Aşağıdaki diyagramda bu kurulum açıklanmaktadır:

Diagram showing a basic hub and spoke topology with on-premises connectivity via an NVA.

NVA aracılığıyla özel trafiği denetleme

Önceki bölümlerde, NVA'dan Yol Sunucusuna varsayılan bir 0.0.0.0/0 yol eklenerek ağ sanal gereci (NVA) tarafından denetlenen trafik gösterilir. Ancak, NVA üzerinden yalnızca uç-uç ve şirket içi trafiği incelemek istiyorsanız, Azure Route Server'ın NVA'dan öğrenilen sanal ağ adres alanından aynı veya daha uzun bir ön ek olan bir yolu tanıtmadığını göz önünde bulundurmanız gerekir. Başka bir deyişle Azure Route Server bu ön ekleri sanal ağa eklemez ve merkez veya uç sanal ağlarındaki sanal makinelerin NIC'lerine programlanmayacak.

Ancak Azure Route Server, NVA'dan öğrenilen sanal ağ adres alanından daha büyük bir alt ağı tanıtacaktır. NVA'dan sanal ağınızdakilerin üst ağını tanıtabilirsiniz. Örneğin, sanal ağınız RFC 1918 adres alanını 10.0.0.0/16kullanıyorsa, NVA'nız Azure Route Server'a tanıtabilir 10.0.0.0/8 ve bu ön ekler hub ve uç sanal ağlarına eklenir. Bu sanal ağ davranışına VPN Gateway ile BGP Hakkında bölümünden başvurulur.

Diagram showing the injection of private prefixes through Azure Route Server and NVA.

Önemli

ExpressRoute ve NVA'dan aynı uzunlukta ön eklerin tanıtıldığı bir senaryonuz varsa Azure, ExpressRoute'tan öğrenilen yolları tercih eder ve programlar. Daha fazla bilgi edinmek için sonraki bölüme bakın.

Sanal ağ geçitleri aracılığıyla şirket içinde Bağlan üretkenlik

Şirket içi ağlara bağlantı sağlamak için Yönlendirme Sunucusu ve NVA ile aynı sanal ağda bir VPN veya ExpressRoute ağ geçidi varsa, bu ağ geçitleri tarafından öğrenilen yollar uç sanal ağlarında da programlanır. Bu yollar, daha belirgin (daha uzun ağ maskeleri) olacağından, Rota Sunucusu tarafından eklenen varsayılan yolu (0.0.0.0/0) geçersiz kılar. Aşağıdaki diyagramda, ExpressRoute ağ geçidinin eklendiği önceki tasarım açıklanmaktadır.

Diagram showing a basic hub and spoke topology with on-premises connectivity via an NVA and ExpressRoute.

Uç sanal ağlardaki alt ağları yalnızca Azure Route Server'dan yolları öğrenecek şekilde yapılandıramazsınız. Alt ağ ile ilişkilendirilmiş bir yol tablosunda "Ağ geçidi yollarını yay" özelliğinin devre dışı bırakılması, her iki yol türünün de (sanal ağ geçidinden yollar ve Azure Route Server'dan yollar) bu alt ağdaki NIC'lere eklenmesini engeller.

Varsayılan olarak, Yönlendirme Sunucusu NVA'dan öğrenilen tüm ön ekleri ExpressRoute'a da tanıtmaktadır. Bu, örneğin ExpressRoute'un yol sınırları veya Yol Sunucusu'nun kendisi nedeniyle istenmeyebilir. Bu durumda, NVA BGP topluluğu no-advertise (değeriyle 65535:65282) dahil olmak üzere Rota Sunucusuna yollarını duyurabilir. Route Server bu BGP topluluğuyla yolları aldığında, bunları alt ağlara aktarır, ancak bunları diğer BGP eşlerine (ExpressRoute veya VPN ağ geçitleri veya diğer NVA'lar gibi) tanıtmaz.

ExpressRoute ve Azure Güvenlik Duvarı ile SDWAN bir arada bulunma

Önceki tasarımın belirli bir örneği, müşterilerin ExpressRoute veya SD-WAN/VPN gereçleri aracılığıyla şirket içi ağlara giden tüm trafiği incelemek için trafik akışına Azure Güvenlik Duvarı eklemeleridir. Bu durumda, tüm uç alt ağları, uçların ExpressRoute veya Route Server'dan herhangi bir yolu öğrenmesini engelleyen rota tablolarına sahiptir ve aşağıdaki diyagramda gösterildiği gibi varsayılan yolları (0.0.0.0/0) ve sonraki atlama olarak Azure Güvenlik Duvarı vardır:

Diagram showing hub and spoke topology with on-premises connectivity via NVA for VPN and ExpressRoute where Azure Firewall does the breakout.

Azure Güvenlik Duvarı alt ağı hem ExpressRoute'tan hem de VPN/SDWAN NVA'dan gelen yolları öğrenir ve trafiğin öyle mi yoksa başka bir yolla mı gönderilip gönderilmeyeceğine karar verir. Önceki bölümde açıklandığı gibi, NVA gereci Rota Sunucusuna 200'den fazla yol tanıtıyorsa BGP yollarını BGP topluluğu no-advertiseile işaretlenmiş olarak göndermelidir. Bu şekilde, SDWAN ön ekleri Express-Route aracılığıyla şirket içi ortamına geri eklenmez.

Trafik simetrisi

Daha iyi dayanıklılık veya ölçeklenebilirlik için etkin/etkin senaryoda birden çok NVA örneği kullanılıyorsa NVA'ların bağlantıların durumunu korumaları gerekiyorsa trafik simetrisi bir gereksinimdir. Bu, örneğin Yeni Nesil Güvenlik Duvarları'nın durumudur.

  • Azure sanal makinelerinden genel İnternet'e bağlantı için, NVA kaynak ağ adresi çevirisini (SNAT) kullanır, böylece çıkış trafiği NVA'nın genel IP adresinden kaynaklanır ve böylece trafik simetrisi elde edilir.
  • Sanal makinelerde çalışan iş yüklerine İnternet'ten gelen trafik için, hedef ağ adresi çevirisine (DNAT) ek olarak NVA'ların, sanal makinelerden gelen trafiğin ilk paketi işleyen aynı NVA örneğine indiğinden emin olmak için kaynak ağ adresi çevirisi (SNAT) yapması gerekir.
  • Azure'dan Azure'a bağlantı için kaynak sanal makine yönlendirme kararını hedeflerden bağımsız olarak alacağı için trafik simetrisine ulaşmak için SNAT gereklidir.

Birden çok NVA örneği etkin/pasif bir kurulumda da dağıtılabilir; örneğin, bunlardan biri diğerinden daha kötü yolları (as yolu daha uzun) tanıtıyorsa. Bu durumda, Azure Route Server yalnızca sanal ağ sanal makinelerine tercih edilen yolu ekler ve daha az tercih edilen yol yalnızca birincil NVA örneği BGP üzerinden reklam kullanmayı durdurduğunda kullanılır.

Sanal Ağ Ağ Geçitlerine ve sanal ağlara yolları tanıtmak için farklı Yol Sunucuları

Önceki bölümlerde gösterildiği gibi Azure Route Server'ın çift rolü vardır:

  • Sanal ağ geçitlerine giden/giden yolları (VPN ve ExpressRoute) öğrenir ve tanıtma
  • Öğrenilen yolları kendi sanal akında ve doğrudan eşlenmiş sanal ağlarda yapılandırıyor

Bu çift işlev genellikle ilginçtir, ancak bazen belirli gereksinimlere zarar verebilir. Örneğin, Yönlendirme Sunucusu şirket içinden 0.0.0.0/0 yolunu ve ExpressRoute ağ geçidi reklam ön eklerini tanıtan bir NVA ile bir sanal ağda dağıtılırsa, sanal ağındaki ve doğrudan eşlenen sanal ağlardaki tüm yolları (NVA'dan 0.0.0.0/0 ve şirket içi ön ekleri) yapılandıracaktır. Sonuç olarak, şirket içi ön ekleri 0.0.0.0/0'dan daha belirgin olacağından, şirket içi ile Azure arasındaki trafik NVA'yı atlar. Bu istenmiyorsa, bu makaledeki önceki bölümlerde VM alt ağlarında BGP yayma özelliğini devre dışı bırakma ve UDR'leri yapılandırma adımları gösterilmiştir.

Ancak alternatif ve daha dinamik bir yaklaşım vardır. Farklı işlevler için farklı Azure Route Sunucuları kullanmak mümkündür: bunlardan biri sanal ağ geçitleriyle, diğeri ise sanal ağ yönlendirmesiyle etkileşimde bulunur. Aşağıdaki diyagramda bunun için olası bir tasarım gösterilmektedir:

Diagram showing a basic hub and spoke topology with on-premises connectivity via ExpressRoute and two Route Servers.

Hub'daki Route Server 1, SDWAN ön eklerini ExpressRoute'a eklemek için kullanılır. Uç sanal ağları Uzak sanal ağın ağ geçidini veya Rota Sunucusu'nu (uç sanal ağ eşlemesinde) kullanma ve Bu sanal ağın ağ geçidini veya Rota Sunucusunu kullanma (Merkez sanal ağ eşlemesinde ağ geçidi geçişi) olmadan merkez sanal ağları ile eşlendiği için uç sanal ağları bu yolları (SDWAN ön ekleri veya ExpressRoute ön ekleri) öğrenmez.

NVA, yolları uç sanal ağlarına yaymak için yeni bir yardımcı sanal ağa dağıtılan Route Server 2'yi kullanır. NVA, Route Server 2'ye yalnızca tek 0.0.0.0/0 bir yol yayacaktır. Uç sanal ağları, uzak sanal ağın ağ geçidini veya Rota Sunucusunu (uç sanal ağ eşlemesinde) kullanma ve Bu sanal ağın ağ geçidini veya Rota Sunucusunu (merkez sanal ağ eşlemesinde 0.0.0.0/0 ağ geçidi geçişi) kullanma ile bu yardımcı sanal ağ ile eşlendiği için, yol uçlardaki tüm sanal makineler tarafından öğrenilir.

Yol için 0.0.0.0/0 sonraki atlama NVA'dır, bu nedenle uç sanal ağlarının hala merkez sanal ağıyla eşlenmiş olması gerekir. Dikkat edilmesi gereken bir diğer önemli nokta da merkez sanal unun Route Server 2'nin dağıtıldığı sanal ağ ile eşlenmesi gerektiğidir, aksi takdirde BGP bitişikliğini oluşturamaz.

ExpressRoute'tan uç sanal ağlarına giden trafik inceleme için bir güvenlik duvarı NVA'sına gönderilecekse, GatewaySubnet'teki bir yol tablosu hala gereklidir, aksi takdirde ExpressRoute sanal ağ geçidi, sanal ağ eşlemesinden öğrenilen yolları kullanarak sanal makinelere paket gönderir. Bu yol tablosundaki yollar uç ön ekleriyle eşleşmeli ve sonraki atlama güvenlik duvarı NVA'sının IP adresi (veya yedeklilik için güvenlik duvarı NVA'larının önündeki yük dengeleyici) olmalıdır. Güvenlik duvarı NVA'sı yukarıdaki diyagramdaki SDWAN NVA ile aynı olabileceği gibi, Azure Güvenlik Duvarı gibi farklı bir cihaz da olabilir çünkü SDWAN NVA, sonraki atlama diğer IP adreslerine işaret eden yolları tanıtabilir. Aşağıdaki diyagramda, Azure Güvenlik Duvarı eklenerek bu tasarım gösterilmektedir:

Diagram showing a basic hub and spoke topology with on-premises connectivity via ExpressRoute, an Azure Firewall, and two Route Servers.

Bu tasarım ExpressRoute, VPN veya SDWAN ortamından öğrenilen diğer yolların müdahalesi olmadan uç sanal ağlarına yolların otomatik olarak eklenmesine ve trafik denetimi için güvenlik duvarı NVA'larının eklenmesine olanak tanır.