Använda S2S VPN som en säkerhetskopia för privat ExpressRoute-peering
I artikeln Designing for disaster recovery with ExpressRoute private peering (Designa för haveriberedskap med privat ExpressRoute-peering) diskuterade vi behovet av en lösning för säkerhetskopieringsanslutning när du använder privat ExpressRoute-peering. Vi diskuterade också hur du använder geo-redundanta ExpressRoute-kretsar för hög tillgänglighet. I den här artikeln förklarar vi hur du använder och underhåller ett plats-till-plats-VPN (S2S) som en säkerhetskopia för privat ExpressRoute-peering.
Kommentar
Användning av plats-till-plats-VPN som en säkerhetskopieringslösning för ExpressRoute-anslutning rekommenderas inte när du hanterar svarstidskänsliga, verksamhetskritiska eller bandbreddsintensiva arbetsbelastningar. I sådana fall rekommenderar vi att du utformar för haveriberedskap med ExpressRoute-återhämtning på flera platser för att säkerställa maximal tillgänglighet.
Till skillnad från geo-redundanta ExpressRoute-kretsar kan du bara använda en kombination av expressroute- och VPN-haveriberedskap i en aktiv-passiv installation. En stor utmaning med att använda nätverksanslutningar för säkerhetskopiering i passivt läge är att den passiva anslutningen ofta misslyckas tillsammans med den primära anslutningen. Den vanliga orsaken till felen i den passiva anslutningen är bristen på aktivt underhåll. Därför ligger fokus i den här artikeln på hur du verifierar och aktivt upprätthåller en S2S VPN-anslutning som säkerhetskopierar en privat ExpressRoute-peering.
Kommentar
När en viss väg annonseras via både ExpressRoute och VPN föredrar Azure routning framför ExpressRoute.
I den här artikeln får du också lära dig hur du verifierar anslutningen från både Azure-perspektivet och den lokala nätverksgränsen. Möjligheten att verifiera från båda sidor hjälper oavsett om du hanterar de lokala nätverksenheter som är peer-kopplade till Microsofts nätverksentiteter eller inte.
Exempeltopologi
I vår konfiguration har vi ett lokalt nätverk som är anslutet till ett virtuellt Azure Hub-nätverk via både en ExpressRoute-krets och en S2S VPN-anslutning. Det virtuella Azure Hub-nätverket är i sin tur peer-kopplat till ett virtuellt ekernätverk, enligt diagrammet:
I installationen avslutas ExpressRoute-kretsen på ett par CE-routrar (Customer Edge) lokalt. Det lokala LAN:et är anslutet till CE-routrarna med ett par brandväggar som fungerar i leader-follower-läge. S2S VPN avslutas direkt i brandväggarna.
I följande tabell visas topologins nyckel-IP-prefix:
| Enhet | Prefix |
|---|---|
| Lokalt LAN | 10.1.11.0/25 |
| Virtuellt Azure Hub-nätverk | 10.17.11.0/25 |
| Virtuellt Azure-ekernätverk | 10.17.11.128/26 |
| Lokal testserver | 10.1.11.10 |
| Virtuell ekernätverkstest-VM | 10.17.11.132 |
| P2P-undernät för primär ExpressRoute-anslutning | 192.168.11.16/30 |
| ExpressRoute sekundär anslutning P2P-undernät | 192.168.11.20/30 |
| PRIMÄR BGP-peer-IP för VPN-gateway | 10.17.11.76 |
| SEKUNDÄR BGP-peer-IP för VPN-gateway | 10.17.11.77 |
| Vpn BGP-peer-IP för lokal brandvägg | 192.168.11.88 |
| Primär CE-router i/f mot brandväggs-IP | 192.168.11.0/31 |
| Brandvägg i/f mot primär CE-router-IP | 192.168.11.1/31 |
| Sekundär CE-router i/f mot brandväggs-IP | 192.168.11.2/31 |
| Brandvägg i/f mot sekundär CE-router-IP | 192.168.11.3/31 |
I följande tabell visas ASN:erna för topologin:
| Autonomt system | ASN |
|---|---|
| Lokal | 65020 |
| Microsoft Enterprise Edge | 12076 |
| Virtual Network GW (ExR) | 65515 |
| Virtual Network GW (VPN) | 65515 |
Hög tillgänglighet utan asymmetriskhet
Konfigurera för hög tillgänglighet
I artikeln Konfigurera expressroute- och plats-till-plats-samexisterande anslutningar förklaras hur du konfigurerar samexisterande ExpressRoute- och S2S VPN-anslutningar. Som vi nämnde i Designa för hög tillgänglighet med ExpressRoute säkerställer vår konfiguration nätverksredundans för att eliminera varje enskild felpunkt upp till slutpunkterna, vilket förbättrar ExpressRoutes höga tillgänglighet. Dessutom är både de primära och sekundära anslutningarna för ExpressRoute-kretsarna aktiva och annonserar de lokala prefixen på samma sätt via båda anslutningarna.
Den lokala routningsannonsen för den primära CE-routern via den primära anslutningen för ExpressRoute-kretsen visas på följande sätt (Junos-kommandon):
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
Den lokala routningsannonsen för den sekundära CE-routern via den sekundära anslutningen för ExpressRoute-kretsen visas på följande sätt (Junos-kommandon):
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
För att förbättra den höga tillgängligheten för säkerhetskopieringsanslutningen konfigureras även S2S VPN i aktivt-aktivt läge. Konfigurationen av Azure VPN-gatewayen visas på följande sätt. Observera att BGP-peer-IP-adresserna för gatewayen--10.17.11.76 och 10.17.11.77- också visas som en del av VPN-konfigurations-VPN.
Den lokala vägen annonseras av brandväggen till VPN-gatewayens primära och sekundära BGP-peer-datorer. Vägannonserna visas på följande sätt (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
Kommentar
Att konfigurera S2S VPN i aktivt-aktivt läge ger inte bara hög tillgänglighet till nätverksanslutningen för haveriberedskapssäkerhetskopiering, utan ger också högre dataflöde för säkerhetskopieringsanslutningen. Därför rekommenderas att konfigurera S2S VPN i aktivt-aktivt läge eftersom det skapar flera underliggande tunnlar.
Konfigurera för symmetriskt trafikflöde
Vi noterade att när en viss lokal väg annonseras via både ExpressRoute och S2S VPN föredrar Azure ExpressRoute-sökvägen. För att tvinga Azure att föredra S2S VPN-sökväg framför den samexisterande ExpressRoute måste du annonsera mer specifika vägar (längre prefix med större nätmask) via VPN-anslutningen. Vårt mål är att endast använda VPN-anslutningarna som säkerhetskopiering. Därför är standardbeteendet för val av sökväg i Azure i linje med vårt mål.
Det är vårt ansvar att se till att trafiken till Azure från den lokala miljön också föredrar ExpressRoute-sökvägen framför plats-till-plats-VPN. Den lokala standardinställningen för CE-routrar och brandväggar i vår lokala installation är 100. Genom att konfigurera den lokala inställningen för de vägar som tas emot via de privata ExpressRoute-peeringarna som är större än 100 kan vi därför göra så att trafiken som är avsedd för Azure föredrar ExpressRoute-kretsen.
BGP-konfigurationen för den primära CE-routern som avslutar den primära anslutningen för ExpressRoute-kretsen visas på följande sätt. Observera att värdet för den lokala inställningen för de vägar som annonseras under iBGP-sessionen har konfigurerats till 150. På samma sätt måste vi se till att den lokala inställningen för den sekundära CE-routern som avslutar den sekundära anslutningen för ExpressRoute-kretsen också är konfigurerad att vara 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;
}
}
}
Routningstabellen för de lokala brandväggarna bekräftar att för den lokala trafik som är avsedd för Azure är den föredragna sökvägen över ExpressRoute i stabilt tillstånd.
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
I routningstabellen ovan för de virtuella nätverksvägarna hubb och eker –-10.17.11.0/25 och 10.17.11.128/26 – ser vi att ExpressRoute-kretsen föredras framför VPN-anslutningar. 192.168.11.0 och 192.168.11.2 är IP-adresser i brandväggsgränssnittet mot CE-routrar.
Validering av routningsutbyte via S2S VPN
Tidigare i den här artikeln verifierade vi lokal vägannonsering av brandväggarna till vpn-gatewayens primära och sekundära BGP-peer-datorer. Dessutom ska vi bekräfta att Azure-vägar som tas emot av brandväggarna från VPN-gatewayens primära och sekundära BGP-peer-datorer.
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
På samma sätt ska vi verifiera för lokala nätverksvägsprefix som tas emot av Azure VPN-gatewayen.
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
Som vi såg tidigare har VPN-gatewayen vägar som tagits emot både av vpn-gatewayens primära och sekundära BGP-peer-datorer. Den har också insyn i de vägar som tas emot via primära och sekundära ExpressRoute-anslutningar (de som har AS-sökvägen förberedd med 12076). För att bekräfta de vägar som tas emot via VPN-anslutningar behöver vi känna till den lokala BGP-peer-IP-adressen för anslutningarna. I vår konfiguration är IP-adressen 192.168.11.88 och vi ser de vägar som tas emot från den.
Nu ska vi kontrollera vägarna som annonseras av Azure VPN-gatewayen till den lokala brandväggens BGP-peer (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
Det gick inte att se routningsutbyten som indikerar anslutningsfel. Se Felsökning: En VPN-anslutning från Azure plats till plats kan inte ansluta och slutar fungera för att få hjälp med att felsöka VPN-anslutningen.
Testa redundans
Nu när vi har bekräftat lyckade vägutbyten över VPN-anslutningen (kontrollplanet) är vi inställda på att växla trafik (dataplan) från ExpressRoute-anslutningen till VPN-anslutningen.
Kommentar
I produktionsmiljöer måste redundanstestning utföras under arbetsfönstret för schemalagt nätverksunderhåll eftersom det kan vara tjänststörande.
Innan vi gör trafikväxlingen ska vi spåra den aktuella sökvägen i konfigurationen från den lokala testservern till den virtuella testdatorn i det virtuella ekernätverket.
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.
De primära och sekundära ExpressRoute punkt-till-punkt-anslutningsundernäten för vår konfiguration är 192.168.11.16/30 respektive 192.168.11.20/30. I ovanstående spårningsväg ser vi i steg 3 att vi når 192.168.11.18, vilket är gränssnitts-IP för den primära MSEE:en. Förekomsten av MSEE-gränssnittet bekräftar att vår aktuella sökväg som förväntat är över ExpressRoute.
Som rapporterats i ExpressRoute-kretspeeringarna återställs ska vi använda följande PowerShell-kommandon för att inaktivera både den primära och sekundära peeringen för ExpressRoute-kretsen.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Redundansväxlingstiden beror på BGP-konvergenstiden. I vår konfiguration tar redundansväxlingen några sekunder (mindre än 10). Efter växeln visar upprepningen av traceroute följande sökväg:
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-resultatet bekräftar att säkerhetskopieringsanslutningen via S2S VPN är aktiv och kan ge tjänstkontinuitet om både de primära och sekundära ExpressRoute-anslutningarna misslyckas. För att slutföra redundanstestningen ska vi aktivera ExpressRoute-anslutningarna igen och normalisera trafikflödet med hjälp av följande uppsättning kommandon.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Bekräfta att trafiken växlas tillbaka till ExpressRoute genom att upprepa traceroute och se till att den går via den privata ExpressRoute-peeringen.
Nästa steg
ExpressRoute är utformat för hög tillgänglighet utan en enskild felpunkt i Microsoft-nätverket. Fortfarande är en ExpressRoute-krets begränsad till en enda geografisk region och till en tjänstleverantör. S2S VPN kan vara en bra passiv säkerhetskopieringslösning för haveriberedskap till en ExpressRoute-krets. För en tillförlitlig lösning för passiv säkerhetskopiering är det viktigt med regelbundet underhåll av den passiva konfigurationen och regelbunden validering av anslutningen. Det är viktigt att inte låta VPN-konfigurationen bli inaktuell, och att regelbundet (t.ex. varje kvartal) upprepa de verifierings- och redundansteststeg som beskrivs i den här artikeln under underhållsfönstret.
Information om hur du aktiverar övervakning och aviseringar baserat på VPN Gateway-mått finns i Konfigurera aviseringar för VPN Gateway-mått.
Om du vill påskynda BGP-konvergensen efter ett ExpressRoute-fel konfigurerar du BFD via ExpressRoute.