Używanie sieci VPN typu lokacja-lokacja jako kopii zapasowej prywatnej komunikacji równorzędnej usługi ExpressRoute
W artykule zatytułowanym Projektowanie na potrzeby odzyskiwania po awarii za pomocą prywatnej komunikacji równorzędnej usługi ExpressRoute omówiliśmy potrzebę rozwiązania łączności z kopiami zapasowymi podczas korzystania z prywatnej komunikacji równorzędnej usługi ExpressRoute. Omówiliśmy również sposób korzystania z geograficznie nadmiarowych obwodów usługi ExpressRoute w celu zapewnienia wysokiej dostępności. W tym artykule wyjaśniono, jak używać i obsługiwać sieć VPN typu lokacja-lokacja (S2S) jako kopię zapasową prywatnej komunikacji równorzędnej usługi ExpressRoute.
Uwaga
Używanie sieci VPN typu lokacja-lokacja jako rozwiązania do tworzenia kopii zapasowych dla łączności usługi ExpressRoute nie jest zalecane w przypadku obsługi obciążeń wymagających opóźnień, krytycznych lub intensywnie korzystających z przepustowości. W takich przypadkach zaleca się zaprojektowanie odzyskiwania po awarii przy użyciu odporności usługi ExpressRoute z wieloma lokacjami w celu zapewnienia maksymalnej dostępności.
W przeciwieństwie do geograficznie nadmiarowych obwodów usługi ExpressRoute można używać tylko kombinacji odzyskiwania po awarii usługi ExpressRoute i sieci VPN w konfiguracji aktywne-pasywnej. Głównym wyzwaniem korzystania z łączności sieciowej kopii zapasowej w trybie pasywnym jest to, że połączenie pasywne często kończy się niepowodzeniem wraz z połączeniem podstawowym. Częstą przyczyną awarii połączenia pasywnego jest brak aktywnej konserwacji. W związku z tym w tym artykule skupimy się na tym, jak weryfikować i aktywnie obsługiwać łączność sieci VPN typu lokacja-lokacja, która tworzy kopię zapasową prywatnej komunikacji równorzędnej usługi ExpressRoute.
Uwaga
Gdy dana trasa jest anonsowana zarówno za pośrednictwem usługi ExpressRoute, jak i sieci VPN, platforma Azure preferuje routing za pośrednictwem usługi ExpressRoute.
Z tego artykułu dowiesz się również, jak zweryfikować łączność zarówno z perspektywy platformy Azure, jak i po stronie brzegowej sieci lokalnej. Możliwość weryfikacji po obu stronach pomaga niezależnie od tego, czy zarządzasz lokalnymi urządzeniami sieciowymi, które są równorzędne z jednostkami sieciowymi firmy Microsoft.
Przykładowa topologia
W naszej konfiguracji mamy sieć lokalną połączoną z siecią wirtualną koncentratora platformy Azure za pośrednictwem obwodu usługi ExpressRoute i połączenia sieci VPN typu lokacja-lokacja. Sieć wirtualna koncentratora platformy Azure jest z kolei równorzędna z siecią wirtualną szprych, jak pokazano na diagramie:
W konfiguracji obwód usługi ExpressRoute jest przerywany na dwóch routerach brzegowych klienta (CE) w środowisku lokalnym. Lokalna sieć LAN jest połączona z routerami CE z parą zapór działających w trybie lidera. Sieć VPN S2S jest bezpośrednio przerywana na zaporach.
W poniższej tabeli wymieniono kluczowe prefiksy adresów IP topologii:
| Encja | Prefiks |
|---|---|
| Lokalna sieć LAN | 10.1.11.0/25 |
| Sieć wirtualna usługi Azure Hub | 10.17.11.0/25 |
| Sieć wirtualna będącej szprychą platformy Azure | 10.17.11.128/26 |
| Lokalny serwer testowy | 10.1.11.10 |
| Maszyna wirtualna testowa sieci wirtualnej będącej szprychą | 10.17.11.132 |
| Podsieć P2P połączenia podstawowego usługi ExpressRoute | 192.168.11.16/30 |
| Podsieć P2P połączenia pomocniczego usługi ExpressRoute | 192.168.11.20/30 |
| Podstawowy adres IP elementu równorzędnego protokołu BGP bramy sieci VPN | 10.17.11.76 |
| Pomocniczy adres IP elementu równorzędnego protokołu BGP bramy sieci VPN | 10.17.11.77 |
| Lokalny adres IP elementu równorzędnego protokołu BGP zapory sieci VPN | 192.168.11.88 |
| Podstawowy router CE i/f w kierunku adresu IP zapory | 192.168.11.0/31 |
| Zapora i/f w kierunku podstawowego adresu IP routera CE | 192.168.11.1/31 |
| Pomocniczy router CE i/f w kierunku adresu IP zapory | 192.168.11.2/31 |
| Zapora i/f w kierunku pomocniczego adresu IP routera CE | 192.168.11.3/31 |
W poniższej tabeli wymieniono numery ASN topologii:
| System autonomiczny | ASN |
|---|---|
| Lokalne | 65020 |
| Microsoft Enterprise Edge | 12076 |
| Brama sieci wirtualnej (ExR) | 65515 |
| Brama sieci wirtualnej (VPN) | 65515 |
Wysoka dostępność bez asymetryczności
Konfigurowanie pod kątem wysokiej dostępności
W artykule Configure ExpressRoute and Site-to-Site coexisting connections (Konfigurowanie współistniejących połączeń usługi ExpressRoute i połączeń sieci VPN typu lokacja-lokacja) wyjaśniono, jak skonfigurować współistniejące połączenia sieci VPN usługi ExpressRoute i połączenia typu lokacja-lokacja. Jak wspomniano w artykule Projektowanie pod kątem wysokiej dostępności za pomocą usługi ExpressRoute, nasza konfiguracja zapewnia nadmiarowość sieci w celu wyeliminowania dowolnego pojedynczego punktu awarii do punktów końcowych, co zwiększa wysoką dostępność usługi ExpressRoute. Ponadto zarówno podstawowe, jak i pomocnicze połączenia obwodów usługi ExpressRoute są aktywne i anonsują lokalne prefiksy w ten sam sposób za pośrednictwem obu połączeń.
Lokalne anonsowanie trasy podstawowego routera CE za pośrednictwem podstawowego połączenia obwodu usługi ExpressRoute jest wyświetlane w następujący sposób (polecenia 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
Lokalne anonsowanie trasy pomocniczego routera CE za pośrednictwem pomocniczego połączenia obwodu usługi ExpressRoute jest wyświetlane w następujący sposób (polecenia 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 zwiększyć wysoką dostępność połączenia kopii zapasowej, sieć VPN typu lokacja-lokacja jest również skonfigurowana w trybie aktywny-aktywny. Konfiguracja bramy sieci VPN platformy Azure jest wyświetlana w następujący sposób. Należy pamiętać, że w ramach konfiguracji sieci VPN adresy IP elementu równorzędnego protokołu BGP bramy--10.17.11.76 i 10.17.11.77-- są również wymienione.
Trasa lokalna jest anonsowana przez zaporę do podstawowych i pomocniczych elementów równorzędnych protokołu BGP bramy sieci VPN. Anonse tras są wyświetlane w następujący sposób (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
Uwaga
Skonfigurowanie sieci VPN typu lokacja-lokacja w trybie aktywne-aktywne nie tylko zapewnia wysoką dostępność łączności sieciowej kopii zapasowej odzyskiwania po awarii, ale także zapewnia większą przepływność łączności kopii zapasowej. Dlatego skonfigurowanie sieci VPN typu lokacja-lokacja w trybie aktywne-aktywne jest zalecane, ponieważ spowoduje utworzenie wielu tuneli bazowych.
Konfigurowanie przepływu ruchu symetrycznego
Zauważyliśmy, że jeśli dana trasa lokalna jest anonsowana zarówno za pośrednictwem sieci VPN expressRoute, jak i S2S, platforma Azure wolałaby ścieżkę usługi ExpressRoute. Aby wymusić na platformie Azure preferowanie ścieżki sieci VPN S2S przez współistniejącą usługę ExpressRoute, musisz anonsować bardziej szczegółowe trasy (dłuższy prefiks z większą maską podsieci) za pośrednictwem połączenia sieci VPN. Naszym celem jest użycie połączeń sieci VPN tylko jako kopii zapasowej. Dlatego domyślne zachowanie wyboru ścieżki platformy Azure jest zgodne z naszym celem.
Naszym zadaniem jest zapewnienie, że ruch kierowany do platformy Azure ze środowiska lokalnego preferuje również ścieżkę usługi ExpressRoute za pośrednictwem sieci VPN typu lokacja-lokacja. Domyślną preferencją lokalną routerów CE i zapór w naszej konfiguracji lokalnej jest 100. Dlatego skonfigurowanie preferencji lokalnych tras, które są odbierane za pośrednictwem prywatnej komunikacji równorzędnej usługi ExpressRoute większej niż 100, możemy sprawić, że ruch przeznaczony dla platformy Azure preferuje obwód usługi ExpressRoute.
Konfiguracja protokołu BGP podstawowego routera CE, który przerywa podstawowe połączenie obwodu usługi ExpressRoute, jest pokazany w następujący sposób. Zwróć uwagę, że wartość preferencji lokalnej tras anonsowanych w sesji iBGP jest skonfigurowana na 150. Podobnie musimy zapewnić lokalną preferencję pomocniczego routera CE, który przerywa połączenie pomocnicze obwodu usługi ExpressRoute jest również skonfigurowany jako 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;
}
}
}
Tabela routingu zapór lokalnych potwierdza, że w przypadku ruchu lokalnego przeznaczonego do platformy Azure preferowana ścieżka odbywa się za pośrednictwem usługi ExpressRoute w stanie stałym.
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
W powyższej tabeli tras dla tras sieci wirtualnej piasty i szprych --10.17.11.0/25 i 10.17.11.128/26- widzimy, że obwód usługi ExpressRoute jest preferowany za pośrednictwem połączeń sieci VPN. Adresy IP 192.168.11.0 i 192.168.11.2 są adresami IP w interfejsie zapory dla routerów CE.
Walidacja wymiany tras za pośrednictwem sieci VPN typu lokacja-lokacja
Wcześniej w tym artykule zweryfikowaliśmy lokalne anonsowanie tras zapory do podstawowych i pomocniczych elementów równorzędnych protokołu BGP bramy sieci VPN. Ponadto potwierdźmy trasy platformy Azure odebrane przez zapory z podstawowych i pomocniczych elementów równorzędnych protokołu BGP bramy sieci 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
Podobnie sprawdźmy, czy lokalne prefiksy tras sieciowych odebrane przez bramę sieci VPN platformy Azure.
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 pokazano wcześniej, brama sieci VPN ma trasy odebrane zarówno przez podstawowe, jak i pomocnicze elementy równorzędne protokołu BGP bramy sieci VPN. Ma również wgląd w trasy odebrane za pośrednictwem połączeń podstawowych i pomocniczych usługi ExpressRoute (z ścieżką AS poprzedzaną numerem 12076). Aby potwierdzić trasy odebrane za pośrednictwem połączeń sieci VPN, musimy znać lokalny adres IP komunikacji równorzędnej BGP połączeń. W ramach naszej konfiguracji adres IP to 192.168.11.88 i widzimy odebrane z niej trasy.
Następnie zweryfikujmy trasy anonsowane przez bramę sieci VPN platformy Azure do lokalnego elementu równorzędnego protokołu BGP zapory (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
Nie można wyświetlić wymiany tras wskazują błąd połączenia. Zobacz Rozwiązywanie problemów: połączenie sieci VPN typu lokacja-lokacja platformy Azure nie może nawiązać połączenia i przestaje działać , aby uzyskać pomoc dotyczącą rozwiązywania problemów z połączeniem sieci VPN.
Testowanie trybu failover
Po potwierdzeniu pomyślnej wymiany tras za pośrednictwem połączenia sieci VPN (płaszczyzny sterowania) ustawiono przełącznik ruchu (płaszczyzny danych) z łączności usługi ExpressRoute z łącznością sieci VPN.
Uwaga
W środowiskach produkcyjnych testy trybu failover muszą być wykonywane podczas zaplanowanego okna roboczego konserwacji sieci, ponieważ może to być zakłócające działanie usługi.
Przed przełączenie ruchu prześledźmy bieżącą ścieżkę w naszej konfiguracji z lokalnego serwera testowego do testowej maszyny wirtualnej w sieci wirtualnej będącej szprychą.
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.
Podstawowe i pomocnicze podsieci połączeń punkt-punkt usługi ExpressRoute są odpowiednio 192.168.11.16/30 i 192.168.11.20/30. W powyższej trasie śledzenia w kroku 3 widzimy, że osiągamy wartość 192.168.11.18, czyli adres IP interfejsu podstawowego protokołu MSEE. Obecność interfejsu MSEE potwierdza, że zgodnie z oczekiwaniami nasza bieżąca ścieżka jest w usłudze ExpressRoute.
Zgodnie z raportami w artykule Resetuj komunikację równorzędną obwodu usługi ExpressRoute użyjmy następujących poleceń programu PowerShell, aby wyłączyć zarówno podstawową, jak i pomocniczą komunikację równorzędną obwodu usługi ExpressRoute.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Czas przełączania trybu failover zależy od czasu zbieżności protokołu BGP. W naszej konfiguracji przełączenie trybu failover trwa kilka sekund (mniej niż 10). Po przełączeniu powtórzenie ścieżki traceroute pokazuje następującą ścieżkę:
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.
Wynik traceroute potwierdza, że połączenie kopii zapasowej za pośrednictwem sieci VPN S2S jest aktywne i może zapewnić ciągłość usługi, jeśli zarówno podstawowe, jak i pomocnicze połączenia usługi ExpressRoute kończą się niepowodzeniem. Aby ukończyć testowanie trybu failover, włączmy połączenia usługi ExpressRoute z powrotem i znormalizowamy przepływ ruchu przy użyciu następującego zestawu poleceń.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Aby potwierdzić, że ruch jest przełączany z powrotem do usługi ExpressRoute, powtórz usługę traceroute i upewnij się, że przechodzi ona przez prywatną komunikację równorzędną usługi ExpressRoute.
Następne kroki
Usługa ExpressRoute została zaprojektowana pod kątem wysokiej dostępności bez pojedynczego punktu awarii w sieci firmy Microsoft. Nadal obwód usługi ExpressRoute jest ograniczony do jednego regionu geograficznego i do dostawcy usług. Sieć VPN S2S może być dobrym rozwiązaniem do pasywnego odzyskiwania po awarii w obwodzie usługi ExpressRoute. W przypadku możliwego do utrzymania pasywnego rozwiązania do tworzenia kopii zapasowych należy regularnie konserwację konfiguracji pasywnej i okresową walidację połączenia. Ważne jest, aby konfiguracja sieci VPN stała się nieaktualna i okresowo (powiedzmy co kwartał) powtarzać kroki weryfikacji i testu trybu failover opisane w tym artykule podczas okna obsługi.
Aby włączyć monitorowanie i alerty na podstawie metryk bramy sieci VPN, zobacz Konfigurowanie alertów dotyczących metryk usługi VPN Gateway.
Aby przyspieszyć zbieżność protokołu BGP po niepowodzeniu usługi ExpressRoute, skonfiguruj BFD za pośrednictwem usługi ExpressRoute.