Fundamentação Teórica: Configure user-defined routes

1. Intuição Inicial

Imagine o sistema de ruas de uma cidade. Normalmente, o GPS determina o caminho mais curto entre dois pontos, e os carros seguem essa rota automaticamente. Mas em certas situações, a prefeitura coloca placas de "desvio obrigatório": mesmo que o GPS indique um caminho mais curto, os carros devem passar por um determinado posto de controle antes de chegar ao destino.

No Azure, o roteamento padrão funciona como o GPS automático: o Azure conhece todos os endereços da VNet, das VNets peered e da internet, e roteia o tráfego automaticamente pelo caminho mais eficiente. As User-Defined Routes (UDRs) são as placas de "desvio obrigatório": você instrui explicitamente que certos tipos de tráfego devem passar por um ponto específico antes de chegar ao destino, mesmo que isso não seja o caminho mais curto.

O caso de uso mais comum é forçar todo o tráfego de uma subnet a passar por um Azure Firewall ou por um Network Virtual Appliance (NVA) antes de sair para a internet ou para outras redes. Sem UDRs, o tráfego iria diretamente para o destino, sem inspeção.

2. Contexto

Nos módulos anteriores, vimos que:

VNets organizam recursos em espaços de endereço isolados
Peerings conectam VNets
NSGs controlam se o tráfego é permitido ou negado

As UDRs atuam em uma dimensão diferente: não controlam se o tráfego é permitido, mas por onde ele passa. É o controle do caminho, não da permissão.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

UDRs são a peça que completa a arquitetura de segurança de rede do Azure. NSGs sozinhos controlam entrada/saída, mas não conseguem redirecionar tráfego para inspeção. UDRs fazem esse redirecionamento.

3. Construção dos Conceitos

3.1 Como o Roteamento Funciona no Azure: Rotas de Sistema

Antes de entender UDRs, é preciso entender o que acontece sem elas. O Azure cria automaticamente rotas de sistema (system routes) para cada subnet:

Prefixo de destino	Next hop	O que faz
`10.0.0.0/16` (VNet local)	`Virtual network`	Tráfego dentro da VNet fica na VNet
`0.0.0.0/0`	`Internet`	Todo tráfego não local vai para a internet
`10.1.0.0/16` (VNet peered)	`VNet peering`	Tráfego para VNet peered vai via peering
`192.168.0.0/16` (on-premises via VPN)	`Virtual network gateway`	Tráfego para rede local vai via gateway
`100.64.0.0/10`	`None`	Descartado (range reservado)

Essas rotas são automáticas e invisíveis, mas você pode vê-las verificando as effective routes de qualquer NIC. Elas formam a tabela de roteamento implícita de cada subnet.

3.2 O que é uma User-Defined Route

Uma UDR é uma entrada em uma Route Table (tabela de rotas) que você cria explicitamente. Ela tem três componentes:

Componente	Descrição	Exemplo
Address prefix	O destino: para onde esse tráfego está indo	`0.0.0.0/0` (toda a internet)
Next hop type	O tipo do próximo salto	`VirtualAppliance`
Next hop address	O IP do próximo salto (quando aplicável)	`10.0.0.4` (IP do Firewall)

3.3 Os Tipos de Next Hop

Next hop type	Descrição	Quando usar
Virtual appliance	Redireciona para um IP privado específico (NVA, Firewall)	Forçar inspeção de tráfego
Virtual network gateway	Encaminha para o gateway VPN/ExpressRoute da VNet	Roteamento para on-premises via gateway
Virtual network	Tráfego fica dentro da VNet (roteamento local)	Sobrescrever uma rota mais específica
Internet	Encaminha para a internet via IP público	Saída direta para internet
None	Descarta o tráfego (blackhole)	Bloquear rotas específicas por roteamento

O tipo None é uma forma alternativa de bloquear tráfego via roteamento, sem NSG. A diferença do NSG: o NSG retorna um "access denied" explícito; None simplesmente descarta os pacotes sem notificação.

3.4 Route Tables: O Contêiner das UDRs

Uma Route Table é o recurso Azure que contém uma coleção de UDRs. A Route Table em si não faz nada; ela precisa ser associada a uma ou mais subnets. Uma subnet pode ter no máximo uma Route Table associada. Uma Route Table pode ser associada a múltiplas subnets.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.5 Precedência de Rotas

