Rotas personalizadas e soluções de virtualização de rede no Azure: UDR, BGP e encaminhamento de IP

radio_button_uncheckedshort_text1. Encaminhe o tráfego para inspeção em vez de confiar no caminho padrão

Uma varejista sofreu uma violação que expôs nomes, endereços e dados de pagamento de clientes. O plano de correção inclui soluções de virtualização de rede para inspecionar o tráfego antes que ele alcance sistemas sensíveis. A equipe de infraestrutura precisa fazer o Azure escolher esse caminho de forma consistente, impedindo que a comunicação direta entre sub-redes contorne a inspeção.

Este capítulo constrói a solução desde a tabela de rotas. Você diferencia rotas de sistema, opcionais, BGP e definidas pelo usuário; escolhe o próximo salto; implanta uma NVA Ubuntu simples; habilita encaminhamento em dois planos distintos; e comprova o caminho assimétrico com traceroute.

• Identificar os recursos de roteamento da Rede Virtual do Azure e o comportamento padrão.
• Configurar tabelas de rotas e rotas definidas pelo usuário (UDRs).
• Implantar uma solução de virtualização de rede básica e explicar seu papel de segurança.
• Habilitar encaminhamento de IP na NIC do Azure e no sistema operacional convidado.
• Conduzir o tráfego da sub-rede pública pela NVA e validar cada salto.

Os pré-requisitos são sub-redes, endereçamento IP, Rede Virtual do Azure, CLI do Azure, SSH e uma assinatura autorizada para os laboratórios opcionais.

radio_button_uncheckedshort_text2. O Azure roteia automaticamente o tráfego que sai de uma sub-rede

Cada sub-rede do Azure possui uma tabela de rotas efetivas. O Azure cria as rotas de sistema iniciais, combina-as com rotas opcionais da plataforma, rotas propagadas pelo gateway e UDRs associadas e avalia o IP de destino de cada pacote de saída. Por isso, VMs na mesma VNet conversam entre sub-redes sem um roteador gerenciado pelo cliente.

Rotas de sistema não podem ser criadas nem excluídas. Algumas podem ser substituídas por uma rota mais específica ou por uma rota personalizada de maior prioridade. Toda rota declara um prefixo de destino e um tipo de próximo salto; a rota para solução de virtualização também informa o IP privado desse salto.

radio_button_uncheckedshort_text3. Rotas de sistema padrão definem tráfego local, internet e descarte

Quando uma faixa privada reservada é adicionada ao espaço da VNet, o Azure altera a rota aplicável para Rede virtual. O próximo salto Nenhum descarta o pacote no roteamento; isso não é uma negação de NSG.

radio_button_uncheckedshort_text4. Recursos do Azure acrescentam rotas opcionais

Um ponto de extremidade de serviço estende a identidade da sub-rede até um serviço do Azure compatível e cria rotas otimizadas. Isso não transforma VirtualNetworkServiceEndpoint em um valor selecionável em uma UDR.

radio_button_uncheckedshort_text5. Uma tabela de rotas vincula a política à sub-rede

A tabela de rotas é um recurso do Azure Resource Manager que armazena UDRs e a opção de propagação de rotas do gateway de rede virtual. Uma tabela pode ser associada a várias sub-redes, mas cada sub-rede aceita no máximo uma tabela. As UDRs são combinadas com as rotas de sistema e propagadas.

• Associe a tabela à sub-rede de origem cujas decisões de saída devem mudar.
• Não coloque a NVA na mesma sub-rede cuja UDR aponta de volta para ela, pois isso pode criar loop.
• Não desabilite propagação de rotas do gateway na GatewaySubnet; o gateway pode deixar de funcionar.
• Use as rotas efetivas da NIC para observar o resultado final e os estados Ativo ou Inválido.

radio_button_uncheckedshort_text6. Rotas personalizadas vêm de UDR ou BGP

Uma UDR é uma rota estática definida pelo administrador e armazenada em uma tabela do Azure. O BGP é um protocolo dinâmico que troca prefixos entre o gateway local e o gateway de rede virtual do Azure. As duas fontes alteram o comportamento padrão, porém possuem propriedade e ciclo de vida diferentes.

radio_button_uncheckedshort_text7. Tipos de próximo salto expressam a ação da UDR

Emparelhamento de rede virtual e VirtualNetworkServiceEndpoint são tipos criados pela plataforma, não valores de UDR. Uma rota VirtualAppliance exige IP de próximo salto com conectividade direta; um salto inválido ou indisponível interrompe o fluxo.

radio_button_uncheckedshort_text8. Marcas de serviço reduzem manutenção de endereços

