Sanal WAN yönlendirmeye derinlemesine bakış

Azure Sanal WAN, gelişmiş ağ topolojilerinin kolayca oluşturulmasına olanak tanıyan bir ağ çözümüdür: Noktadan Siteye VPN, Siteden Siteye VPN, ExpressRoute ve tümleşik SDWAN gereçleri aracılığıyla Azure sanal ağları ve şirket içi konumlar arasında Trafiğin güvenliğini sağlama seçeneği de dahil olmak üzere Azure bölgeleri arasında yönlendirmeyi kapsar. Çoğu senaryoda, Sanal WAN iç yönlendirmenin nasıl çalıştığı hakkında ayrıntılı bilgi sahibi olmanız gerekmez, ancak bazı durumlarda Sanal WAN yönlendirme kavramlarını anlamak yararlı olabilir.

Bu belge, kuruluşların sanal ağlarıyla dallarını karmaşık ağlara bağlarken karşılaşabilecekleri davranışlardan bazılarını açıklayan örnek Sanal WAN senaryolarını inceler. Bu makalede gösterilen senaryolar hiçbir şekilde tasarım önerileri değildir, yalnızca belirli Sanal WAN işlevlerini göstermek için tasarlanmış örnek topolojilerdir.

Senaryo 1: varsayılan yönlendirme tercihi olan topoloji

Bu makaledeki ilk senaryoda expressRoute, VPN ve SDWAN bağlantısı olmak üzere iki Sanal WAN hub'ı olan bir topoloji analiz edilir. Her hub'da doğrudan (VNet 11 ve 21) ve dolaylı olarak bir NVA üzerinden (121, 122, 221 ve 222 sanal ağları) bağlı sanal ağlar vardır. VNet 12, yönlendirme bilgilerini HUB 1 ile BGP aracılığıyla değiştirir (bkz . Sanal hub ile BGP eşlemesi) ve VNet 22'de statik yollar yapılandırılmıştır, böylece her iki seçenek arasındaki farklar gösterilebilir.

Her hub'da VPN ve SDWAN cihazları çift amaca hizmet eder: bir tarafta kendi ön eklerini (10.4.1.0/24 merkez 1'de VPN üzerinden ve 10.5.3.0/24 hub 2'de SDWAN üzerinden) ve diğer tarafta aynı bölgedeki ExpressRoute bağlantı hatlarıyla aynı ön ekleri (10.4.2.0/24 hub 1'de ve 10.5.2.0/24 hub 2'de) tanıtırlar. Bu fark, Sanal WAN hub yönlendirme tercihinin nasıl çalıştığını göstermek için kullanılır.

Tüm sanal ağ ve dal bağlantıları ilişkilendirilir ve varsayılan yol tablosuna yayılır. Hub'ların güvenliği sağlansa da (her hub'da dağıtılan bir Azure Güvenlik Duvarı vardır), özel veya İnternet trafiğinin güvenliğini sağlamak için yapılandırılmamıştır. Bunun yapılması, yol tablosuna yayılan tüm bağlantıların None yol tablosundan tüm statik olmayan yolları Default kaldırmasına ve portaldaki etkin yol dikey penceresi neredeyse boş olacağından (trafiği Azure Güvenlik Duvarı göndermek için kullanılan statik yollar dışında) bu makalenin amacını bozacak şekilde sonuçlanır.

Sanal WAN hub'ları, bölgeler arasında iletişimin etkinleştirilmesi için birbiriyle bilgi alışverişinde bulunur. Sanal WAN yol tablolarındaki geçerli yolları inceleyebilirsiniz: Örneğin, aşağıdaki resimde merkez 1'deki geçerli yollar gösterilmektedir:

Bu etkili yollar daha sonra Sanal WAN tarafından dallara tanıtılır ve bunları sanal hub'lara bağlı sanal ağlara ekleyerek Kullanıcı Tanımlı Yolların kullanılmasını gereksiz hale getirir. Bir sanal hub'daki geçerli yolları incelerken "Sonraki Atlama Türü" ve "Kaynak" alanları yolların nereden geldiğini gösterir. Örneğin, "Sanal Ağ Bağlan ion" Sonraki Atlama Türü, ön ekin doğrudan Sanal WAN bağlı bir sanal ağda tanımlandığını gösterir (önceki ekran görüntüsünde VNet 11 ve 12)

