Planejar e implementar Rotas User-Defined (UDRs)

Você pode criar rotas personalizadas ou definidas pelo usuário (estáticas) no Azure para substituir as rotas padrão do sistema do Azure ou para adicionar mais rotas à tabela de rotas de uma sub-rede. No Azure, crie uma tabela de rotas e associe-a a nenhuma ou a mais sub-redes da rede virtual. Cada sub-rede pode ter zero ou uma tabela de rotas associada a si. Para saber mais sobre o número máximo de rotas que pode adicionar a uma tabela de rotas e o número máximo de tabelas de rotas definidas pelo utilizador que pode criar por subscrição do Azure, veja Limites do Azure. Quando você cria uma tabela de rotas e a associa a uma sub-rede, as rotas da tabela são combinadas com as rotas padrão da sub-rede. Se houver atribuições de rota conflitantes, as rotas definidas pelo usuário substituem as rotas padrão.

Ao criar uma rota definida pelo utilizador, pode especificar os tipos de próximo salto abaixo:

• Aplicação virtual: uma aplicação virtual é uma máquina virtual que, normalmente, executa uma aplicação de rede, como uma firewall. Para saber mais sobre vários dispositivos virtuais de rede pré-configurados que você pode implantar em uma rede virtual, consulte o Azure Marketplace. Quando cria uma rota com o tipo de salto de aplicação virtual, também deve especificar um endereço IP do próximo salto. O endereço IP pode ser:

  • O endereço IP privado de uma interface de rede ligada a uma máquina virtual. Qualquer interface de rede ligada a uma máquina virtual que reencaminhe o tráfego de rede para um endereço que não o da mesma tem de ter a opção do Azure Ativar reencaminhamento de IP ativada. A definição desativa a verificação por parte do Azure da origem e do destino de uma interface de rede. Saiba mais sobre como ativar o reencaminhamento de IP em interfaces de rede. Embora Ativar o reencaminhamento de IPs seja uma definição do Azure, também poderá ser necessário ativar o reencaminhamento de IP dentro do sistema operativo da máquina virtual, de modo a que a aplicação reencaminhe o tráfego entre as interfaces de rede dos endereços IP privados atribuídos ao Azure. Se o dispositivo precisar rotear o tráfego para um endereço IP público, ele deverá fazer proxy do tráfego ou executar a conversão de endereços de rede (NAT) do endereço IP privado da fonte para seu próprio endereço IP privado. Em seguida, o Azure executa NAT para um endereço IP público antes de enviar o tráfego para a Internet. Para determinar as definições necessárias na máquina virtual, veja a documentação relativa ao seu sistema operativo ou à sua aplicação de rede. Para compreender as ligações de saída no Azure, veja Compreender as ligações de saída.
    
  • O endereço IP privado de um Balanceador de carga interno do Azure. Muitas vezes, são utilizados balanceadores de carga como parte de uma estratégia de elevada disponibilidade para aplicações de redes virtuais.

Você pode definir uma rota com 0.0.0.0/0 como o prefixo de endereço e um tipo de aplicação virtual de próximo salto. Essa configuração permite que o dispositivo inspecione o tráfego e determine se o tráfego deve ser encaminhado ou descartado. Se quiser criar uma rota definida pelo utilizador que contenha o prefixo de endereço 0.0.0.0/0, leia prefixo de endereço 0.0.0.0/0 primeiro.