O prefixo de uma UDR pode ser uma marca de serviço em vez de um CIDR literal. A Microsoft mantém os prefixos representados por marcas como Storage, suas versões regionais e AzureCloud. Isso reduz a quantidade de rotas e evita atualizar manualmente a tabela quando o serviço muda endereços.

Limites e precedência continuam importantes. Uma tabela aceita quantidade limitada de rotas com marcas; uma rota de prefixo IP explícito vence a marca em correspondência exata. Entre marcas correspondentes, versões regionais mais específicas precedem as abrangentes.

radio_button_uncheckedshort_text9. BGP propaga o conhecimento da rede híbrida

O BGP troca informações de roteamento entre sistemas autônomos. ExpressRoute exige BGP entre a borda local e a Microsoft; o Gateway de VPN do Azure pode usar BGP opcionalmente em conexões site a site. Cada prefixo anunciado torna-se uma rota nas sub-redes elegíveis com Gateway de rede virtual como fonte e próximo salto.

A retirada dinâmica permite que roteadores escolham outro caminho após falha. Resuma rotas locais para anunciar menos prefixos. A tabela pode desabilitar propagação em sub-redes específicas, mas nunca faça isso na GatewaySubnet.

radio_button_uncheckedshort_text10. Prefixo mais longo vem antes da prioridade da fonte

O Azure primeiro escolhe a rota cujo prefixo contém o destino com maior especificidade. Para 10.0.0.2, uma rota /24 vence uma /16 independentemente da ordem de exibição. O prefixo mais longo representa menos endereços e, portanto, intenção mais precisa.

Somente quando as candidatas têm o mesmo prefixo aplica-se a ordem geral: UDR, BGP e rota de sistema. Rotas de sistema preferenciais de VNet, emparelhamento e pontos de serviço têm tratamento especial; a rota de ponto de serviço não pode ser substituída. Uma tabela não aceita duas UDRs com o mesmo prefixo.

radio_button_uncheckedshort_text11. Correção atual: rota Internet não é um projeto de saída

A rota de sistema 0.0.0.0/0 com próximo salto Internet continua visível. Entretanto, roteamento e NAT de origem são diferentes. Para APIs lançadas após 31 de março de 2026, novas VNets usam sub-redes privadas por padrão e precisam de um método explícito para alcançar endpoints públicos.

• Use o Gateway da NAT do Azure para saída previsível, escalável e somente de saída.
• Associe explicitamente um IP público quando uma VM realmente precisar dele.
• Use regras de saída do Standard Load Balancer quando fizerem parte da arquitetura.
• Use UDR com NVA ou firewall somente quando o dispositivo também fornecer proxy/NAT e retorno.
• Não use UDR Internet em uma sub-rede privada para tentar restaurar saída; a plataforma atual bloqueia esse caminho.

Uma UDR 0.0.0.0/0 apontando para NVA implementa túnel forçado. Ela também pode redirecionar destinos públicos de serviços do Azure quando nenhuma rota de ponto de serviço mais longa existe; avalie ativação, atualizações, DNS e gestão antes da implantação.

radio_button_uncheckedshort_text12. NVA é uma VM que executa funções de rede

Uma solução de virtualização de rede é uma máquina virtual ou imagem de appliance que controla tráfego por meio de roteamento e de uma aplicação de rede. Suas funções podem incluir firewall, otimização de WAN, entrega de aplicações, roteamento, balanceamento de carga, IDS/IPS e proxy.

O Azure Marketplace oferece imagens de Cisco, Check Point, Barracuda, Sophos, WatchGuard e SonicWall. Também é possível montar uma NVA didática em Windows ou Linux, mas suporte, atualização, desempenho, licenciamento e alta disponibilidade de produção precisam ser planejados.

radio_button_uncheckedshort_text13. Microssegmentação e NICs definem o caminho dos dados

O desenho simples coloca a NVA em uma sub-rede de perímetro/DMZ e conduz por ela sub-redes selecionadas. A microssegmentação separa web, negócio, dados, gestão e inspeção para controlar fluxos leste-oeste. Dispositivos de Camada 4 analisam endereços, protocolos e portas; soluções com consciência da aplicação também inspecionam a Camada 7.

Algumas NVAs usam uma NIC de gestão e outras para o plano de dados. A arquitetura do fornecedor determina quais interfaces recebem, inspecionam e encaminham. As UDRs precisam mirar o frontend privado compatível e o retorno deve respeitar o estado do dispositivo.

radio_button_uncheckedshort_text14. A NVA inserida na rota torna-se dependência crítica