VNet 12'deki NVA, Sonraki Atlama Türü "HubBgp Bağlan ion" gibi BGP üzerinden 10.1.20.0/22 yolunu ekler (bkz. Sanal Hub ile BGP Eşlemesi). Bu özet rota hem dolaylı uçlar VNet 121 (10.1.21.0/24) hem de VNet 122 (10.1.22.0/24) konularını kapsar. Uzak hub'daki sanal ağlar ve dallar bir sonraki atlamayla hub2görünür ve AS yolunda otonom Sistem Numarası'nın 65520 bu interhub yollarına iki kez eklendiği görülebilir.

Hub 2'de tümleşik bir SDWAN Ağ Sanal Gereci vardır. Bu tümleştirme için desteklenen NVA'lar hakkında daha fazla bilgi için lütfen Sanal WAN hub'ında NVA'lar hakkında bölümünü ziyaret edin. SDWAN dalının 10.5.3.0/24 yolunun bir sonraki atlamasına VPN_S2S_Gatewaysahip olduğunu unutmayın. Bu tür bir sonraki atlama, bugün bir Azure Sanal Ağ Gateway'den veya hub'a tümleşik NVA'lardan gelen yolları gösterebilir.

Merkez 2'de, dolaylı uçlara giden yol 10.2.20.0/22 VNet 221 (10.2.21.0/24) ve VNet 222 (10.2.22.0/24) kaynağı defaultRouteTabletarafından belirtildiği gibi statik bir yol olarak yüklenir. Hub 1 için geçerli yolları denetlerseniz, bu yol orada değildir. Bunun nedeni statik yolların BGP aracılığıyla yayılmamış olması, ancak her hub'da yapılandırılması gerektiğidir. Bu nedenle, hub 1'deki sanal ağlar ve dallar arasında merkez 2'deki dolaylı uçlara (VNet 221 ve 222) bağlantı sağlamak için hub 1'de statik bir yol gereklidir:

Statik yolu ekledikten sonra hub 1 de yolu içerir 10.2.20.0/22 :

Senaryo 2: Genel Erişim ve merkez yönlendirme tercihi

Hub 1, bağlantı hattı 2'den (10.5.2.0/24) ExpressRoute ön ekini ve 1. bağlantı10.4.2.0/24 hattından () ExpressRoute ön ekini biliyor olsa bile, uzak bölgelerden gelen ExpressRoute yolları şirket içi ExpressRoute bağlantılarına geri tanıtılamaz. Sonuç olarak ExpressRoute konumlarının birbiriyle iletişim kurması için ExpressRoute Global Reach gereklidir:

Sanal hub yönlendirme tercihinde açıklandığı gibi Sanal WAN varsayılan olarak ExpressRoute'tan gelen yolları tercih eder. Yollar merkez 1'den ExpressRoute bağlantı hattı 1'e, ExpressRoute bağlantı hattı 1'den bağlantı hattı 2'ye ve ExpressRoute bağlantı hattı 2'den hub 2'ye (ve tam tersi) tanıtıldığından, sanal hub'lar şimdi daha doğrudan merkezler arası bağlantı yerine bu yolu tercih eder. Hub 1'deki geçerli yollar şunu gösterir:

Rotalarda görebileceğiniz gibi ExpressRoute Global Reach, bu yolları daha az tercih edilebilir hale getirmek için yolları Azure'a geri göndermeden önce ExpressRoute Otonom Sistem Numarası'nı (12076) birden çok kez ekler. Ancak ExpressRoute'un varsayılan hub yönlendirme önceliği Sanal WAN yönlendirme kararı alınırken AS yol uzunluğunu yoksayar.

Merkez 2'deki geçerli yollar benzer olacaktır:

