ExpressRoute máis VPN: que dominios de fallo cobre?

Un túnel IPsec que se executa sobre o emparellamento privado de ExpressRoute engade cifrado a un transporte que xa existe. Un segundo túnel mellora a dispoñibilidade do extremo e non fai absolutamente nada pola ruta do operador que hai debaixo de ambos. Esa distinción pérdese facilmente cando os paneis mostran dous túneles verdes e a revisión de deseño formula outra pregunta: que fallos debe sobrevivir esta conexión? Responda iso primeiro e logo conte túneles, porque o número de indicadores verdes é unha propiedade da capa de cifrado e o número de dominios de fallo é unha propiedade da ruta completa.

Empece polos fallos, non polos túneles verdes

Escriba catro filas antes de debuxar nada: o fallo dun extremo de VPN ou dunha instancia de par, o fallo dun encamiñador local ou dunha conexión de primeira milla, o fallo da ruta compartida de ExpressRoute e a indispoñibilidade de IPsec mentres o emparellamento privado aínda transporta tráfico. Cada fila nomea o que o deseño debe preservar, e a cada unha respóndelle un mecanismo distinto.

Microsoft documenta a VPN de sitio a sitio con IP privadas sobre o emparellamento privado de ExpressRoute, e a coexistencia admitida con conexións de sitio a sitio baseadas en internet. Esa coexistencia é un deseño distinto da capa inferior e non aparece só porque engadiu outro extremo de túnel privado.

Dominio de fallo 1: o extremo de VPN

Dous túneles nunha pasarela adoitan ser parellas activo-activo que rematan no mesmo recurso do lado de Azure. Protexen contra un problema dun só túnel ou instancia, e non protexen contra que ese recurso quede non dispoñible, se reconfigure ou se quede sen capacidade. A redundancia de extremo significa un segundo extremo admitido, coa súa propia ruta e a súa propia configuración, máis unha ruta que poida alcanzalo.

Comprobe o que despregou realmente e non o que di o diagrama, porque o portal agrupa estes recursos de xeitos que ocultan a súa relación:

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 ambos os túneles apuntan a unha pasarela cunha IP pública, ten unha redundancia de extremo dun tipo concreto e limitado. Pode ser exactamente o que pide o requisito, e debería dicirse así en lugar de describilo como unha conexión redundante.

Dominio de fallo 2: a ruta local e o operador

Baixo o cifrado hai unha realidade física e comercial: un dispositivo de bordo do cliente, unha interconexión, unha rede de provedor e unha localización de emparellamento. as directrices de dispoñibilidade de ExpressRoute son explícitas en que a redundancia de extremo a extremo inclúe os segmentos do cliente e do provedor de servizos, non só o lado de Microsoft. Dúas rutas lóxicas que comparten un encamiñador, unha alimentación eléctrica ou unha conexión de primeira milla seguen compartindo esa dependencia.

Aquí é onde un deseño adoita suspender unha revisión honesta. Dous circuítos do mesmo provedor, que rematan no mesmo edificio, sobre equipos do mesmo pedido de compra, non son dous dominios de fallo. Son un dominio de fallo con dúas facturas.

Pregunte ao operador por escrito: cales destas rutas diverxen, onde, e cal é o comportamento documentado cando falla o segmento compartido. Unha garantía verbal durante unha chamada de deseño non sobrevive á caída para a que está deseñando.

Dominio de fallo 3: a ruta que sobrevive sen IPsec

O emparellamento privado e IPsec poden ofrecer rutas competidoras cara ao mesmo prefixo de aplicación. Se a ruta protexida desaparece, unha ruta directa de ExpressRoute supervivente aínda pode ser utilizábel, sen a capa de cifrado que proporcionaba o túnel. Se iso é aceptábel é unha decisión de política, e é a decisión que máis a miúdo se deixa implícita.

Os requisitos de cifrado e os de dispoñibilidade poden entrar aquí en conflito real. «Calquera ruta supervivente conta como éxito» é unha afirmación de dispoñibilidade que responde en voz baixa á pregunta do cifrado cun «non». Anote cal gaña, para que prefixos e quen o aprobou.

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

Compare as rutas aprendidas cos prefixos que esperaba. Unha ruta alternativa que transporta unha carga administrativa pequena pode ser perfectamente axeitada para esa carga e quedar moi lonxe da capacidade que necesita a demanda de produción, así que anote a suposición de capacidade xunto á ruta.

Anote tres filas separadas, non un só veredicto

Manteña a redundancia de extremo, a redundancia de transporte e a recuperación ante desastres como entradas separadas no rexistro de deseño, cada unha co seu propio mecanismo, a súa propia verificación e o seu propio responsable. Cando unha revisión de incidente pregunta por que a conexión sobreviviu a un reinicio de pasarela pero non a un corte de fibra, tres filas responden nunha frase; unha soa caixa de «redundante» non pode.

Despois probe as filas que poida probar barato. Faga fallar un túnel e confirme que o tráfico se move e se volve cifrar. Retire unha ruta e confirme que a ruta supervivente é a que pretendía, e logo confirme se aínda está cifrada. Documente os fallos que non puido simular, porque unha fila non probada é unha suposición e debería etiquetarse como tal.

A saída útil é unha táboa curta máis unha frase por fila. Se unha fila non ten mecanismo, ese é o achado, e é moito máis barato descubrilo nunha revisión de deseño que durante unha caída do operador que ningún dos dous túneles habería sobrevivir.