• Gateway de rede virtual: especifique se quiser que o tráfego destinado a prefixos de endereços específicos seja encaminhado para um gateweay de rede virtual. O gateway de rede virtual tem de ser criado com o tipo VPN. Não é possível especificar um gateway de rede virtual criado como tipo ExpressRoute em uma rota definida pelo usuário porque, com ExpressRoute, você deve usar BGP para rotas personalizadas. Também não é possível especificar Gateways de Rede Virtual se você tiver conexões coexistentes VPN e Rota Expressa. Pode definir uma rota que direciona o tráfego destinado ao prefixo de endereço 0.0.0.0/0 para um gateway de rede virtual baseado numa rota. Nas suas instalações, poderá ter um dispositivo que inspeciona o tráfego e determina se este deve ser reencaminhado ou descartado. Se quiser criar uma rota definida pelo utilizador para o prefixo de endereço 0.0.0.0/0, leia prefixo de endereço 0.0.0.0/0 primeiro. Em vez de configurar uma rota definida pelo utilizador para o prefixo de endereço 0.0.0.0/0, pode anunciar uma rota com o prefixo 0.0.0.0/0 através do BGP, se tiver ativado o BGP num gateway de rede virtual VPN.
• Nenhum: especifique se quiser ignorar o tráfego para um prefixo de endereço, em vez de o reencaminhar para um destino. Se ainda não tiver configurado uma capacidade, o Azure poderá apresentar Nenhum em algumas das rotas do sistema opcionais. Por exemplo, se vir Nenhum apresentado como o Endereço IP do próximo salto com o Tipo de próximo salto de Gateway de rede virtual ou Aplicação Virtual, poderá dever-se ao facto de o dispositivo não estar em execução ou totalmente configurado. O Azure cria rotas do sistema predefinidas para prefixos de endereço reservado com Nenhum como o tipo de próximo salto.
  
• Rede virtual: especifique a opção Rede virtual quando quiser substituir o roteamento padrão em uma rede virtual.
  
• Internet: especifique a opção Internet quando desejar rotear explicitamente o tráfego destinado a um prefixo de endereço para a Internet ou se desejar tráfego destinado a serviços do Azure com endereços IP públicos mantidos na rede de backbone do Azure. Consulte Exemplo de roteamento, para obter um exemplo de por que você pode criar uma rota com o tipo de salto de rede virtual.
  

Não é possível especificar o emparelhamento de rede virtual ou VirtualNetworkServiceEndpoint como o próximo tipo de salto em rotas definidas pelo usuário. As rotas com os tipos de próximo salto de emparelhamento de rede virtual ou VirtualNetworkServiceEndpoint são criadas apenas pelo Azure, quando você configura um emparelhamento de rede virtual ou um ponto de extremidade de serviço.

Etiquetas de serviço para rotas definidas pelo utilizador

Agora você pode especificar uma marca de serviço como o prefixo de endereço para uma rota definida pelo usuário em vez de um intervalo de IP explícito. Uma marca de serviço representa um grupo de prefixos de endereço IP de um determinado serviço do Azure. A Microsoft gerencia os prefixos de endereço incluídos pela etiqueta de serviço e atualiza automaticamente a etiqueta de serviço à medida que os endereços mudam. Assim, minimizando a complexidade de atualizações frequentes para rotas definidas pelo usuário e reduzindo o número de rotas que você precisa criar. Atualmente, você pode criar 25 ou menos rotas com tags de serviço em cada tabela de rotas. Com esta versão, o uso de tags de serviço em cenários de roteamento para contêineres também é suportado.

Correspondência exata

O sistema dá preferência à rota com o prefixo explícito quando há uma correspondência de prefixo exata entre uma rota com um prefixo IP explícito e uma rota com uma etiqueta de serviço. Quando várias rotas com etiquetas de serviço têm prefixos IP correspondentes, as rotas são avaliadas na seguinte ordem:

1. Tags regionais (por exemplo, Storage.EastUS, AppService.AustraliaCentral)
   
2. Tags de nível superior (por exemplo, Storage, AppService)
   
3. Tags regionais do AzureCloud (por exemplo, AzureCloud.canadacentral, AzureCloud.eastasia)
   
4. A tag AzureCloud
   

Para usar esse recurso, especifique um nome de etiqueta de serviço para o parâmetro de prefixo de endereço nos comandos da tabela de rotas. Por exemplo, no PowerShell, você pode criar uma nova rota para direcionar o tráfego enviado para um prefixo IP de Armazenamento do Azure para um dispositivo virtual usando:

$param = @{ Name = 'StorageRoute' AddressPrefix = 'Storage' NextHopType = 'VirtualAppliance' NextHopIpAddress = '10.0.100.4' } New-AzRouteConfig @param

O mesmo comando para a CLI do Azure é:

az network route-table route create \ --resource-group MyResourceGroup \ --route-table-name MyRouteTable \ --name StorageRoute \ --address-prefix Storage \ --next-hop-type VirtualAppliance \ --next-hop-ip-address 10.0.100.4

Tipos de próximo salto transversais às ferramentas do Azure