Yönlendirme tercihi, Sanal hub yönlendirme tercihinde açıklandığı gibi VPN veya AS-Path olarak değiştirilebilir. Örneğin, bu görüntüde gösterildiği gibi tercihi VPN olarak ayarlayabilirsiniz:

VPN'in merkez yönlendirme tercihi ile merkez 1'deki geçerli yollar şöyle görünür:

Önceki görüntüde, adresine 10.4.2.0/24 giden yolun artık bir sonraki atlamasına VPN_S2S_Gatewaysahip olduğu gösterilirken, ExpressRoute'un varsayılan yönlendirme tercihi olan öğesinin olduğu gösterilir ExpressRouteGateway. Bununla birlikte, hub 2'de yolu 10.5.2.0/24 yine sonraki atlamasıyla ExpressRoutegörüntülenir, çünkü bu durumda alternatif yol bir VPN Gateway'den değil, hub ile tümleştirilmiş bir NVA'dan gelir:

Ancak merkezler arasındaki trafik hala ExpressRoute üzerinden gelen yolları tercih ediyor. Sanal hub'lar arasında daha verimli doğrudan bağlantı kullanmak için yol tercihi her iki hub'da da "AS Path" olarak ayarlanabilir:

Artık merkez 1'deki uzak uçlar ve dallar için rotaların bir sonraki atlaması Remote Hub amaçlandığı gibi olacaktır:

Hub 2 (192.168.2.0/23) için IP ön ekinin Genel Erişim bağlantısı üzerinden hala erişilebilir olduğunu görebilirsiniz, ancak hub 2'deki cihazlara yönelik herhangi bir trafik olmaması gerektiği için bunun trafiği etkilememesi gerekir. Ancak her iki hub'da da birbiriyle SDWAN tünelleri oluşturan NVA'lar varsa bu yol bir sorun olabilir.

Ancak, 10.4.2.0/24 artık VPN Gateway yerine tercih edilir. VPN aracılığıyla tanıtılan yolların AS yolu ExpressRoute üzerinden tanıtılan yollardan daha kısaysa bu durum oluşabilir. Şirket içi VPN cihazını, Otonom Sistem Numarası'nı (65501) VPN yollarına yükleyerek daha az tercih edilebilir hale getirecek şekilde yapılandırdıktan sonra, merkez 1 şimdi için 10.4.2.0/24sonraki atlama olarak ExpressRoute'u seçer:

Hub 2, diğer hub'daki sanal ağların ve dalların sonraki atlama olarak göründüğü Remote Hub geçerli yollar için benzer bir tablo gösterir:

Senaryo 3: ExpressRoute bağlantı hatlarını iki hub'a da çapraz bağlama

Azure bölgeleri ile ExpressRoute aracılığıyla bağlanan şirket içi konumlar arasında doğrudan bağlantılar eklemek için, genellikle aşağıdaki topolojide gösterildiği gibi tek bir ExpressRoute bağlantı hattının bir topolojideki birden çok Sanal WAN hub'ına bağlanması tercih edilir:

Sanal WAN her iki bağlantı hattının da her iki hub'a da bağlı olduğunu gösterir:

ExpressRoute'un varsayılan hub yönlendirme tercihine geri döndüğünüzde, merkez 1'deki uzak dallara ve sanal ağlara giden yollar sonraki atlama olarak ExpressRoute'u yeniden gösterir. Bu kez bunun nedeni Global Reach olmasa da ExpressRoute devrelerinin bir merkezden diğerine aldıkları yol tanıtımlarını geri döndürmesi. Örneğin, ExpressRoute'un merkez yönlendirme tercihi ile hub 1'in etkili yolları şunlardır:

Hub yönlendirme tercihini yeniden AS Yolu olarak değiştirmek, merkezler arası yolları hub 1 ile 2 arasındaki doğrudan bağlantıyı kullanarak en uygun yola döndürür:

Sonraki adımlar

Sanal WAN hakkında daha fazla bilgi için bkz:

• Sanal WAN SSS