ExpressRoute més VPN: quins dominis de fallada cobriu?

Un túnel IPsec que funciona sobre l'aparellament privat d'ExpressRoute afegeix xifratge a un transport que ja existeix. Un segon túnel millora la disponibilitat de l'extrem i no fa absolutament res pel camí de l'operador que hi ha a sota dels dos. Aquesta distinció es perd fàcilment quan els taulers mostren dos túnels verds i la revisió de disseny planteja una altra pregunta: quines fallades ha de sobreviure aquesta connexió? Responeu primer això i després compteu túnels, perquè el nombre d'indicadors verds és una propietat de la capa de xifratge i el nombre de dominis de fallada és una propietat de tot el camí.

Comenceu per les fallades, no pels túnels verds

Escriviu quatre files abans de dibuixar res: la fallada d'un extrem de VPN o d'una instància homòloga, la fallada d'un encaminador local o d'una connexió de primera milla, la fallada del camí compartit d'ExpressRoute i la indisponibilitat d'IPsec mentre l'aparellament privat encara transporta trànsit. Cada fila anomena què ha de preservar el disseny, i a cadascuna respon un mecanisme diferent.

Microsoft documenta la VPN de lloc a lloc amb IP privades sobre l'aparellament privat d'ExpressRoute, i la coexistència admesa amb connexions de lloc a lloc basades en internet. Aquesta coexistència és un disseny diferent de la capa inferior i no apareix només perquè hàgiu afegit un altre extrem de túnel privat.

Domini de fallada 1: l'extrem de VPN

Dos túnels en una passarel·la solen ser parells actiu-actiu que acaben al mateix recurs del costat d'Azure. Protegeixen contra un problema d'un sol túnel o instància, i no protegeixen que aquest recurs quedi indisponible, es reconfigure o es quedi sense capacitat. La redundància d'extrem vol dir un segon extrem admès, amb el seu propi camí i la seva pròpia configuració, més una ruta que hi pugui arribar.

Comproveu què heu desplegat realment i no què diu el diagrama, perquè el portal agrupa aquests recursos de maneres que n'amaguen la relació:

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}'

Si tots dos túnels apunten a una passarel·la amb una IP pública, teniu una redundància d'extrem d'un tipus concret i limitat. Potser és exactament el que demana el requisit, i s'hauria de dir així en lloc de descriure-ho com una connexió redundant.

Domini de fallada 2: el camí local i l'operador

Sota el xifratge hi ha una realitat física i comercial: un dispositiu de la vora del client, una interconnexió, una xarxa de proveïdor i una ubicació d'aparellament. les directrius de disponibilitat d'ExpressRoute són explícites que la redundància d'extrem a extrem inclou els segments del client i del proveïdor de serveis, no només la banda de Microsoft. Dos camins lògics que comparteixen un encaminador, una alimentació elèctrica o una connexió de primera milla continuen compartint aquesta dependència.

Aquí és on un disseny sol suspendre una revisió honesta. Dos circuits del mateix proveïdor, que acaben al mateix edifici, amb equip de la mateixa ordre de compra, no són dos dominis de fallada. Són un domini de fallada amb dues factures.

Pregunteu a l'operador per escrit: quins d'aquests camins divergeixen, on, i quin és el comportament documentat quan falla el segment compartit? Una garantia verbal durant una trucada de disseny no sobreviu a la caiguda per a la qual dissenyeu.

Domini de fallada 3: la ruta que sobreviu sense IPsec

L'aparellament privat i IPsec poden oferir rutes competidores cap al mateix prefix d'aplicació. Si la ruta protegida desapareix, una ruta directa d'ExpressRoute supervivent encara pot ser utilitzable, sense la capa de xifratge que proporcionava el túnel. Si això és acceptable és una decisió de política, i és la decisió que més sovint es deixa implícita.

Els requisits de xifratge i els de disponibilitat aquí poden entrar realment en conflicte. «Qualsevol ruta supervivent compta com un èxit» és una afirmació de disponibilitat que respon en veu baixa la pregunta del xifratge amb un «no». Anoteu qui guanya, per a quins prefixos i qui ho va aprovar.

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

Compareu les rutes apreses amb els prefixos que esperàveu. Una ruta alternativa que transporta una càrrega administrativa petita pot ser perfectament adequada per a aquesta càrrega i quedar molt lluny de la capacitat que necessita la demanda de producció, així que anoteu la suposició de capacitat al costat de la ruta.

Anoteu tres files separades, no un sol veredicte

Mantingueu la redundància d'extrem, la redundància de transport i la recuperació de desastres com a entrades separades al registre de disseny, cadascuna amb el seu mecanisme, la seva verificació i el seu propietari. Quan una revisió d'incident pregunta per què la connexió va sobreviure a un reinici de passarel·la però no a un tall de fibra, tres files responen en una frase; una única casella de «redundant» no pot.

Després proveu les files que podeu provar barat. Feu fallar un túnel i confirmeu que el trànsit es mou i es torna a xifrar. Retireu una ruta i confirmeu que el camí supervivent és el que volíeu, i després confirmeu si encara està xifrat. Documenteu les fallades que no vau poder simular, perquè una fila no provada és una suposició i s'ha d'etiquetar com a tal.

La sortida útil és una taula curta més una frase per fila. Si una fila no té mecanisme, aquesta és la troballa, i és molt més barat descobrir-la en una revisió de disseny que durant una caiguda de l'operador que cap dels dos túnels hauria sobreviscut.