O nome exibido e referenciado para os tipos de próximo salto é diferente entre o portal do Azure e as ferramentas de linha de comando, e o Gerenciador de Recursos e os modelos de implantação clássicos. A tabela a seguir lista os nomes usados para se referir a cada tipo de salto seguinte com as diferentes ferramentas e modelos de implantação.

Expandir tabela

Tipo de salto seguinte	CLI do Azure e PowerShell (Gerenciador de Recursos)	CLI clássica do Azure e PowerShell (clássico)
Gateway de rede virtual	VirtualNetworkGateway	VPNGateway
Rede virtual	VNetLocal	VNETLocal (não disponível na CLI clássica no modo de modelo de implantação clássico)
Internet	Internet	Internet (não disponível na CLI clássica no modo de modelo de implantação clássico)
Dispositivo virtual	VirtualAppliance	VirtualAppliance
Nenhum	Nenhum	Nulo (não disponível na CLI clássica no modo de modelo de implantação clássico)
Conexão de rede virtual	Conexão de rede virtual	Não aplicável
Ponto final de serviço de rede virtual	Ponto Final de Serviço de Rede Virtual	Não aplicável

Protocolo de Gateway de Fronteira (BGP)

Um gateway de rede local pode trocar rotas com um gateway de rede virtual do Azure usando o BGP. Usar BGP com um gateway de rede virtual do Azure depende do tipo selecionado quando você criou o gateway:

• ExpressRoute: tem de utilizar o BGP para anunciar rotas no local no router do Microsoft Edge. Não é possível criar UDRs para forçar o tráfego para o gateway de rede virtual ExpressRoute se você implantar um gateway de rede virtual implantado como o tipo ExpressRoute. Você pode usar UDRs para forçar o tráfego da rota expressa para, por exemplo, um dispositivo virtual de rede.
• VPN: Opcionalmente, você pode usar BGP. Para obter mais informações, consulte BGP com conexões VPN site-a-site.

Quando você troca rotas com o Azure usando BGP, uma rota separada é adicionada à tabela de rotas de todas as sub-redes em uma rede virtual para cada prefixo anunciado. A rota é adicionada com Gateway de rede virtual listado como a origem e o tipo de próximo salto.

Você pode desativar a propagação de rotas do ExpressRoute e do Gateway de VPN do Azure numa sub-rede usando uma propriedade de uma tabela de rotas. Quando desativa a propagação de rotas, o sistema não adiciona rotas à tabela de rotas de todas as sub-redes com a propagação de rotas do gateway de rede virtual desativada. Este processo aplica-se a rotas estáticas e a rotas BGP. A conectividade com ligações VPN é obtida utilizando rotas personalizadas com um tipo de salto seguinte de portal de rede virtual. Para obter mais informações, consulte Desativar a propagação de rota do gateway de rede virtual.

Como o Azure seleciona uma rota

Quando o tráfego de saída é enviado de uma sub-rede, o Azure seleciona uma rota com base no endereço IP de destino usando o algoritmo de correspondência de prefixo mais longo. Por exemplo, uma tabela de rotas tem duas rotas. Uma rota especifica o prefixo de endereço 10.0.0.0/24 e a outra rota especifica o prefixo de endereço 10.0.0.0/16.

O Azure direciona o tráfego destinado a 10.0.0.5 para o próximo tipo de salto especificado na rota com o prefixo de endereço 10.0.0.0/24. Esse processo ocorre porque 10.0.0.0/24 é um prefixo mais longo do que 10.0.0.0/16, embora 10.0.0.5 esteja dentro de ambos os prefixos de endereço.

O Azure direciona o tráfego destinado a 10.0.1.5 para o próximo tipo de salto especificado na rota com o prefixo de endereço 10.0.0.0/16. Esse processo ocorre porque 10.0.1.5 não está incluído no prefixo de endereço 10.0.0.0/24, o que torna a rota com o prefixo de endereço 10.0.0.0/16 o prefixo de correspondência mais longo.

Se várias rotas contiverem o mesmo prefixo de endereço, o Azure selecionará o tipo de rota com base na seguinte prioridade:

1. Rota definida pelo utilizador
2. Rota BGP
3. Rota do sistema

Por exemplo, uma tabela de rotas contém as rotas seguintes:

Expandir tabela

Fonte	Prefixos de endereço	Tipo de salto seguinte
Predefinido	0.0.0.0/0	Internet
Utilizador	0.0.0.0/0	Gateway de rede virtual

