ExpressRoute özel eşlemesi için yedek olarak S2S VPN kullanma
ExpressRoute özel eşlemesi ile olağanüstü durum kurtarma için tasarlama başlıklı makalede, ExpressRoute özel eşlemesi kullanılırken bir yedekleme bağlantısı çözümüne ihtiyaç duyulduğundan bahsedildi. Ayrıca, yüksek kullanılabilirlik için coğrafi olarak yedekli ExpressRoute bağlantı hatlarının nasıl kullanılacağını da ele aldık. Bu makalede, ExpressRoute özel eşlemesi için yedek olarak siteden siteye (S2S) VPN'in nasıl kullanılacağını ve sürdürülmesini açıklayacağız.
Not
Gecikme süresine duyarlı, görev açısından kritik veya bant genişliği yoğun iş yükleriyle ilgilenirken ExpressRoute bağlantısı için siteden siteye VPN'in bir yedekleme çözümü olarak kullanılması önerilmez. Bu gibi durumlarda, maksimum kullanılabilirlik sağlamak için ExpressRoute çok siteli dayanıklılık ile olağanüstü durum kurtarma tasarımı yapılması önerilir.
Coğrafi olarak yedekli ExpressRoute bağlantı hatlarından farklı olarak, etkin-pasif kurulumda yalnızca ExpressRoute ve VPN olağanüstü durum kurtarma bileşimini kullanabilirsiniz. Pasif modda herhangi bir yedekleme ağ bağlantısını kullanmanın en önemli zorluklarından biri, pasif bağlantının genellikle birincil bağlantıyla birlikte başarısız olmasıdır. Pasif bağlantının başarısız olmasının yaygın nedeni, etkin bakım eksikliğidir. Bu nedenle, bu makalede, ExpressRoute özel eşlemesini yedekleyen bir S2S VPN bağlantısını doğrulama ve etkin bir şekilde sürdürme konusuna odaklanılır.
Not
Belirli bir yol hem ExpressRoute hem de VPN aracılığıyla tanıtıldığında, Azure ExpressRoute yerine yönlendirmeyi tercih eder.
Bu makalede ayrıca hem Azure perspektifinden hem de şirket içi ağ uç tarafından bağlantıyı doğrulamayı öğreneceksiniz. İki taraftan da doğrulama özelliği, Microsoft ağ varlıklarıyla eş olan şirket içi ağ cihazlarını yönetip yönetmediğinize bakılmaksızın yardımcı olur.
Örnek topoloji
Kurulumumuzda hem ExpressRoute bağlantı hattı hem de S2S VPN bağlantısı aracılığıyla Azure hub sanal ağına bağlı bir şirket içi ağımız var. Azure hub sanal ağı, diyagramda gösterildiği gibi bir uç sanal ağına eşlenmiştir:
Kurulumda ExpressRoute bağlantı hattı şirket içindeki bir çift müşteri uç (CE) yönlendiricisinde sonlandırılır. Şirket içi LAN, öncü-takip modunda çalışan bir çift güvenlik duvarı ile CE yönlendiricilerine bağlanır. S2S VPN doğrudan güvenlik duvarlarında sonlandırılır.
Aşağıdaki tabloda topolojinin temel IP ön ekleri listeleniyor:
| Varlık | Önek |
|---|---|
| Şirket içi LAN | 10.1.11.0/25 |
| Azure Hub sanal ağı | 10.17.11.0/25 |
| Azure uç sanal ağı | 10.17.11.128/26 |
| Şirket içi test sunucusu | 10.1.11.10 |
| Uç sanal ağ testi VM'si | 10.17.11.132 |
| ExpressRoute birincil bağlantısı P2P alt ağı | 192.168.11.16/30 |
| ExpressRoute ikincil bağlantısı P2P alt ağı | 192.168.11.20/30 |
| VPN ağ geçidi birincil BGP eş IP'si | 10.17.11.76 |
| VPN ağ geçidi ikincil BGP eş IP'si | 10.17.11.77 |
| Şirket içi güvenlik duvarı VPN BGP eş IP | 192.168.11.88 |
| Güvenlik duvarı IP'sine yönelik birincil CE yönlendiricisi i/f | 192.168.11.0/31 |
| Birincil CE yönlendirici IP'sine yönelik güvenlik duvarı i/f | 192.168.11.1/31 |
| güvenlik duvarı IP'sine yönelik ikincil CE yönlendiricisi i/f | 192.168.11.2/31 |
| İkincil CE yönlendirici IP'sine yönelik güvenlik duvarı i/f | 192.168.11.3/31 |
Aşağıdaki tabloda topolojinin ASN'leri listelenir:
| Otonom sistem | ASN |
|---|---|
| Şirket içinde | 65020 |
| Microsoft Enterprise Edge | 12076 |
| Sanal Ağ GW (ExR) | 65515 |
| Sanal Ağ GW (VPN) | 65515 |
Asimetriklik olmadan yüksek kullanılabilirlik
Yüksek kullanılabilirlik için yapılandırma
ExpressRoute ve Siteden Siteye bağlantıları yapılandırma makalesinde, birlikte var olan ExpressRoute ve S2S VPN bağlantılarının nasıl ayarlanacağı açıklanır. ExpressRoute ile yüksek kullanılabilirlik tasarlama bölümünde de belirttiğimiz gibi kurulumumuz, uç noktalara kadar tek bir hata noktasını ortadan kaldırmak için ağ yedekliliğini güvence altına alır ve bu da ExpressRoute yüksek kullanılabilirliğini artırır. Ayrıca, ExpressRoute bağlantı hatlarının hem birincil hem de ikincil bağlantıları etkindir ve şirket içi ön eklerini her iki bağlantı aracılığıyla aynı şekilde tanıtmaktadır.
ExpressRoute bağlantı hattının birincil bağlantısı üzerinden birincil CE yönlendiricisinin şirket içi yol tanıtımı aşağıdaki gibi gösterilir (Junos komutları):
user@SEA-MX03-01> show route advertising-protocol bgp 192.168.11.18
Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
ExpressRoute bağlantı hattının ikincil bağlantısı aracılığıyla ikincil CE yönlendiricisinin şirket içi yol tanıtımı aşağıdaki gibi gösterilir (Junos komutları):
user@SEA-MX03-02> show route advertising-protocol bgp 192.168.11.22
Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
Yedekleme bağlantısının yüksek kullanılabilirliğini geliştirmek için S2S VPN de etkin-etkin modunda yapılandırılır. Azure VPN ağ geçidi yapılandırması aşağıdaki gibi gösterilir. VPN yapılandırması VPN'sinin bir parçası olarak ağ geçidinin BGP eş IP adresleri (10.17.11.76 ve 10.17.11.77) de listelenir.
Şirket içi yol, güvenlik duvarı tarafından VPN ağ geçidinin birincil ve ikincil BGP eşlerine tanıtılır. Yol tanıtımları aşağıdaki gibi gösterilir (Junos):
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.76
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
{primary:node0}
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.77
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.1.11.0/25 Self I
Not
S2S VPN'i etkin-etkin modda yapılandırmak yalnızca olağanüstü durum kurtarma yedekleme ağı bağlantınıza yüksek kullanılabilirlik sağlamakla kalmaz, aynı zamanda yedekleme bağlantısı için daha yüksek aktarım hızı sağlar. Bu nedenle, birden çok temel tünel oluşturacağı için S2S VPN'in etkin-etkin modda yapılandırılması önerilir.
Simetrik trafik akışı için yapılandırma
Belirli bir şirket içi yol hem ExpressRoute hem de S2S VPN aracılığıyla tanıtıldığında Azure'ın ExpressRoute yolunu tercih edeceğini belirttik. Azure'ı birlikte bulunan ExpressRoute yerine S2S VPN yolunu tercih etmeye zorlamak için VPN bağlantısı aracılığıyla daha belirli yolları (daha büyük alt ağ maskesiyle daha uzun ön ek) tanıtmalısınız. Hedefimiz VPN bağlantılarını yalnızca yedekleme olarak kullanmaktır. Bu nedenle, Azure'ın varsayılan yol seçimi davranışı hedefimizle uyumludur.
Şirket içinden Azure'a giden trafiğin siteden siteye VPN üzerinden ExpressRoute yolunu da tercih etmesini sağlamak bizim sorumluluğumuzdadır. Şirket içi kurulumumuzda CE yönlendiricilerinin ve güvenlik duvarlarının varsayılan yerel tercihi 100'dür. Bu nedenle, ExpressRoute özel eşlemeleri üzerinden alınan yolların yerel tercihini 100'den büyük yapılandırarak Azure'a yönelik trafiğin ExpressRoute bağlantı hattını tercih etmelerini sağlayabiliriz.
ExpressRoute bağlantı hattının birincil bağlantısını sonlandıran birincil CE yönlendiricisinin BGP yapılandırması aşağıdaki gibi gösterilir. iBGP oturumu üzerinden tanıtılan yolların yerel tercihinin değerinin 150 olarak yapılandırıldığını unutmayın. Benzer şekilde, ExpressRoute bağlantı hattının ikincil bağlantısını sonlandıran ikincil CE yönlendiricisinin yerel tercihinin de 150 olarak yapılandırıldığından emin olmamız gerekir.
user@SEA-MX03-01> show configuration routing-instances Cust11
description "Customer 11 VRF";
instance-type virtual-router;
interface xe-0/0/0:0.110;
interface ae0.11;
protocols {
bgp {
group ibgp {
type internal;
local-preference 150;
neighbor 192.168.11.1;
}
group ebgp {
peer-as 12076;
bfd-liveness-detection {
minimum-interval 300;
multiplier 3;
}
neighbor 192.168.11.18;
}
}
}
Şirket içi güvenlik duvarlarının yönlendirme tablosu, Azure'a yönlendirilen şirket içi trafik için tercih edilen yolun sabit durumda ExpressRoute üzerinden olduğunu onaylar.
user@SEA-SRX42-01> show route table Cust11.inet.0 10.17.11.0/24
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.17.11.0/25 *[BGP/170] 2d 00:34:04, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.0 via reth1.11
to 192.168.11.2 via reth2.11
[BGP/170] 2d 00:34:01, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.2 via reth2.11
[BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
AS path: 65515 I, validation-state: unverified
> via st0.118
[BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
AS path: 65515 I, validation-state: unverified
> via st0.119
10.17.11.76/32 *[Static/5] 2d 21:12:16
> via st0.118
10.17.11.77/32 *[Static/5] 2d 00:41:56
> via st0.119
10.17.11.128/26 *[BGP/170] 2d 00:34:04, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.0 via reth1.11
to 192.168.11.2 via reth2.11
[BGP/170] 2d 00:34:01, localpref 150
AS path: 12076 I, validation-state: unverified
> to 192.168.11.2 via reth2.11
[BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
AS path: 65515 I, validation-state: unverified
> via st0.118
[BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
AS path: 65515 I, validation-state: unverified
> via st0.119
Yukarıdaki yol tablosunda merkez-uç sanal ağ yolları için --10.17.11.0/25 ve 10.17.11.128/26--ExpressRoute bağlantı hattının VPN bağlantıları yerine tercih edildiğine bakıyoruz. 192.168.11.0 ve 192.168.11.2, CE yönlendiricilerine yönelik güvenlik duvarı arabirimindeki IP'lerdir.
S2S VPN üzerinden rota değişiminin doğrulanması
Bu makalenin önceki bölümlerinde, güvenlik duvarlarının şirket içi yönlendirme tanıtımını VPN ağ geçidinin birincil ve ikincil BGP eşlerine doğrulayacağız. Ayrıca, VPN ağ geçidinin birincil ve ikincil BGP eşlerinden güvenlik duvarları tarafından alınan Azure yollarını da onaylayalım.
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.76 table Cust11.inet.0
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.17.11.0/25 10.17.11.76 65515 I
10.17.11.128/26 10.17.11.76 65515 I
{primary:node0}
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.77 table Cust11.inet.0
Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
10.17.11.0/25 10.17.11.77 65515 I
10.17.11.128/26 10.17.11.77 65515 I
Benzer şekilde, Azure VPN ağ geçidi tarafından alınan şirket içi ağ yolu ön eklerini de doğrulayalım.
PS C:\Users\user> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | where {$_.Network -eq "10.1.11.0/25"} | select Network, NextHop, AsPath, Weight
Network NextHop AsPath Weight
------- ------- ------ ------
10.1.11.0/25 192.168.11.88 65020 32768
10.1.11.0/25 10.17.11.76 65020 32768
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 192.168.11.88 65020 32768
10.1.11.0/25 10.17.11.77 65020 32768
10.1.11.0/25 10.17.11.69 12076-65020 32769
10.1.11.0/25 10.17.11.69 12076-65020 32769
Daha önce görüldüğü gibi VPN ağ geçidinin hem birincil hem de ikincil BGP eşleri tarafından alınan yollar vardır. Ayrıca birincil ve ikincil ExpressRoute bağlantıları aracılığıyla alınan yollar (AS yolu 12076 ile ekli olanlar) üzerinde görünürlük sağlar. VPN bağlantıları aracılığıyla alınan yolları onaylamak için bağlantıların şirket içi BGP eş IP'sini bilmemiz gerekir. Dikkate alınan kurulumumuzda IP 192.168.11.88'dir ve buradan alınan yolları görürüz.
Şimdi Azure VPN ağ geçidi tarafından şirket içi güvenlik duvarı BGP eşine (192.168.11.88) tanıtılan yolları doğrulayalım.
PS C:\Users\user> Get-AzVirtualNetworkGatewayAdvertisedRoute -Peer 192.168.11.88 -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | select Network, NextHop, AsPath, Weight
Network NextHop AsPath Weight
------- ------- ------ ------
10.17.11.0/25 10.17.11.76 65515 0
10.17.11.128/26 10.17.11.76 65515 0
10.17.11.0/25 10.17.11.77 65515 0
10.17.11.128/26 10.17.11.77 65515 0
Yol değişimlerinin görünememesi bağlantının başarısız olduğunu gösterir. Bkz . Sorun giderme: Azure siteden siteye VPN bağlantısı bağlanamıyor ve VPN bağlantısı sorunlarını giderme konusunda yardım almak için çalışmayı durduruyor.
Yük devretmeyi test etme
VPN bağlantısı (kontrol düzlemi) üzerinden başarılı rota değişimlerini onayladığımıza göre, trafiği (veri düzlemi) ExpressRoute bağlantısından VPN bağlantısına geçmeye hazırız.
Not
Hizmet kesintisi olabileceği için üretim ortamlarında yük devretme testi zamanlanmış ağ bakım iş penceresi sırasında yapılmalıdır.
Trafik anahtarını gerçekleştirmeden önce, kurulumumuzdaki geçerli yolu şirket içi test sunucusundan uç sanal ağdaki test VM'sine yönlendirelim.
C:\Users\PathLabUser>tracert 10.17.11.132
Tracing route to 10.17.11.132 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.1.11.1
2 <1 ms <1 ms 11 ms 192.168.11.0
3 <1 ms <1 ms <1 ms 192.168.11.18
4 * * * Request timed out.
5 6 ms 6 ms 5 ms 10.17.11.132
Trace complete.
Kurulumumuzun birincil ve ikincil ExpressRoute noktadan noktaya bağlantı alt ağları sırasıyla 192.168.11.16/30 ve 192.168.11.20/30'dır. Yukarıdaki izleme yolunda, 3. adımda birincil MSEE'nin arabirim IP'si olan 192.168.11.18'e ulaşıyoruz. MSEE arabiriminin varlığı, beklendiği gibi geçerli yolumuzun ExpressRoute üzerinden olduğunu onaylar.
ExpressRoute bağlantı hattı eşlemelerini sıfırla bölümünde belirtildiği gibi, ExpressRoute bağlantı hattının hem birincil hem de ikincil eşlemesini devre dışı bırakmak için aşağıdaki PowerShell komutlarını kullanalım.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Yük devretme anahtar süresi BGP yakınsama süresine bağlıdır. Kurulumumuzda yük devretme anahtarı birkaç saniye sürer (10'dan az). Anahtardan sonra traceroute işleminin tekrarı aşağıdaki yolu gösterir:
C:\Users\PathLabUser>tracert 10.17.11.132
Tracing route to 10.17.11.132 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.1.11.1
2 * * * Request timed out.
3 6 ms 7 ms 9 ms 10.17.11.132
Trace complete.
traceroute sonucu, S2S VPN aracılığıyla yedekleme bağlantısının etkin olduğunu onaylar ve hem birincil hem de ikincil ExpressRoute bağlantıları başarısız olursa hizmet sürekliliği sağlayabilir. Yük devretme testini tamamlamak için aşağıdaki komut kümesini kullanarak ExpressRoute bağlantılarını etkinleştirelim ve trafik akışını normalleştirelim.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Trafiğin ExpressRoute'a geri döndüğünü onaylamak için izleme akışını tekrarlayın ve ExpressRoute özel eşlemesi üzerinden geçtiğinden emin olun.
Sonraki adımlar
ExpressRoute, Microsoft ağı içinde tek bir hata noktası olmadan yüksek kullanılabilirlik için tasarlanmıştır. Yine de ExpressRoute bağlantı hattı tek bir coğrafi bölgeyle ve bir hizmet sağlayıcısıyla sınırlandırılır. S2S VPN, ExpressRoute bağlantı hattı için iyi bir olağanüstü durum kurtarma pasif yedekleme çözümü olabilir. Güvenilir bir pasif yedekleme bağlantısı çözümü için pasif yapılandırmanın düzenli olarak bakımı ve düzenli olarak doğrulanması önemlidir. VPN yapılandırmasının eskimesine izin vermemek ve düzenli aralıklarla (örneğin her çeyrekte) bakım penceresi sırasında bu makalede açıklanan doğrulama ve yük devretme testi adımlarını yinelemek önemlidir.
VPN ağ geçidi ölçümlerine göre izlemeyi ve uyarıları etkinleştirmek için bkz . VPN Gateway ölçümleriyle ilgili uyarıları ayarlama.
ExpressRoute hatasından sonra BGP yakınsamasını hızlandırmak için ExpressRoute üzerinden BFD'yi yapılandırın.