Uso della VPN da sito a sito come backup per il peering privato di ExpressRoute
Nell'articolo intitolato Progettazione per il ripristino di emergenza con il peering privato di ExpressRoute, è stata illustrata la necessità di una soluzione di connettività di backup quando si usa il peering privato di ExpressRoute. È stato anche illustrato come usare circuiti ExpressRoute con ridondanza geografica per la disponibilità elevata. In questo articolo viene illustrato come usare e gestire una VPN da sito a sito come backup per il peering privato di ExpressRoute.
Nota
L'uso della VPN da sito a sito come soluzione di backup per la connettività ExpressRoute non è consigliato quando si gestiscono carichi di lavoro con distinzione tra latenza, cruciali o a elevato utilizzo di larghezza di banda. In questi casi, è consigliabile progettare per il ripristino di emergenza con resilienza multisito ExpressRoute per garantire la massima disponibilità.
A differenza dei circuiti ExpressRoute con ridondanza geografica, è possibile usare la combinazione di ExpressRoute e VPN per il ripristino di emergenza solo in una configurazione attiva-passiva. Uno dei problemi principali dell'uso di una connettività di rete di backup in modalità passiva è che la connessione passiva spesso ha esito negativo insieme alla connessione primaria. La causa comune degli errori della connessione passiva è la mancanza di manutenzione attiva. Pertanto, in questo articolo ci si concentra su come verificare e mantenere attivamente una connettività VPN da sito a sito che esegue il backup di un peering privato di ExpressRoute.
Nota
Quando una determinata route viene annunciata sia tramite ExpressRoute che tramite VPN, Azure preferisce il routing su ExpressRoute.
Questo articolo illustra anche come verificare la connettività sia dal punto di vista di Azure che dal lato perimetrale della rete locale. La possibilità di eseguire la convalida da entrambi i lati è utile indipendentemente dal fatto che si gestiscano o meno i dispositivi di rete locali che eseguano il peering con le entità di rete Microsoft.
Topologia di esempio
Nella configurazione di esempio è presente una rete locale connessa a una rete virtuale dell'hub di Azure tramite un circuito ExpressRoute e una connessione VPN da sito a sito. La rete virtuale dell'hub di Azure è a sua volta connessa tramite peering a una rete virtuale spoke, come illustrato nella figura seguente:
Nella configurazione, il circuito ExpressRoute viene terminato su una coppia di router perimetrali del cliente (CE) in locale. La rete LAN locale è connessa ai router CE con una coppia di firewall che operano in modalità leader-follower. La VPN da sito a sito viene terminata direttamente nei firewall.
Nella tabella seguente sono elencati i prefissi IP chiave della topologia:
| Entità | Prefix |
|---|---|
| Rete LAN locale | 10.1.11.0/25 |
| Rete virtuale dell'hub di Azure | 10.17.11.0/25 |
| Rete virtuale spoke di Azure | 10.17.11.128/26 |
| Server di test locale | 10.1.11.10 |
| Macchina virtuale di test della rete virtuale spoke | 10.17.11.132 |
| Subnet P2P della connessione primaria ExpressRoute | 192.168.11.16/30 |
| Subnet P2P della connessione secondaria ExpressRoute | 192.168.11.20/30 |
| Indirizzo IP peer BGP primario del gateway VPN | 10.17.11.76 |
| Indirizzo IP peer BGP secondario del gateway VPN | 10.17.11.77 |
| Indirizzo IP peer BGP del firewall locale | 192.168.11.88 |
| Interfaccia del router CE primario verso l'indirizzo IP del firewall | 192.168.11.0/31 |
| Interfaccia del firewall verso l'indirizzo IP del router CE primario | 192.168.11.1/31 |
| Interfaccia del router CE secondario verso l'indirizzo IP del firewall | 192.168.11.2/31 |
| Interfaccia del firewall verso l'indirizzo IP del router CE secondario | 192.168.11.3/31 |
Nella tabella seguente sono elencati gli ASN della topologia:
| Sistema autonomo | ASN |
|---|---|
| Locale | 65020 |
| Microsoft Enterprise Edge | 12076 |
| Gateway di rete virtuale (ExR) | 65515 |
| Gateway di rete virtuale (VPN) | 65515 |
Disponibilità elevata senza asimmetria
Configurazione per la disponibilità elevata
L'articolo Configurare connessioni coesistenti ExpressRoute e da sito a sito illustra come configurare connessioni ExpressRoute e da sito a sito coesistenti. Come accennato in Progettazione per la disponibilità elevata con ExpressRoute, la configurazione garantisce la ridondanza della rete per eliminare qualsiasi singolo punto di guasto fino agli endpoint, migliorando la disponibilità elevata di ExpressRoute. Inoltre, sia le connessioni primarie che secondarie dei circuiti ExpressRoute sono attive e annunciano i prefissi locali nello stesso modo tramite entrambe le connessioni.
L'annuncio della route locale del router CE primario tramite la connessione primaria del circuito ExpressRoute viene visualizzato come segue (comandi 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
L'annuncio della route locale del router CE secondario tramite la connessione secondaria del circuito ExpressRoute viene visualizzato come segue (comandi 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
Per migliorare la disponibilità elevata della connessione di backup, la VPN da sito a sito è configurata anche in modalità attiva-attiva. La configurazione del gateway VPN di Azure è illustrata di seguito. Nella configurazione della VPN sono elencati anche gli indirizzi IP dei peer BGP del gateway, 10.17.11.76 e 10.17.11.77.
La route locale viene annunciata dal firewall ai peer BGP primari e secondari del gateway VPN. Gli annunci di route vengono visualizzati come segue (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
Nota
La configurazione della VPN da sito a sito in modalità attiva-attiva non solo offre disponibilità elevata per la connettività di rete di backup del ripristino di emergenza, ma offre anche una velocità effettiva più elevata per la connettività di backup. Pertanto, la configurazione della VPN da sito a sito in modalità attiva-attiva è consigliata perché creerà più tunnel sottostanti.
Configurazione per un flusso di traffico simmetrico
Si è notato che quando viene annunciata una determinata route locale tramite ExpressRoute e VPN da sito a sito, Azure preferisce il percorso ExpressRoute. Per forzare Azure a preferire il percorso VPN da sito a sito rispetto a ExpressRoute coesistente, è necessario annunciare route più specifiche (prefisso più lungo con subnet mask più grande) tramite la connessione VPN. L'obiettivo è usare le connessioni VPN solo come backup. Il comportamento di selezione del percorso predefinito di Azure è quindi in linea con l'obiettivo.
È nostra responsabilità garantire che anche il traffico destinato ad Azure dall'ambiente locale preferisca il percorso ExpressRoute rispetto alla VPN da sito a sito. La preferenza locale predefinita dei router CE e dei firewall nella configurazione locale è 100. Configurando quindi la preferenza locale delle route ricevute tramite i peering privati di ExpressRoute maggiori di 100, è possibile far sì che il traffico destinato ad Azure preferisca il circuito ExpressRoute.
La configurazione BGP del router CE primario che termina la connessione primaria del circuito ExpressRoute è illustrata di seguito. Si noti che il valore della preferenza locale delle route annunciate sulla sessione iBGP è configurato su 150. Analogamente, è necessario assicurarsi che anche la preferenza locale del router CE secondario che termina la connessione secondaria del circuito ExpressRoute sia configurata su 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;
}
}
}
La tabella di routing dei firewall locali conferma che per il traffico locale destinato ad Azure il percorso preferito è su ExpressRoute nello stato stabile.
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
Nella tabella di routing precedente, per le route della rete virtuale hub e spoke, 10.17.11.0/25 e 10.17.11.128/26, si noterà che il circuito ExpressRoute è preferito rispetto alle connessioni VPN. 192.168.11.0 e 192.168.11.2 sono indirizzi IP sull'interfaccia del firewall verso i router CE.
Convalida dello scambio di route tramite VPN da sito a sito
In precedenza in questo articolo è stato verificato l'annuncio delle route locali dei firewall ai peer BGP primari e secondari del gateway VPN. È anche possibile confermare le route di Azure ricevute dai firewall dai peer BGP primari e secondari del gateway 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
Analogamente, verificare i prefissi di route di rete locali ricevuti dal gateway VPN di 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
Come illustrato in precedenza, il gateway VPN ha route ricevute sia dai peer BGP primari che secondari del gateway VPN. Ha anche visibilità sulle route ricevute tramite connessioni ExpressRoute primarie e secondarie (quelle con percorso AS preceduto da 12076). Per confermare le route ricevute tramite connessioni VPN, è necessario conoscere l'indirizzo IP del peer BGP locale delle connessioni. Nella configurazione in esame, l'indirizzo IP è 192.168.11.88 e vengono visualizzate le route da esso ricevute.
Verificare quindi le route annunciate dal gateway VPN di Azure al peer BGP del firewall locale (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
La mancata visualizzazione degli scambi di route indica un errore di connessione. Vedere Risoluzione dei problemi: una connessione VPN da sito a sito di Azure non può connettersi e smette di funzionare per informazioni sulla risoluzione dei problemi della connessione VPN.
Test del failover
Dopo aver verificato la riuscita degli scambi di route tramite la connessione VPN (piano di controllo),è possibile trasferire il traffico (piano dati) dalla connettività ExpressRoute alla connettività VPN.
Nota
Negli ambienti di produzione i test di failover devono essere eseguiti durante le finestre di lavoro della manutenzione di rete pianificata, perché possono verificarsi interruzioni del servizio.
Prima di eseguire il trasferimento del traffico, tracciare il percorso corrente nella configurazione dal server di test locale alla macchina virtuale di test nella rete virtuale spoke.
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.
Le subnet di connessione da punto a punto ExpressRoute primaria e secondaria della configurazione sono rispettivamente 192.168.11.16/30 e 192.168.11.20/30. Nel tracciamento delle route precedente, nel passaggio 3 si noterà che si sta raggiungendo 192.168.11.18, che è l'indirizzo IP dell'interfaccia MSEE primaria. La presenza dell'interfaccia MSEE conferma che, come previsto, il percorso corrente si trova su ExpressRoute.
Come indicato nell'articolo Reimpostare i peering del circuito ExpressRoute, usare i comandi di PowerShell seguenti per disabilitare il peering primario e secondario del circuito ExpressRoute.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Il tempo di commutazione del failover dipende dal tempo di convergenza BGP. Nella configurazione di esempio, la commutazione del failover richiede pochi secondi (meno di 10). Dopo la commutazione, la ripetizione del comando traceroute mostra il percorso seguente:
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.
Il risultato di traceroute conferma che la connessione di backup tramite VPN da sito a sito è attiva e può garantire la continuità del servizio se le connessioni ExpressRoute primarie e secondarie hanno esito negativo. Per completare i test di failover, abilitare le connessioni ExpressRoute e normalizzare il flusso di traffico usando il set di comandi seguente.
$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt
Per verificare che il traffico sia stato trasferito di nuovo a ExpressRoute, ripetere il comando traceroute e assicurarsi che passi attraverso il peering privato di ExpressRoute.
Passaggi successivi
ExpressRoute è progettato per la disponibilità elevata senza un singolo punto di guasto all'interno della rete Microsoft. Un circuito ExpressRoute è comunque limitato a una singola area geografica e a un provider di servizi. La VPN da sito a sito può essere una buona soluzione di backup passivo per il ripristino di emergenza in un circuito ExpressRoute. Per una soluzione di connessione di backup passivo affidabile, la manutenzione regolare della configurazione passiva e la convalida periodica della connessione sono importanti. È essenziale non lasciare che la configurazione VPN diventi obsoleta e ripetere periodicamente (ad esempio ogni trimestre) i passaggi di convalida e test di failover descritti in questo articolo durante la finestra di manutenzione.
Per abilitare il monitoraggio e gli avvisi in base alle metriche del gateway VPN, vedere Configurare gli avvisi sulle metriche del gateway VPN.
Per accelerare la convergenza BGP in seguito a un errore di ExpressRoute, Configurare BFD su ExpressRoute.