Quando o tráfego é destinado a um endereço IP fora dos prefixos de endereço de quaisquer outras rotas na tabela de rotas, o Azure seleciona a rota com a origem do usuário. O Azure faz essa escolha porque as UDRs são uma prioridade maior do que as rotas padrão do sistema.

Para obter uma tabela de roteamento abrangente com explicações das rotas na tabela, consulte Exemplo de roteamento.

Prefixo de endereço 0.0.0.0/0

Uma rota com o prefixo de endereço 0.0.0.0/0 fornece instruções ao Azure. O Azure usa estas instruções para rotear o tráfego destinado a um endereço IP que não se enquadra no prefixo de endereço de nenhuma outra rota na tabela de rotas de uma sub-rede. Quando uma sub-rede é criada, o Azure cria uma rota padrão para o prefixo de endereço 0.0.0.0/0, com o tipo de salto seguinte da Internet. Se você não substituir essa rota, o Azure roteia todo o tráfego destinado a endereços IP não incluídos no prefixo de endereço de qualquer outra rota para a Internet.

A exceção é que o tráfego para os endereços IP públicos dos serviços do Azure permanece na rede de backbone do Azure e não é roteado para a Internet. Quando você substitui essa rota por uma rota personalizada , o tráfego destinado a endereços que não estão dentro dos prefixos de endereço de qualquer outra rota na tabela de rotas é direcionado. O destino depende se você especificar um dispositivo virtual de rede ou gateway de rede virtual na rota personalizada.

Quando você substitui o prefixo de endereço 0.0.0.0/0, o tráfego de saída da sub-rede flui através do gateway de rede virtual ou dispositivo virtual. As seguintes alterações também ocorrem com o roteamento padrão do Azure:

• O Azure envia o tráfego ao tipo de próximo salto especificado na rota, incluindo o tráfego destinado aos endereços IP públicos dos serviços do Azure.

  Quando o próximo tipo de salto para a rota com o prefixo de endereço 0.0.0.0/0 é Internet, o tráfego da sub-rede destinada aos endereços IP públicos dos serviços do Azure nunca sai da rede de backbone do Azure, independentemente da região do Azure na qual a rede virtual ou o recurso de serviço do Azure existe.

  Quando se cria uma rota UDR ou BGP com um gateway de rede virtual ou um tipo de próximo salto de uma aplicação virtual, todo o tráfego é enviado para o próximo tipo de salto especificado na rota. Isso inclui o tráfego enviado para endereços IP públicos de serviços do Azure para os quais você não habilitou pontos de extremidade de serviço.

  Quando você habilita um ponto de extremidade de serviço para um serviço, o Azure cria uma rota com prefixos de endereço para o serviço. O tráfego para o serviço não é encaminhado para o próximo tipo de salto em uma rota com o prefixo de endereço 0.0.0.0/0. Os prefixos de endereço para o serviço são mais longos que 0.0.0.0/0.

• Você não pode mais acessar diretamente os recursos na sub-rede a partir da Internet. Você pode acessar recursos na sub-rede da Internet indiretamente. O dispositivo especificado pelo próximo tipo de salto para uma rota com o prefixo de endereço 0.0.0.0/0 deve processar o tráfego de entrada. Depois que o tráfego atravessa o dispositivo, o tráfego atinge o recurso na rede virtual. Se a rota contiver os seguintes valores para o próximo tipo de salto:

  • Dispositivo virtual: O dispositivo deve:

    • Ser acessível a partir da internet.
    • Ter um endereço IP público atribuído a ele.
    • Não ter uma regra de grupo de segurança de rede associada a ela que impeça a comunicação com o dispositivo.
    • Não negar a comunicação.
    • Ser capaz de traduzir e encaminhar endereços de rede, ou fazer proxy do tráfego para o recurso de destino na sub-rede e retornar o tráfego para a Internet.

  • Gateway de rede virtual: se o gateway for um gateway de rede virtual da Rota Expressa, um dispositivo conectado à Internet no local poderá converter e encaminhar endereços de rede ou fazer proxy do tráfego para o recurso de destino na sub-rede, por meio do emparelhamento privado da Rota Expressa.

