ExpressRoute mais VPN: quais domínios de falha cobre?

Um túnel IPsec a correr sobre o peering privado do ExpressRoute acrescenta cifra a um transporte que já existe. Um segundo túnel melhora a disponibilidade do endpoint e não faz absolutamente nada pelo caminho da operadora por baixo dos dois. Essa distinção perde-se facilmente quando os painéis mostram dois túneis verdes e a revisão de design coloca outra pergunta: que falhas é que esta ligação tem de sobreviver? Responda primeiro a isso e só depois conte túneis, porque o número de indicadores verdes é uma propriedade da camada de cifra e o número de domínios de falha é uma propriedade do caminho completo.

Comece pelas falhas, não pelos túneis verdes

Escreva quatro linhas antes de desenhar seja o que for: um endpoint VPN ou uma instância de par a falhar, um router local ou uma ligação de primeira milha a falhar, o caminho partilhado do ExpressRoute a falhar e o IPsec a ficar indisponível enquanto o peering privado ainda transporta tráfego. Cada linha nomeia o que o design tem de preservar, e a cada uma responde um mecanismo diferente.

A Microsoft documenta a VPN site-to-site com IP privados sobre o peering privado do ExpressRoute e a coexistência suportada com ligações site-to-site baseadas na internet. Essa coexistência é um desenho diferente da camada inferior e não aparece só porque acrescentou outro endpoint de túnel privado.

Domínio de falha 1: o endpoint da VPN

Dois túneis num gateway são normalmente pares ativo-ativo que terminam no mesmo recurso do lado do Azure. Protegem contra um problema de um único túnel ou instância e não protegem contra esse recurso ficar indisponível, ser reconfigurado ou esgotar a capacidade. Redundância de endpoint significa um segundo endpoint suportado, com o seu próprio caminho e a sua própria configuração, mais uma rota capaz de o alcançar.

Verifique o que realmente implementou e não o que diz o diagrama, porque o portal agrupa estes recursos de formas que escondem a relação entre eles:

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úneis apontam para um gateway com um único IP público, tem redundância de endpoint de um tipo concreto e limitado. Pode ser exatamente o que o requisito pede, e devia ser dito assim em vez de ser descrito como uma ligação redundante.

Domínio de falha 2: o caminho local e a operadora

Por baixo da cifra está uma realidade física e comercial: um equipamento de bordo do cliente, uma interligação, uma rede de fornecedor e um local de peering. as orientações de disponibilidade do ExpressRoute são explícitas ao afirmar que a redundância ponta a ponta inclui os segmentos do cliente e do fornecedor de serviço, não apenas o lado da Microsoft. Dois caminhos lógicos que partilham um router, uma alimentação elétrica ou uma ligação de primeira milha continuam a partilhar essa dependência.

É aqui que um design costuma falhar uma revisão honesta. Dois circuitos do mesmo fornecedor, a terminar no mesmo edifício, em equipamento da mesma encomenda, não são dois domínios de falha. São um domínio de falha com duas faturas.

Faça a pergunta à operadora por escrito: quais destes caminhos divergem, onde, e qual é o comportamento documentado quando o segmento partilhado falha? Uma garantia verbal durante uma chamada de design não sobrevive à queda para a qual está a desenhar.

Domínio de falha 3: a rota que sobrevive sem IPsec

O peering privado e o IPsec podem oferecer rotas concorrentes para o mesmo prefixo de aplicação. Se a rota protegida desaparecer, uma rota direta do ExpressRoute sobrevivente pode ainda ser utilizável, sem a camada de cifra que o túnel fornecia. Se isso é aceitável é uma decisão de política, e é a decisão que mais vezes fica implícita.

Os requisitos de cifra e os requisitos de disponibilidade podem entrar aqui em conflito real. «Qualquer rota sobrevivente conta como sucesso» é uma afirmação de disponibilidade que responde em voz baixa «não» à pergunta da cifra. Anote qual ganha, para que prefixos e quem o aprovou.

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 rotas aprendidas com os prefixos que esperava. Um caminho alternativo que transporta uma carga administrativa pequena pode ser perfeitamente adequado para essa carga e ficar muito longe da capacidade de que a procura de produção precisa, por isso registe a suposição de capacidade ao lado da rota.

Registe três linhas separadas, não um único veredicto

Mantenha a redundância de endpoint, a redundância de transporte e a recuperação de desastres como entradas separadas no registo de design, cada uma com o seu mecanismo, a sua verificação e o seu responsável. Quando uma revisão de incidente pergunta porque é que a ligação sobreviveu a um reinício do gateway mas não a um corte de fibra, três linhas respondem numa frase; uma única caixa de «redundante» não consegue.

Depois teste as linhas que pode testar a baixo custo. Faça falhar um túnel e confirme que o tráfego se move e volta a ser cifrado. Retire uma rota e confirme que o caminho sobrevivente é o que pretendia, e depois confirme se continua cifrado. Documente as falhas que não conseguiu simular, porque uma linha não testada é uma suposição e deve ser rotulada como tal.

O resultado útil é uma tabela curta mais uma frase por linha. Se uma linha não tiver mecanismo, é esse o achado, e é muito mais barato descobri-lo numa revisão de design do que durante uma queda da operadora que nenhum dos dois túneis teria sobrevivido.