Quando todo fluxo permitido depende do appliance, sua falha vira indisponibilidade de rede. Produção exige o padrão de alta disponibilidade do fornecedor: várias instâncias em zonas ou conjuntos, investigação de integridade, seleção resiliente de próximo salto, sincronização de estado quando necessária e recuperação automatizada.

O IP privado de um balanceador de carga interno pode ser um próximo salto VirtualAppliance em arquiteturas compatíveis. Azure Route Server, Gateway Load Balancer ou outros padrões podem ser adequados a fornecedores específicos. O laboratório usa uma VM e não é uma arquitetura de produção.

radio_button_uncheckedshort_text15. Topologia do laboratório: três sub-redes e inspeção em uma direção

Os laboratórios opcionais criam a VNet vnet com 10.0.0.0/16. publicsubnet usa 10.0.0.0/24, privatesubnet 10.0.1.0/24 e dmzsubnet 10.0.2.0/24. A NVA usa 10.0.2.4. A rota productionsubnet envia o destino 10.0.1.0/24 para esse appliance e a tabela é associada somente a publicsubnet.

radio_button_uncheckedshort_text16. Laboratório 1: crie a tabela e a UDR

Execute somente em assinatura autorizada. Use grupo dedicado, substitua myResourceGroupName, confira a assinatura ativa no Azure Cloud Shell e limpe ao final. A antiga orientação para usar o modo “Classic” reflete a interface exportada e não é requisito de roteamento.

az network route-table create \
  --name publictable \
  --resource-group "myResourceGroupName" \
  --disable-bgp-route-propagation false

az network route-table route create \
  --route-table-name publictable \
  --resource-group "myResourceGroupName" \
  --name productionsubnet \
  --address-prefix 10.0.1.0/24 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.2.4

O primeiro comando mantém propagação do gateway. O segundo altera somente destinos pertencentes à privatesubnet; ele não conduz todo o tráfego da publicsubnet pela NVA.

radio_button_uncheckedshort_text17. Laboratório 1: crie rede, sub-redes e associação

az network vnet create \
  --name vnet \
  --resource-group "myResourceGroupName" \
  --address-prefixes 10.0.0.0/16 \
  --subnet-name publicsubnet \
  --subnet-prefixes 10.0.0.0/24

az network vnet subnet create \
  --name privatesubnet --vnet-name vnet \
  --resource-group "myResourceGroupName" \
  --address-prefixes 10.0.1.0/24

az network vnet subnet create \
  --name dmzsubnet --vnet-name vnet \
  --resource-group "myResourceGroupName" \
  --address-prefixes 10.0.2.0/24

az network vnet subnet list \
  --resource-group "myResourceGroupName" \
  --vnet-name vnet --output table

az network vnet subnet update \
  --name publicsubnet --vnet-name vnet \
  --resource-group "myResourceGroupName" \
  --route-table publictable

A listagem confirma os CIDRs antes da associação. O update aplica publictable a publicsubnet; privatesubnet preserva somente rotas de sistema e opcionais, explicando o teste de retorno.

radio_button_uncheckedshort_text18. Laboratório 2: implante a NVA Ubuntu

O exercício implanta Ubuntu 22.04 LTS em dmzsubnet com azureuser e senha de exemplo. Em ambiente real, prefira chaves SSH, restrinja a origem de gestão, não exponha a administração do appliance diretamente à internet e siga o endurecimento do fornecedor.

az vm create \
  --resource-group "myResourceGroupName" \
  --name nva --vnet-name vnet --subnet dmzsubnet \
  --image Ubuntu2204 --admin-username azureuser \
  --admin-password <password>

radio_button_uncheckedshort_text19. Encaminhamento precisa ser habilitado no Azure e no convidado

A configuração da NIC diz ao Azure para aceitar pacotes cuja origem ou destino não é o endereço da própria NVA. A configuração do sistema faz o Linux agir como roteador. Somente um dos lados não basta.

NICID=$(az vm nic list \
  --resource-group "myResourceGroupName" --vm-name nva \
  --query "[].{id:id}" --output tsv)

NICNAME=$(az vm nic show \
  --resource-group "myResourceGroupName" --vm-name nva \
  --nic $NICID --query "{name:name}" --output tsv)

az network nic update --name $NICNAME \
  --resource-group "myResourceGroupName" \
  --ip-forwarding true

NVAIP="$(az vm list-ip-addresses \
  --resource-group "myResourceGroupName" --name nva \
  --query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
  --output tsv)"

ssh -t -o StrictHostKeyChecking=no azureuser@$NVAIP \
  'sudo sysctl -w net.ipv4.ip_forward=1; exit;'