Se sua rede virtual estiver conectada a um gateway de VPN do Azure, não associe uma tabela de rotas à sub-rede do gateway que inclua uma rota com um destino de 0.0.0.0/0. Se o fizer, poderá impedir que o gateway funcione corretamente. Para obter mais informações, consulte Por que certas portas são abertas no meu gateway VPN?.

Para obter detalhes de implementação quando você usa gateways de rede virtual entre a Internet e o Azure, consulte DMZ entre o Azure e seu datacenter local.

Exemplo de encaminhamento

Para ilustrar os conceitos deste artigo, as seguintes seções descrevem:

• Um cenário, com requisitos.
• As rotas personalizadas que são necessárias para atender aos requisitos.
• A tabela de rotas que existe para uma sub-rede que inclui as rotas padrão e personalizadas necessárias para atender aos requisitos.

Requerimentos

1. Implemente duas redes virtuais na mesma região do Azure e ative os recursos para comunicarem entre as redes virtuais.

2. Habilite uma rede local para se comunicar com segurança com ambas as redes virtuais por meio de um túnel VPN pela Internet. Como alternativa, você pode usar uma conexão ExpressRoute, mas este exemplo usa uma conexão VPN.

3. Para uma sub-rede numa rede virtual:

   • Encaminhe todo o tráfego de saída da sub-rede por meio de um dispositivo virtual de rede para inspeção e registro. Exclua o tráfego para o Armazenamento do Azure e o tráfego dentro da sub-rede deste encaminhamento.
   • Não inspecione o tráfego entre endereços IP privados dentro da sub-rede. Permita que o tráfego flua diretamente entre todos os recursos.
   • Ignore todo o tráfego de saída destinado à outra rede virtual.
   • Habilite o tráfego de saída para o Armazenamento do Azure, para que flua diretamente para o armazenamento, sem ter de passar por um dispositivo virtual de rede.

4. Permita todo o tráfego entre todas as outras sub-redes e redes virtuais.

Execução

O diagrama a seguir mostra uma implementação por meio do modelo de implantação do Resource Manager que atende aos requisitos anteriores.

Tabelas de rotas

Aqui estão as tabelas de rotas para o exemplo de roteamento anterior.

Sub-rede1

A tabela de rotas para Subnet1 no diagrama anterior contém as seguintes rotas:

Expandir tabela

ID	Fonte	Estado	Prefixos de endereço	Tipo de salto seguinte	Endereço IP do próximo salto	Nome UDR
1	Predefinido	Inválido	10.0.0.0/16	Rede virtual
2	Utilizador	Ativo	10.0.0.0/16	Dispositivo virtual	10.0.100.4	Within-VNet1
3	Utilizador	Ativo	10.0.0.0/24	Rede virtual		Dentro do Subnet1
4	Predefinido	Inválido	10.1.0.0/16	Conexão de rede virtual
5	Predefinido	Inválido	10.2.0.0/16	Conexão de rede virtual
6	Utilizador	Ativo	10.1.0.0/16	Nenhum		ToVNet2-1-Drop
7	Utilizador	Ativo	10.2.0.0/16	Nenhum		ToVNet2-2-Drop
8	Predefinido	Inválido	10.10.0.0/16	Gateway de rede virtual	[X.X.X.X]
9	Utilizador	Ativo	10.10.0.0/16	Dispositivo virtual	10.0.100.4	To-On-Prem
10	Predefinido	Ativo	[X.X.X.X]	Ponto Final de Serviço de Rede Virtual
11	Predefinido	Inválido	0.0.0.0/0	Internet
12	Utilizador	Ativo	0.0.0.0/0	Dispositivo virtual	10.0.100.4	Default-NVA

Aqui está uma explicação de cada ID de rota:

• ID1: O Azure adicionou automaticamente esta rota para todas as sub-redes na rede virtual-1 porque 10.0.0.0/16 é o único intervalo de endereços definido no espaço de endereços da rede virtual. Se você não criar o UDR na rota ID2, o tráfego enviado para qualquer endereço entre 10.0.0.1 e 10.0.255.254 será roteado dentro da rede virtual. Esse processo ocorre porque o prefixo é maior que 0.0.0.0/0 e não se enquadra nos prefixos de endereço de nenhuma outra rota.

  O Azure alterou automaticamente o estado de Ativo para Inválido, quando ID2, um UDR, foi adicionado. Ele tem o mesmo prefixo que a rota padrão, e UDRs substituem rotas padrão. O estado dessa rota ainda está ativo para Subnet2 porque a tabela de rotas em que o UDR, ID2, está não está associada a Subnet2.

