Inspeção de NVA no Azure: por que a resposta passa por outro firewall

Um fluxo da filial para o Azure pode ser roteado corretamente nos dois sentidos e ainda assim falhar, porque os dois sentidos passam por dispositivos diferentes. A requisição deixa a filial pela VPN, pousa na NVA A e chega à carga de trabalho. A resposta deixa a carga de trabalho, corresponde a uma rota que aponta para a NVA B e morre ali. Todas as rotas dessa imagem são válidas, e a sessão TCP continua quebrada.

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Essa lacuna é o tema inteiro aqui: a convergência de roteamento e a propriedade do estado da sessão são problemas diferentes que parecem idênticos em um diagrama.

O que o Route Server realmente programa

O Azure Route Server faz peering com os falantes BGP suportados, aprende suas rotas e as programa nas rotas efetivas da rede virtual. Isso é um trabalho de plano de controle. Ele não lê a tabela de sessões de um firewall de fornecedor e não sabe qual dispositivo admitiu uma conexão específica. Dois próximos saltos de custo igual são, para esta malha, simplesmente duas formas de alcançar o mesmo prefixo, e ele usará qualquer uma.

Aprender uma rota, portanto, prova alcançabilidade. Não prova nada sobre se o dispositivo do outro lado já viu este fluxo antes.

Leia os dois sentidos antes de projetar

Comece anotando o direcionamento que você realmente tem em cada sentido, não o que pretendia. Rotas BGP mais específicas, rotas definidas pelo usuário e o comportamento do gateway competem todos, e o vencedor é decidido por destino, não por sessão. Uma rota padrão na NVA não significa que todo prefixo privado passe por ela.

Uma verificação útil é perguntar, para um IP específico de carga de trabalho, a qual próximo salto cada sentido resolve. Se a resposta forem dois dispositivos diferentes, você tem um problema de assimetria, já tenha aparecido ou não.

Onde o estado vive

Um firewall com estado admite uma conexão e mantém uma entrada de tabela com chave na quíntupla. A resposta precisa chegar ao dispositivo que detém essa entrada, ou esse dispositivo precisa obter o estado de outra forma. Nada no plano de dados do Azure encaminha a entrada entre dispositivos. Ou o tráfego é direcionado de volta ao proprietário, ou os dispositivos compartilham estado por um mecanismo do fornecedor, ou o projeto não funciona.

É por isso que duas NVAs saudáveis não são uma verificação de saúde para inspeção. Saúde é sobre alcançabilidade; inspeção é sobre qual instância detém a sessão.

Modelos de HA suportados e o que cada um promete

Microsoft's guidance on a intenção de roteamento do Virtual WAN descreve comportamento limitado para conectividade de dupla função e NVAs de firewall, onde o roteamento direto pode contornar a aplicação simétrica normal do hub. Leia essas notas como restrições à topologia escolhida, não como proibição de projetos ativo-ativo. Um par de fornecedor que sincroniza estado, ou direciona por fluxo, pode ser suportado. Um par de custo igual que não faz nenhuma das duas coisas não é.

Em seguida, defina o que acontece com as sessões existentes quando um nó falha. A convergência de rotas restaura a alcançabilidade para novos fluxos em segundos, enquanto o estado antigo do firewall simplesmente desaparece. Uma reconexão do cliente pode ser o resultado documentado, e essa é uma decisão a tomar antes do incidente, não durante.

O que testar antes de confiar

Test with inspection enabled and a política de acesso da carga de trabalho no lugar, porque qualquer uma delas pode esconder a assimetria. Envie um novo fluxo autorizado nos dois sentidos e confirme que o mesmo dispositivo viu as duas metades. Depois execute tráfego sustentado e acione o failover aprovado, observando se as sessões estabelecidas sobrevivem ou se reconectam.

Correlacione cada fluxo com o dispositivo que o tratou. Uma captura de pacotes em uma NVA não diz quase nada se a resposta nunca voltou para ela.

Por fim, escreva o plano em três linhas separadas: propriedade das rotas, direcionamento do tráfego e propriedade do estado da sessão. Os projetos quebram quando os dois primeiros estão resolvidos e o terceiro é presumido.