A mudança `sysctl -w` dura somente até reinicialização, salvo se for persistida. Desabilitar a verificação da chave do host é conveniente no laboratório descartável, mas não deve ser copiado para automação de produção.

radio_button_uncheckedshort_text20. Laboratório 3: implante VMs com traceroute

Crie cloud-init.txt para instalar inetutils-traceroute nas duas VMs. O exercício atribui IP público a ambas para SSH; isso é conveniência didática temporária, não um desenho recomendado para camada privada.

cat > cloud-init.txt <<'EOF'
#cloud-config
package_upgrade: true
packages:
  - inetutils-traceroute
EOF

az vm create \
  --resource-group "myResourceGroupName" --name public \
  --vnet-name vnet --subnet publicsubnet --image Ubuntu2204 \
  --admin-username azureuser --no-wait \
  --custom-data cloud-init.txt --admin-password <password>

az vm create \
  --resource-group "myResourceGroupName" --name private \
  --vnet-name vnet --subnet privatesubnet --image Ubuntu2204 \
  --admin-username azureuser --no-wait \
  --custom-data cloud-init.txt --admin-password <password>

watch -d -n 5 "az vm list \
  --resource-group 'myResourceGroupName' --show-details \
  --query '[*].{Name:name,ProvisioningState:provisioningState,PowerState:powerState}' \
  --output table"

Prossiga quando todas mostrarem Succeeded e VM running; encerre watch com Ctrl+C. Se traceroute ainda não existir, o cloud-init pode estar instalando o pacote: aguarde e tente novamente.

radio_button_uncheckedshort_text21. Laboratório 3: trace as duas direções e explique a assimetria

PUBLICIP="$(az vm list-ip-addresses \
  --resource-group "myResourceGroupName" --name public \
  --query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
  --output tsv)"

PRIVATEIP="$(az vm list-ip-addresses \
  --resource-group "myResourceGroupName" --name private \
  --query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
  --output tsv)"

ssh -t -o StrictHostKeyChecking=no azureuser@$PUBLICIP \
  'traceroute private --type=icmp; exit'

ssh -t -o StrictHostKeyChecking=no azureuser@$PRIVATEIP \
  'traceroute public --type=icmp; exit'

Public-para-private deve mostrar 10.0.2.4, a NVA, no primeiro salto e 10.0.1.4 no segundo. Private-para-public vai diretamente a 10.0.0.4 porque privatesubnet não possui UDR associada. Isso prova que a tabela atua na sub-rede de origem e que o roteamento pode ser assimétrico.

Firewalls com estado geralmente exigem simetria. Acrescente UDR de retorno apropriada ou use arquitetura simétrica e altamente disponível compatível; caso contrário, o retorno pode contornar o appliance e a sessão falhar.

radio_button_uncheckedshort_text22. Respostas das verificações de conhecimento

radio_button_uncheckedshort_text23. Diagnóstico e verificações atuais de projeto

• Confirme que a tabela está associada à sub-rede de origem, não apenas criada.
• Inspecione rotas efetivas e verifique se a UDR está Ativa e vence pelo prefixo mais longo.
• Confirme que o IP VirtualAppliance é diretamente alcançável e pertence ao frontend compatível.
• Habilite encaminhamento em todas as NICs envolvidas e no sistema/configuração do appliance.
• Verifique NSGs, firewall convidado, política e integridade da NVA, probes e rotas de retorno.
• Garanta que a NVA não está na mesma sub-rede cuja UDR aponta para ela.
• Trate inspeção 0.0.0.0/0, saída pública e NAT como requisitos distintos.
• Prefira chaves SSH, Azure Bastion ou rede confiável e NVAs altamente disponíveis em produção.
• Use próximo salto, diagnóstico de conexão, rotas efetivas e captura do Observador de Rede do Azure.

radio_button_uncheckedshort_text24. Revisão compacta, recordação ativa e recursos oficiais

Perguntas para recordação ativa

• Reconstrua a tabela de rotas de sistema sem consultar.
• Escolha próximo salto para inspeção, descarte, VPN, VNet local e internet explícita.
• Resolva um exemplo com prefixos sobrepostos de UDR, BGP e sistema.
• Explique por que encaminhar na NIC não transforma sozinho o Ubuntu em roteador.
• Preveja os dois traceroutes antes do laboratório.
• Converta a NVA única em projeto seguro, simétrico e altamente disponível.

Documentação oficial

• Roteamento de tráfego de rede virtual do Azure
• Tutorial de roteamento com tabela de rotas
• Acesso de saída padrão no Azure
• Implantar soluções de virtualização de rede altamente disponíveis
• Diagnóstico de próximo salto no Observador de Rede do Azure