• ID2: O Azure acrescentou esta rota quando um UDR para o prefixo de endereço 10.0.0.0/16 foi associado à Subnet1 na rede virtual Virtual-network-1. O UDR especifica 10.0.100.4 como o endereço IP do dispositivo virtual porque o endereço é o endereço IP privado atribuído à máquina virtual do dispositivo virtual. A tabela de rotas na qual essa rota existe não está associada a Subnet2, portanto, a rota não aparece na tabela de rotas para Subnet2.

  Esta rota substitui a rota predefinida para o prefixo 10.0.0.0/16 (ID1), que encaminhou automaticamente o tráfego dirigido a 10.0.0.1 e 10.0.255.254 dentro da rede virtual através do tipo de próximo salto da rede virtual. Essa rota existe para atender ao requisito 3, que é forçar todo o tráfego de saída por meio de um dispositivo virtual.

• ID3: O Azure adicionou essa rota quando um UDR para o prefixo de endereço 10.0.0.0/24 foi associado à sub-rede Subnet1 . O tráfego destinado a endereços entre 10.0.0.1 e 10.0.0.254 permanece na sub-rede. O tráfego não é roteado para o dispositivo virtual especificado na regra anterior (ID2) porque tem um prefixo mais longo do que a rota ID2.

  Essa rota não foi associada a Subnet2, portanto, a rota não aparece na tabela de rotas para Subnet2. Esta rota substitui eficazmente a rota ID2 para o tráfego em Subnet1. Esta rota existe para satisfazer o requisito 3.

• ID4: O Azure adicionou automaticamente as rotas nas IDs 4 e 5 para todas as sub-redes em Virtual-network-1 quando a rede virtual foi emparelhada com Virtual-network-2.A rede virtual-2 tem dois intervalos de endereços em seu espaço de endereço, 10.1.0.0/16 e 10.2.0.0/16, portanto, o Azure adicionou uma rota para cada intervalo. Se você não criar os UDRs nas IDs de rota 6 e 7, o tráfego enviado para qualquer endereço entre 10.1.0.1-10.1.255.254 e 10.2.0.1-10.2.255.254 será roteado para a rede virtual emparelhada. Esse processo ocorre porque o prefixo é maior que 0.0.0.0/0 e não se enquadra nos prefixos de endereço de nenhuma outra rota.

  Quando você adicionou as rotas nas IDs 6 e 7, o Azure alterou automaticamente o estado de Ativo para Inválido. Esse processo ocorre porque eles têm os mesmos prefixos que as rotas nas IDs 4 e 5, e UDRs substituem rotas padrão. O estado das rotas nas IDs 4 e 5 ainda está Ativo para Subnet2 porque a tabela de rotas na qual as UDRs nas IDs 6 e 7 não está associada à Subnet2. Foi criado um peering de rede virtual para cumprir o requisito 1.

• ID5: Mesma explicação que ID4.

• ID6: O Azure adicionou estas rotas e a rota em ID7 quando as UDRs para os prefixos de endereço 10.1.0.0/16 e 10.2.0.0/16 foram associadas à sub-rede Subnet1. O Azure descarta o tráfego destinado a endereços entre 10.1.0.1-10.1.255.254 e 10.2.0.1-10.2.255.254, em vez de ser roteado para a rede virtual emparelhada, porque as UDRs substituem as rotas padrão. As rotas não estão associadas à Subnet2, portanto, as rotas não aparecem na tabela de rotas da Subnet2. As rotas substituem as rotas com os ID4 e ID5 para o tráfego que sai de Subnet1. As rotas ID6 e ID7 existem para satisfazer o requisito 3 para descartar o tráfego destinado à outra rede virtual.

• ID7: Mesma explicação que ID6.

• ID8: O Azure adicionou automaticamente essa rota para todas as sub-redes na rede virtual-1 quando um gateway de rede virtual do tipo VPN foi criado na rede virtual. O Azure adicionou o endereço IP público do gateway de rede virtual à tabela de rotas. O tráfego enviado para qualquer endereço entre 10.10.0.1 e 10.10.255.254 é encaminhado para o gateway de rede virtual. O prefixo é mais longo do que 0.0.0.0/0 e não está dentro dos prefixos de endereço de nenhuma das outras rotas. Foi criado um gateway de rede virtual para cumprir o requisito 2.

