Použití S2S VPN jako zálohy pro privátní partnerský vztah ExpressRoute
V článku Návrh pro zotavení po havárii pomocí privátního partnerského vztahu ExpressRoute jsme probrali potřebu řešení připojení k zálohování při použití privátního partnerského vztahu ExpressRoute. Také jsme probrali, jak používat geograficky redundantní okruhy ExpressRoute pro zajištění vysoké dostupnosti. V tomto článku vysvětlujeme, jak používat a udržovat síť VPN typu site-to-site (S2S) jako zálohu privátního partnerského vztahu ExpressRoute.
Poznámka:
Použití sítě VPN typu site-to-site jako řešení zálohování pro připojení ExpressRoute se nedoporučuje při řešení úloh náročných na latenci, kritické úlohy nebo úlohy náročné na šířku pásma. V takových případech je vhodné navrhnout zotavení po havárii s odolností expressRoute pro více lokalit, aby se zajistila maximální dostupnost.
Na rozdíl od geograficky redundantních okruhů ExpressRoute můžete v nastavení aktivní-pasivní použít pouze kombinaci expressRoute a zotavení po havárii VPN. Hlavním problémem při použití jakéhokoli připojení k síti zálohování v pasivním režimu je, že pasivní připojení často selže společně s primárním připojením. Běžným důvodem selhání pasivního připojení je nedostatek aktivní údržby. Proto se v tomto článku zaměřujeme na to, jak ověřit a aktivně udržovat připojení VPN typu S2S, které zálohuje privátní partnerský vztah ExpressRoute.
Poznámka:
Když se daná trasa inzeruje prostřednictvím ExpressRoute i VPN, Azure bude upřednostňovat směrování přes ExpressRoute.
V tomto článku se také dozvíte, jak ověřit připojení z hlediska Azure i z hraniční strany místní sítě. Možnost ověření na obou stranách pomáhá bez ohledu na to, jestli spravujete místní síťová zařízení, která jsou v partnerském vztahu se síťovými entitami Microsoftu.
Příklad topologie
V našem nastavení máme místní síť připojenou k virtuální síti centra Azure prostřednictvím okruhu ExpressRoute i připojení VPN typu S2S. Virtuální síť Centra Azure je zase v partnerském vztahu s paprskovou virtuální sítí, jak je znázorněno v diagramu:
V nastavení se okruh ExpressRoute ukončí na dvojici hraničních směrovačů zákazníka (CE) v místním prostředí. Místní síť LAN je připojená ke směrovačům CE s dvojicí bran firewall, které pracují v režimu sledování výsledků. Síť VPN S2S je přímo ukončena v bránách firewall.
Následující tabulka uvádí předpony ip adres klíče topologie:
| Entita | Předponu |
|---|---|
| Místní síť LAN | 10.1.11.0/25 |
| Virtuální síť Azure Hubu | 10.17.11.0/25 |
| Virtuální síť paprsků Azure | 10.17.11.128/26 |
| Místní testovací server | 10.1.11.10 |
| Virtuální počítač test paprskové virtuální sítě | 10.17.11.132 |
| Podsíť P2P primárního připojení ExpressRoute | 192.168.11.16/30 |
| Podsíť P2P sekundárního připojení ExpressRoute | 192.168.11.20/30 |
| Primární IP adresa partnerského uzlu protokolu BGP brány VPN | 10.17.11.76 |
| Sekundární IP adresa partnerského uzlu protokolu BGP brány VPN | 10.17.11.77 |
| IP adresa partnerského uzlu protokolu BGP místní brány firewall VPN | 192.168.11.88 |
| Primární směrovač CE i/f směrem k IP adrese brány firewall | 192.168.11.0/31 |
| I/f brány firewall směrem k primární IP adrese směrovače CE | 192.168.11.1/31 |
| Sekundární směrovač CE i/f směrem k IP adrese brány firewall | 192.168.11.2/31 |
| Ip adresa brány firewall směrem k sekundárnímu směrovači CE | 192.168.11.3/31 |
Následující tabulka uvádí názvy ASN topologie:
| Autonomní systém | ASN |
|---|---|
| Místní | 65020 |
| Microsoft Enterprise Edge | 12076 |
| GW virtuální sítě (ExR) | 65515 |
| GW virtuální sítě (VPN) | 65515 |
Vysoká dostupnost bez asymetrie
Konfigurace pro zajištění vysoké dostupnosti
Článek Konfigurace společně existujících připojení ExpressRoute a Site-to-Site vysvětluje, jak nastavit spoluexistující připojení ExpressRoute a S2S VPN. Jak jsme zmínili v návrhu pro zajištění vysoké dostupnosti pomocí ExpressRoute, naše nastavení zajišťuje redundanci sítě, která eliminuje jakýkoli kritický bod selhání až do koncových bodů, což zlepšuje vysokou dostupnost ExpressRoute. Kromě toho jsou primární i sekundární připojení okruhů ExpressRoute aktivní a inzerují místní předpony stejným způsobem prostřednictvím obou připojení.
Inzerování místní trasy primárního směrovače CE prostřednictvím primárního připojení okruhu ExpressRoute se zobrazí takto (příkazy Junos):
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
Inzerování místní trasy sekundárního směrovače CE prostřednictvím sekundárního připojení okruhu ExpressRoute se zobrazí takto (příkazy Junos):
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
Aby se zlepšila vysoká dostupnost připojení zálohování, síť VPN S2S je také nakonfigurovaná v režimu aktivní-aktivní. Konfigurace služby Azure VPN Gateway se zobrazí následovně. Všimněte si, že v rámci konfigurace sítě VPN vpn jsou uvedené také IP adresy partnerského uzlu protokolu BGP brány --10.17.11.76 a 10.17.11.77.
Místní trasa se inzeruje bránou firewall primárnímu a sekundárnímu partnerskému vztahu protokolu BGP brány VPN. Inzerce tras se zobrazují takto (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
Poznámka:
Konfigurace sítě VPN S2S v režimu aktivní-aktivní poskytuje nejen vysokou dostupnost připojení k síti zálohování zotavení po havárii, ale také poskytuje vyšší propustnost připojení k zálohování. Proto se doporučuje nakonfigurovat síť VPN typu S2S v režimu aktivní-aktivní, protože vytvoří více podkladových tunelů.
Konfigurace pro symetrický tok provozu
Poznamenali jsme, že když se daná místní trasa inzeruje prostřednictvím ExpressRoute i S2S VPN, Azure by preferovala cestu ExpressRoute. Pokud chcete, aby Azure preferuje cestu VPN typu S2S před existující službou ExpressRoute, musíte prostřednictvím připojení VPN inzerovat konkrétnější trasy (delší předponu s větší maskou podsítě). Naším cílem je použít připojení VPN pouze jako zálohování. Výchozí chování výběru cesty v Azure je tedy v souladu s naším cílem.
Je naší zodpovědností zajistit, aby provoz směřující do Azure z místního prostředí preferoval také cestu ExpressRoute přes síť VPN typu Site-to-Site. Výchozí místní předvolba směrovačů a bran firewall CE v našem místním nastavení je 100. Konfigurace místní předvolby tras přijatých prostřednictvím privátních partnerských vztahů ExpressRoute větší než 100 tedy můžeme nastavit provoz určený pro Azure jako preferovaný okruh ExpressRoute.
Konfigurace protokolu BGP primárního směrovače CE, který ukončuje primární připojení okruhu ExpressRoute, je znázorněno takto. Všimněte si, že hodnota místní předvolby tras inzerovaných v relaci iBGP je nakonfigurovaná tak, aby byla 150. Podobně musíme zajistit místní předvolbu sekundárního směrovače CE, který ukončí sekundární připojení okruhu ExpressRoute, je také nakonfigurováno na 150.
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;
}
}
}
Směrovací tabulka místních bran firewall potvrzuje, že pro místní provoz, který je určený do Azure, je upřednostňovaná cesta přes ExpressRoute v stabilním stavu.
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
Ve výše uvedené směrovací tabulce pro hvězdicové trasy virtuální sítě –-10.17.11.0/25 a 10.17.11.128/26 –-vidíme, že okruh ExpressRoute je upřednostňovaný před připojeními VPN. 192.168.11.0 a 192.168.11.2 jsou IP adresy na rozhraní brány firewall směrem ke směrovačům CE.
Ověření výměny tras přes S2S VPN
Dříve v tomto článku jsme ověřili inzerování místních tras bran firewall na primární a sekundární partnerské vztahy protokolu BGP brány VPN. Dále ověříme trasy Azure přijaté branami firewall z primárních a sekundárních partnerských uzlů protokolu BGP brány VPN.
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
Podobně ověříme předpony místních síťových tras přijatých bránou Azure VPN Gateway.
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
Jak jsme viděli dříve, brána VPN má trasy přijaté primárním i sekundárním partnerskými vztahy protokolu BGP brány VPN. Má také přehled o trasách přijatých prostřednictvím primárních a sekundárních připojení ExpressRoute (ty s předem oddělenou cestou AS s 12076). Abychom potvrdili, že trasy přijaté prostřednictvím připojení VPN, musíme znát místní IP adresu partnerského uzlu protokolu BGP připojení. V našem nastavení je ip adresa 192.168.11.88 a vidíme, že z ní byly přijaty trasy.
Dále ověříme trasy inzerované službou Azure VPN Gateway pro místní partnerský vztah protokolu BGP brány firewall (192.168.11.88).
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
Selhání zobrazení výměn tras značí selhání připojení. Viz Řešení potíží: Připojení VPN typu Site-to-Site Azure se nemůže připojit a přestane fungovat s řešením potíží s připojením VPN.
Testování převzetí služeb při selhání
Teď, když jsme potvrdili úspěšné výměny tras přes připojení VPN (řídicí rovina), jsme nastavili přepnutí provozu (roviny dat) z připojení ExpressRoute k připojení VPN.
Poznámka:
V produkčních prostředích je potřeba provést testování převzetí služeb při selhání během naplánované pracovní doby údržby sítě, protože to může být rušivé.
Před přepnutím provozu trasujeme aktuální cestu v naší instalaci z místního testovacího serveru na testovací virtuální počítač v paprskové virtuální síti.
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.
Primární a sekundární podsítě připojení ExpressRoute typu point-to-point našeho nastavení jsou 192.168.11.16/30 a 192.168.11.20/30. Ve výše uvedené trasovací trase vidíme v kroku 3, že dosáhneme 192.168.11.18, což je IP adresa rozhraní primárního MSEE. Přítomnost rozhraní MSEE potvrzuje, že podle očekávání se naše aktuální cesta nachází přes ExpressRoute.
Jak je uvedeno v resetování partnerských vztahů okruhů ExpressRoute, pojďme pomocí následujících příkazů PowerShellu zakázat primární i sekundární partnerský vztah okruhu ExpressRoute.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Doba přepnutí převzetí služeb při selhání závisí na času konvergence protokolu BGP. V našem nastavení trvá přepnutí převzetí služeb při selhání několik sekund (méně než 10). Po přepnutí se opakováním traceroute zobrazí následující cesta:
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.
Výsledek traceroute potvrzuje, že je připojení zálohování přes S2S VPN aktivní a může poskytovat kontinuitu služeb, pokud primární i sekundární připojení ExpressRoute selžou. K dokončení testování převzetí služeb při selhání povolíme připojení ExpressRoute zpět a normalizujeme tok provozu pomocí následující sady příkazů.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Pokud chcete ověřit, že se provoz přepne zpět na ExpressRoute, zopakujte trasování a ujistěte se, že prochází privátním partnerským vztahem ExpressRoute.
Další kroky
ExpressRoute je navržený pro vysokou dostupnost bez jediného bodu selhání v síti Microsoftu. Okruh ExpressRoute je stále omezen na jednu geografickou oblast a na poskytovatele služeb. S2S VPN může být dobrým řešením pasivního zálohování zotavení po havárii do okruhu ExpressRoute. Pro spolehlivé řešení pasivního zálohování je důležitá pravidelná údržba pasivní konfigurace a pravidelné ověřování připojení. Není nutné nechat konfiguraci sítě VPN zastaralou a pravidelně (například každé čtvrtletí) opakovat kroky ověření a testu převzetí služeb při selhání popsané v tomto článku během časového období údržby.
Pokud chcete povolit monitorování a výstrahy na základě metrik brány VPN, přečtěte si téma Nastavení upozornění na metriky služby VPN Gateway.
Pokud chcete urychlit konvergenci protokolu BGP po selhání ExpressRoute, nakonfigurujte BFD přes ExpressRoute.