Quando há múltiplas rotas que se aplicam ao mesmo destino, o Azure segue uma ordem de precedência:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Exemplo de precedência por especificidade: se existe uma rota de sistema para 0.0.0.0/0 → Internet, e você cria uma UDR para 10.1.0.0/16 → VirtualAppliance, o tráfego para 10.1.0.0/16 usará a UDR (mais específica), e todo o resto usará a rota de sistema padrão. A UDR não precisa substituir todas as rotas; ela apenas sobrepõe as que você define.

4. Visão Estrutural

Cenário Clássico: Force Tunneling via Azure Firewall

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A Route Table rt-spoke-to-hub contém:

0.0.0.0/0 → VirtualAppliance → 10.0.1.4 (Firewall)
192.168.0.0/16 → VirtualAppliance → 10.0.1.4 (Firewall)

Isso garante que todo o tráfego que sai das subnets da VNet Spoke passa pelo Azure Firewall, seja para internet, seja para on-premises.

Effective Routes: A Visão Completa

Para entender o roteamento efetivo de uma NIC, o Azure combina todas as fontes:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

O Problema do IP Forwarding

Quando uma UDR redireciona tráfego para uma VM ou NVA (por exemplo, um Azure Firewall ou um appliance de terceiro), existe um requisito técnico crítico: a NIC da VM de destino deve ter o IP Forwarding habilitado.

Por padrão, o Azure descarta pacotes que chegam a uma NIC mas cujo IP de destino não é o IP daquela NIC. Isso é uma proteção contra spoofing. Mas quando uma VM está atuando como roteador ou firewall, ela precisa aceitar e encaminhar pacotes destinados a outros IPs.

O IP Forwarding precisa ser habilitado em dois lugares:

Na NIC da VM no Azure (configuração do recurso NIC no portal/CLI)
No sistema operacional da VM (habilitando o IP forwarding no kernel Linux ou no registro do Windows)

Para o Azure Firewall, isso é gerenciado automaticamente pela Microsoft. Para NVAs de terceiros (Palo Alto, FortiGate, etc.), é necessário habilitar manualmente.

# Habilitar IP Forwarding na NIC via CLI
az network nic update \
  --name nic-nva-appliance \
  --resource-group rg-networking \
  --ip-forwarding true

Rota de Blackhole para Bloqueio por Roteamento

Um uso menos óbvio de UDRs é criar blackholes de roteamento: descartar tráfego para prefixos específicos sem usar NSG. Isso é útil para bloquear rotas anunciadas via BGP que você não quer que sejam usadas:

# Criar rota de blackhole para bloquear saída para um range específico
az network route-table route create \
  --route-table-name rt-application \
  --resource-group rg-networking \
  --name block-sensitive-range \
  --address-prefix 203.0.113.0/24 \
  --next-hop-type None

Comportamento de Rota com BGP Propagation

Route Tables têm uma configuração chamada "Disable BGP route propagation". Por padrão, rotas aprendidas via BGP de um VPN Gateway ou ExpressRoute são automaticamente propagadas para as subnets da VNet. Se você desabilitar essa propagação na Route Table de uma subnet, as rotas BGP não chegam àquela subnet.

Esse comportamento é importante em cenários onde você quer controlar explicitamente todo o roteamento on-premises de uma subnet via UDRs, sem interferência das rotas BGP automáticas.

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: criação pontual, verificação de rotas, diagnóstico visual.

Caminho para criar Route Table: Create a resource > Networking > Route table

Caminho para adicionar rotas: Route table > Routes > Add

Caminho para associar a uma subnet: Route table > Subnets > Associate ou pelo lado da subnet: Virtual Network > Subnet > Route table

Caminho para verificar effective routes: Network interface > Help > Effective routes

6.2 Azure CLI

Criar Route Table:

az network route-table create \
  --name rt-spoke-to-hub \
  --resource-group rg-networking \
  --location brazilsouth \
  --disable-bgp-route-propagation false

Adicionar rota para forçar tráfego de internet via Firewall:

az network route-table route create \
  --route-table-name rt-spoke-to-hub \
  --resource-group rg-networking \
  --name route-internet-via-firewall \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4

Adicionar rota para on-premises via Firewall:

