ExpressRoute più VPN: quali domini di guasto copri?

Un tunnel IPsec che gira sul peering privato di ExpressRoute aggiunge cifratura a un trasporto che esiste già. Un secondo tunnel migliora la disponibilità dell'endpoint e non fa assolutamente nulla per il percorso dell'operatore sottostante a entrambi. Questa distinzione si perde facilmente quando le dashboard mostrano due tunnel verdi e la revisione di progettazione pone un'altra domanda: quali guasti deve sopravvivere questa connessione? Rispondete prima a questo, poi contate i tunnel, perché il numero di indicatori verdi è una proprietà dello strato di cifratura e il numero di domini di guasto è una proprietà dell'intero percorso.

Iniziate dai guasti, non dai tunnel verdi

Scrivete quattro righe prima di disegnare qualsiasi cosa: il guasto di un endpoint VPN o di un'istanza peer, il guasto di un router locale o di una connessione di primo miglio, il guasto del percorso ExpressRoute condiviso e l'indisponibilità di IPsec mentre il peering privato trasporta ancora traffico. Ogni riga nomina ciò che la progettazione deve preservare, e a ciascuna risponde un meccanismo diverso.

Microsoft documenta la VPN site-to-site con IP privati sul peering privato di ExpressRoute e la coesistenza supportata con connessioni site-to-site basate su Internet. Quella coesistenza è una progettazione diversa dello strato sottostante e non compare solo perché avete aggiunto un altro endpoint di tunnel privato.

Dominio di guasto 1: l'endpoint VPN

Due tunnel su un gateway sono di solito coppie attivo-attivo che terminano sulla stessa risorsa lato Azure. Proteggono da un problema di un singolo tunnel o di una singola istanza e non proteggono dall'indisponibilità, dalla riconfigurazione o dall'esaurimento della capacità di quella risorsa. La ridondanza dell'endpoint significa un secondo endpoint supportato, con il proprio percorso e la propria configurazione, più una rotta in grado di raggiungerlo.

Verificate ciò che avete effettivamente distribuito e non ciò che dice il diagramma, perché il portale raggruppa queste risorse in modi che ne nascondono la relazione:

az network vpn-connection show -g rg-connectivity -n vpn-to-hub   --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub   --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'

Se entrambi i tunnel puntano a un gateway con un solo IP pubblico, avete una ridondanza dell'endpoint di tipo specifico e limitato. Può essere esattamente ciò che il requisito chiede, e andrebbe detto così invece di descriverlo come una connessione ridondante.

Dominio di guasto 2: il percorso locale e l'operatore

Sotto la cifratura c'è una realtà fisica e commerciale: un apparato di bordo del cliente, un'interconnessione, una rete del fornitore e una sede di peering. le linee guida sulla disponibilità di ExpressRoute sono esplicite nel dire che la ridondanza end-to-end include i segmenti del cliente e del fornitore di servizi, non solo il lato Microsoft. Due percorsi logici che condividono un router, un'alimentazione o una connessione di primo miglio condividono ancora quella dipendenza.

È qui che una progettazione di solito fallisce una revisione onesta. Due circuiti dello stesso fornitore, che terminano nello stesso edificio, su apparecchiature dello stesso ordine d'acquisto, non sono due domini di guasto. Sono un dominio di guasto con due fatture.

Ponete la domanda all'operatore per iscritto: quali di questi percorsi divergono, dove, e qual è il comportamento documentato quando il segmento condiviso si guasta? Un'assicurazione verbale durante una chiamata di progettazione non sopravvive al disservizio per cui state progettando.

Dominio di guasto 3: la rotta che sopravvive senza IPsec

Il peering privato e IPsec possono offrire rotte concorrenti verso lo stesso prefisso applicativo. Se la rotta protetta scompare, una rotta diretta ExpressRoute sopravvissuta può essere ancora utilizzabile, senza lo strato di cifratura che il tunnel forniva. Se ciò sia accettabile è una decisione di policy, ed è la decisione più spesso lasciata implicita.

I requisiti di cifratura e quelli di disponibilità possono entrare davvero in conflitto qui. «Qualsiasi rotta sopravvissuta conta come successo» è un'affermazione di disponibilità che risponde in sordina «no» alla domanda sulla cifratura. Scrivete quale vince, per quali prefissi e chi l'ha approvato.

az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o table

Confrontate le rotte apprese con i prefissi che vi aspettavate. Una rotta di riserva che trasporta un piccolo carico amministrativo può essere del tutto adeguata a quel carico e molto lontana dalla capacità richiesta dalla domanda di produzione, quindi annotate l'ipotesi di capacità accanto alla rotta.

Registrate tre righe separate, non un solo verdetto

Tenete la ridondanza dell'endpoint, la ridondanza del trasporto e il disaster recovery come voci separate nel registro di progettazione, ciascuna con il proprio meccanismo, la propria verifica e il proprio responsabile. Quando una revisione di incidente chiede perché la connessione ha superato un riavvio del gateway ma non un taglio di fibra, tre righe rispondono in una frase; una singola casella «ridondante» non può.

Poi provate le righe che potete provare a basso costo. Fate fallire un tunnel e confermate che il traffico si sposta e viene ricifrato. Ritirate una rotta e confermate che il percorso sopravvissuto è quello che intendevate, poi confermate se è ancora cifrato. Documentate i guasti che non siete riusciti a simulare, perché una riga non testata è un'ipotesi e va etichettata come tale.

L'output utile è una tabella breve più una frase per riga. Se una riga non ha alcun meccanismo, questo è il risultato, ed è molto più economico scoprirlo in una revisione di progettazione che durante un disservizio dell'operatore che nessuno dei due tunnel avrebbe mai superato.