• ID9: O Azure adicionou essa rota quando um UDR para o prefixo de endereço 10.10.0.0/16 foi adicionado à tabela de rotas associada a Subnet1. Esta rota substitui o ID8. A rota envia todo o tráfego destinado à rede local para um dispositivo virtual de rede para inspeção, em vez de rotear o tráfego diretamente no local. Esta rota foi criada para satisfazer o requisito 3.

• ID10: O Azure adicionou automaticamente esta rota à sub-rede quando um ponto de extremidade de serviço para um serviço do Azure foi ativado na sub-rede. O Azure encaminha o tráfego da sub-rede para um endereço IP público do serviço através da rede da infraestrutura do Azure. O prefixo é mais longo do que 0.0.0.0/0 e não está dentro dos prefixos de endereço de nenhuma das outras rotas. Um terminal de serviço foi criado para atender ao requisito 3, permitindo que o tráfego destinado ao Armazenamento do Azure flua diretamente para o Armazenamento do Azure.

• ID11: O Azure adicionou automaticamente essa rota à tabela de rotas de todas as sub-redes em Virtual-network-1 e Virtual-network-2. O prefixo de endereço 0.0.0.0/0 é o prefixo mais curto. Qualquer tráfego enviado para endereços dentro de prefixos mais longos é encaminhado com base noutras rotas.

  Por padrão, o Azure roteia todo o tráfego destinado a endereços diferentes dos endereços especificados em uma das outras rotas para a Internet. O Azure alterou automaticamente o estado de Ativo para Inválido para a sub-rede Subnet1 quando um UDR para o prefixo de endereço 0.0.0.0/0 (ID12) foi associado à sub-rede. O estado dessa rota ainda está ativo para todas as outras sub-redes em ambas as redes virtuais porque a rota não está associada a nenhuma outra sub-rede em nenhuma outra rede virtual.

• ID12: O Azure adicionou esta rota quando um UDR para o prefixo de endereço 0.0.0.0/0 foi associado à Sub-rede Subnet1. O UDR especifica 10.0.100.4 como o endereço IP do dispositivo virtual. Essa rota não está associada a Subnet2, portanto, a rota não aparece na tabela de rotas para Subnet2. Todo o tráfego destinado a qualquer endereço que não esteja incluído nos prefixos de endereço de uma das outras rotas é enviado para a aplicação virtual.

  A adição dessa rota alterou o estado da rota padrão para o prefixo de endereço 0.0.0.0/0 (ID11) de Ativo para Inválido para Subnet1 porque um UDR substitui uma rota padrão. Esta rota existe para satisfazer o requisito 3.

Subnet2

A tabela de rotas para Subnet2 no diagrama anterior contém as seguintes rotas:

Expandir tabela

Fonte	Estado	Prefixos de endereço	Tipo de salto seguinte	Endereço IP do próximo salto
Predefinido	Ativo	10.0.0.0/16	Rede virtual
Predefinido	Ativo	10.1.0.0/16	Conexão de rede virtual
Predefinido	Ativo	10.2.0.0/16	Conexão de rede virtual
Predefinido	Ativo	10.10.0.0/16	Gateway de rede virtual	[X.X.X.X]
Predefinido	Ativo	0.0.0.0/0	Internet
Predefinido	Ativo	10.0.0.0/8	Nenhum
Predefinido	Ativo	100.64.0.0/10	Nenhum
Predefinido	Ativo	192.168.0.0/16	Nenhum

A tabela de rotas para Subnet2 contém todas as rotas padrão criadas pelo Azure e as rotas opcionais de emparelhamento de rede virtual e gateway de rede virtual. O Azure adicionou as rotas opcionais a todas as sub-redes na rede virtual quando o gateway e o peering foram adicionados à rede virtual.

O Azure removeu as rotas para os prefixos de endereço 10.0.0.0/8, 192.168.0.0/16 e 100.64.0.0/10 da tabela de rotas Subnet1 quando o UDR para o prefixo de endereço 0.0.0.0/0 foi adicionado à Subnet1.