az network route-table route create \
  --route-table-name rt-spoke-to-hub \
  --resource-group rg-networking \
  --name route-onprem-via-firewall \
  --address-prefix 192.168.0.0/16 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4

Associar Route Table a uma subnet:

az network vnet subnet update \
  --name subnet-application \
  --vnet-name vnet-spoke \
  --resource-group rg-networking \
  --route-table rt-spoke-to-hub

Verificar effective routes de uma NIC:

az network nic show-effective-route-table \
  --name nic-vm-app \
  --resource-group rg-producao \
  --output table

Desassociar Route Table de uma subnet:

az network vnet subnet update \
  --name subnet-application \
  --vnet-name vnet-spoke \
  --resource-group rg-networking \
  --remove routeTable

Listar todas as rotas de uma Route Table:

az network route-table route list \
  --route-table-name rt-spoke-to-hub \
  --resource-group rg-networking \
  --output table

6.3 PowerShell

# Criar Route Table
$routeTable = New-AzRouteTable `
  -Name "rt-spoke-to-hub" `
  -ResourceGroupName "rg-networking" `
  -Location "brazilsouth"

# Adicionar rota de internet via Firewall
Add-AzRouteConfig `
  -RouteTable $routeTable `
  -Name "route-internet-via-firewall" `
  -AddressPrefix "0.0.0.0/0" `
  -NextHopType "VirtualAppliance" `
  -NextHopIpAddress "10.0.1.4" |
  Set-AzRouteTable

# Adicionar rota para on-premises via Firewall
Add-AzRouteConfig `
  -RouteTable $routeTable `
  -Name "route-onprem-via-firewall" `
  -AddressPrefix "192.168.0.0/16" `
  -NextHopType "VirtualAppliance" `
  -NextHopIpAddress "10.0.1.4" |
  Set-AzRouteTable

# Associar a uma subnet
$vnet = Get-AzVirtualNetwork -Name "vnet-spoke" -ResourceGroupName "rg-networking"
$subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name "subnet-application"
$subnet.RouteTable = $routeTable
Set-AzVirtualNetwork -VirtualNetwork $vnet

# Verificar effective routes
Get-AzEffectiveRouteTable `
  -NetworkInterfaceName "nic-vm-app" `
  -ResourceGroupName "rg-producao" |
  Format-Table

6.4 Bicep

resource routeTable 'Microsoft.Network/routeTables@2023-05-01' = {
  name: 'rt-spoke-to-hub'
  location: location
  properties: {
    disableBgpRoutePropagation: false
    routes: [
      {
        name: 'route-internet-via-firewall'
        properties: {
          addressPrefix: '0.0.0.0/0'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: '10.0.1.4'
        }
      }
      {
        name: 'route-onprem-via-firewall'
        properties: {
          addressPrefix: '192.168.0.0/16'
          nextHopType: 'VirtualAppliance'
          nextHopIpAddress: '10.0.1.4'
        }
      }
    ]
  }
}

// Associar à subnet
resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-05-01' = {
  name: 'subnet-application'
  parent: vnet
  properties: {
    addressPrefix: '10.1.1.0/24'
    routeTable: {
      id: routeTable.id
    }
  }
}

7. Controle e Segurança

O Problema de Roteamento Assimétrico

O roteamento assimétrico é o erro mais crítico ao configurar UDRs com NVAs/Firewalls. Ele ocorre quando o tráfego de entrada (inbound) e o tráfego de retorno (return) percorrem caminhos diferentes, e o appliance de inspeção vê apenas metade do fluxo:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A solução é garantir que tanto o tráfego de entrada quanto o de retorno passem pelo mesmo appliance. Isso é feito aplicando UDRs consistentes em ambas as direções do tráfego.

UDR na GatewaySubnet: Cuidado Especial

Associar uma Route Table à GatewaySubnet é possível, mas extremamente arriscado. Uma UDR incorreta pode interromper toda a conectividade VPN/ExpressRoute. A Microsoft não recomenda colocar UDRs na GatewaySubnet a menos que você tenha certeza absoluta do impacto.

A única UDR segura na GatewaySubnet seria para garantir que tráfego de endereços específicos não saia pela internet, mas mesmo isso deve ser feito com muito cuidado e testado em ambiente não produtivo primeiro.

8. Tomada de Decisão

Quando usar UDR vs. NSG vs. Azure Firewall?

Objetivo	Ferramenta	Motivo
Bloquear tráfego de uma porta específica	NSG	NSG opera em L4, mais simples e eficiente
Forçar inspeção de tráfego antes de liberar	UDR + Azure Firewall/NVA	UDR redireciona, Firewall inspeciona e decide
Bloquear tráfego para um prefixo via roteamento	UDR com Next hop: None	Alternativa ao NSG, mais eficiente para grandes blocos
Garantir saída para internet via Firewall centralizado	UDR com 0.0.0.0/0 → VirtualAppliance	Force tunneling padrão em hub-spoke
Rotear tráfego on-premises via gateway específico	UDR com prefixo → VirtualNetworkGateway	Controle preciso sobre qual tráfego usa o gateway

Em quais subnets associar Route Tables?

Subnet	Associar RT?	Configuração típica
Subnets de workload (app, backend, db)	Sim	`0.0.0.0/0` → Firewall; prefixos on-premises → Firewall
AzureFirewallSubnet	Sim (apenas rotas específicas)	Rota para on-premises via VPN Gateway
GatewaySubnet	Raramente, com cuidado extremo	Apenas se absolutamente necessário
AzureBastionSubnet	Não recomendado	Bastion tem requisitos específicos de roteamento
Subnets de serviços gerenciados delegados	Verificar documentação do serviço	Alguns serviços não suportam RTs

9. Boas Práticas

Sempre teste UDRs em ambiente não produtivo primeiro: uma UDR incorreta pode criar loops de roteamento ou blackholes que interrompem completamente a conectividade de uma subnet. Um ambiente de desenvolvimento onde você pode validar o comportamento antes de aplicar em produção é essencial.

Verifique as effective routes antes e depois de aplicar: use a ferramenta de effective routes do Network Watcher para confirmar exatamente quais rotas estão ativas em uma NIC após aplicar uma Route Table. Isso confirma que a UDR está se comportando como esperado.

Nomeie rotas de forma descritiva: route-internet-via-azfw, route-onprem-192-168-via-azfw, blackhole-rfc1918-unused são nomes que imediatamente comunicam o propósito da rota. Rotas com nomes como route1, route2 tornam a manutenção e diagnóstico muito mais difíceis.

Mantenha Route Tables separadas por função: uma RT para subnets de spoke que forçam tráfego via hub, uma RT para a AzureFirewallSubnet, uma RT para subnets de gerenciamento. Compartilhar a mesma RT entre subnets de funções muito diferentes torna mudanças mais arriscadas.

Use uma Route Table compartilhada por múltiplas subnets quando as rotas são idênticas: se todas as subnets de um spoke precisam das mesmas rotas, uma única Route Table associada a todas é mais fácil de manter do que múltiplas cópias.

10. Erros Comuns

Criar a UDR mas esquecer de associar à subnet

A Route Table existe, as rotas estão configuradas, mas o tráfego ainda segue as rotas de sistema. A causa é que a Route Table não foi associada a nenhuma subnet. Verificar as effective routes da NIC imediatamente mostra que as UDRs não aparecem, revelando o problema.

Roteamento assimétrico por UDR parcial

A UDR é aplicada apenas na subnet de saída (ex: subnet-backend → Firewall), mas não na subnet de entrada ou no caminho de retorno. O Firewall vê apenas metade das conexões, não pode manter estado, e descarta pacotes de retorno. Todas as conexões ficam intermitentes ou falham. A solução é garantir que o tráfego de ambas as direções de uma conexão passe pelo mesmo appliance.

Loop de roteamento entre NVA e Route Table

Uma UDR direciona 0.0.0.0/0 para o IP da NVA (10.0.1.4). A NVA está na mesma subnet que tem a Route Table. O tráfego da NVA em direção ao próximo hop entra em loop: vai para si mesma. A solução é colocar a NVA em uma subnet separada sem a Route Table de redirecionamento, ou garantir que a Route Table da subnet da NVA tenha a rota 0.0.0.0/0 → Internet (não → VirtualAppliance).

Não habilitar IP Forwarding na NIC da NVA

A UDR redireciona tráfego para a NVA (10.0.1.4), mas o tráfego chega na NIC e é descartado porque o IP de destino do pacote não é 10.0.1.4 (é o destino final, como 8.8.8.8). O Azure descarta o pacote por segurança. Habilitar IP Forwarding na NIC do Azure E no sistema operacional da NVA resolve o problema.

Aplicar UDR na GatewaySubnet sem testar

Um administrador aplica uma Route Table na GatewaySubnet para controlar o tráfego de on-premises. A rota está ligeiramente errada, e toda a conectividade VPN cai imediatamente. Como o acesso ao Azure agora só é possível via VPN (que caiu), o administrador não consegue acessar o portal para corrigir. Sempre mantenha um caminho de acesso alternativo (por exemplo, uma conta de acesso de emergência com acesso ao portal via internet) antes de modificar roteamento crítico.

11. Operação e Manutenção

Diagnóstico com Network Watcher

Duas ferramentas do Network Watcher são essenciais para diagnóstico de roteamento:

Effective Routes: mostra todas as rotas ativas em uma NIC, incluindo sistema, UDRs, BGP e peering. Mostra a fonte de cada rota e qual está sendo usada para cada destino.

az network watcher show-next-hop \
  --resource-group rg-producao \
  --vm vm-app-01 \
  --source-ip 10.1.1.4 \
  --dest-ip 8.8.8.8

Esse comando responde diretamente: "se uma VM com IP 10.1.1.4 tentar alcançar 8.8.8.8, qual é o próximo salto e qual rota está sendo usada?"

Connection Troubleshoot: testa conectividade ponta a ponta e identifica onde no caminho a comunicação está sendo bloqueada ou redirecionada.

Auditoria de Route Tables Sem Associação

Route Tables sem subnets associadas são recursos órfãos que não têm utilidade mas podem causar confusão:

az network route-table list \
  --query "[?subnets==null || length(subnets)==`0`].{Nome:name, RG:resourceGroup}" \
  --output table

Limites Importantes

Item	Limite
Route Tables por assinatura por região	200
Rotas por Route Table	400
Route Tables por subnet	1 (apenas uma RT por subnet)
Subnets por Route Table	Sem limite documentado

O limite de 400 rotas por Route Table raramente é atingido em cenários típicos, mas em ambientes com muitas redes on-premises anunciadas via BGP que precisam ser sobrescritas por UDRs, pode ser relevante.

12. Integração e Automação

UDRs em Arquitetura Hub-Spoke Completa

A configuração completa de UDRs em uma arquitetura hub-spoke típica envolve múltiplas Route Tables:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

A RT da subnet do Firewall (rt-azfw-subnet) é necessária para que o Firewall saiba rotear tráfego destinado a on-premises via o VPN Gateway, em vez de tentar acessar diretamente. Sem ela, o Firewall pode descartar ou rotear incorretamente o tráfego on-premises.

Automação de Deploy via Terraform

resource "azurerm_route_table" "spoke_rt" {
  name                          = "rt-spoke-to-hub"
  location                      = var.location
  resource_group_name           = var.resource_group
  disable_bgp_route_propagation = false

  route {
    name                   = "route-internet-via-firewall"
    address_prefix         = "0.0.0.0/0"
    next_hop_type          = "VirtualAppliance"
    next_hop_in_ip_address = var.firewall_private_ip
  }

  route {
    name                   = "route-onprem-via-firewall"
    address_prefix         = "192.168.0.0/16"
    next_hop_type          = "VirtualAppliance"
    next_hop_in_ip_address = var.firewall_private_ip
  }
}

resource "azurerm_subnet_route_table_association" "app" {
  subnet_id      = azurerm_subnet.application.id
  route_table_id = azurerm_route_table.spoke_rt.id
}

Azure Policy para Conformidade de Roteamento

# Criar policy para auditar subnets sem Route Table
az policy assignment create \
  --name "audit-subnet-route-table" \
  --policy "/providers/Microsoft.Authorization/policyDefinitions/fc5e4038-4584-4632-8c85-c0448d374b2c" \
  --scope "/subscriptions/<sub-id>"

Essa política integrada audita subnets que não têm Route Table associada, ajudando a garantir que o roteamento centralizado via Firewall está em vigor em todas as subnets de workload.

13. Resumo Final

Pontos essenciais:

UDRs controlam o caminho do tráfego, não se ele é permitido. NSGs controlam permissão. Os dois são complementares.
Uma Route Table é o contêiner de UDRs. Ela precisa ser associada a subnets para ter efeito. Uma subnet pode ter apenas uma Route Table.
Cada rota tem: address prefix (destino), next hop type e next hop address (quando aplicável).
UDRs têm prioridade sobre rotas de sistema quando têm o mesmo prefixo. Prefixos mais específicos sempre vencem, independentemente da fonte.

Diferenças críticas:

Next hop VirtualAppliance vs. VirtualNetworkGateway: o primeiro redireciona para um IP privado de NVA/Firewall; o segundo usa o gateway VPN/ExpressRoute da VNet.
Next hop None vs. NSG Deny: None descarta silenciosamente (sem resposta ao emissor); NSG Deny pode retornar uma resposta explícita. Ambos bloqueiam o tráfego mas por mecanismos diferentes.
Route Table vs. Effective Routes: a Route Table é o que você configura; as Effective Routes são o resultado final após combinação com rotas de sistema, BGP e peering.
Disable BGP route propagation desabilitado (padrão): rotas BGP chegam à subnet. Habilitado: apenas UDRs explícitas são usadas, sem rotas BGP automáticas.

O que precisa ser lembrado:

Para NVAs de terceiros, habilitar IP Forwarding na NIC do Azure E no sistema operacional é obrigatório. Para Azure Firewall, é automático.
Roteamento assimétrico é o erro mais crítico: garantir que tráfego de ida e volta passe pelo mesmo appliance de inspeção.
Nunca aplique Route Tables na GatewaySubnet sem testes rigorosos; pode derrubar toda a conectividade VPN.
Sempre verifique effective routes de uma NIC após aplicar uma Route Table para confirmar o comportamento esperado.
O comando az network watcher show-next-hop responde diretamente qual rota será usada para um par de IPs específico, essencial para diagnóstico.
Route Table associada a uma subnet que tem recursos mas sem rotas configuradas ainda não faz nada; as rotas de sistema continuam vigentes.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 Como o Roteamento Funciona no Azure: Rotas de Sistema​

3.2 O que é uma User-Defined Route​

3.3 Os Tipos de Next Hop​

3.4 Route Tables: O Contêiner das UDRs​

3.5 Precedência de Rotas​

4. Visão Estrutural​

Cenário Clássico: Force Tunneling via Azure Firewall​

Effective Routes: A Visão Completa​

5. Funcionamento na Prática​

O Problema do IP Forwarding​

Rota de Blackhole para Bloqueio por Roteamento​

Comportamento de Rota com BGP Propagation​

6. Formas de Implementação​

6.1 Portal do Azure​

6.2 Azure CLI​

6.3 PowerShell​

6.4 Bicep​

7. Controle e Segurança​

O Problema de Roteamento Assimétrico​

UDR na GatewaySubnet: Cuidado Especial​

8. Tomada de Decisão​

Quando usar UDR vs. NSG vs. Azure Firewall?​

Em quais subnets associar Route Tables?​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Diagnóstico com Network Watcher​

Auditoria de Route Tables Sem Associação​

Limites Importantes​

12. Integração e Automação​

UDRs em Arquitetura Hub-Spoke Completa​

Automação de Deploy via Terraform​

Azure Policy para Conformidade de Roteamento​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 Como o Roteamento Funciona no Azure: Rotas de Sistema

3.2 O que é uma User-Defined Route

3.3 Os Tipos de Next Hop

3.4 Route Tables: O Contêiner das UDRs

3.5 Precedência de Rotas

4. Visão Estrutural

Cenário Clássico: Force Tunneling via Azure Firewall

Effective Routes: A Visão Completa

5. Funcionamento na Prática

O Problema do IP Forwarding

Rota de Blackhole para Bloqueio por Roteamento

Comportamento de Rota com BGP Propagation

6. Formas de Implementação

6.1 Portal do Azure

6.2 Azure CLI

6.3 PowerShell

6.4 Bicep

7. Controle e Segurança

O Problema de Roteamento Assimétrico

UDR na GatewaySubnet: Cuidado Especial

8. Tomada de Decisão

Quando usar UDR vs. NSG vs. Azure Firewall?

Em quais subnets associar Route Tables?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Diagnóstico com Network Watcher

Auditoria de Route Tables Sem Associação

Limites Importantes

12. Integração e Automação

UDRs em Arquitetura Hub-Spoke Completa

Automação de Deploy via Terraform

Azure Policy para Conformidade de Roteamento

13. Resumo Final