O NovaBank exige que todo o tráfego de saída da internet das VNets do Azure seja inspecionado por um dispositivo de segurança on-premises. Eles implantaram o Azure Firewall no hub e querem forçar o tunelamento do tráfego de saída através de um circuito ExpressRoute para o dispositivo, enquanto ainda permitem que o tráfego de serviço do Azure (por exemplo, Azure SQL) vá diretamente para o Azure sem "hairpinning" através do ambiente on-prem. Qual combinação de recursos do Azure Firewall e de roteamento atende a esse requisito?

A opção correta aborda o tunelamento forçado de forma eficiente e com as exceções necessárias. O Azure Firewall pode ser configurado para tunelamento forçado, direcionando 0.0.0.0/0 para um Gateway de Rede Virtual. Anunciar uma rota padrão via BGP garante que o tráfego de saída seja direcionado para o dispositivo on-premises para inspeção. Para serviços do Azure como o Azure SQL, as exceções baseadas em IP (tags de serviço) configuradas no dispositivo on-premises permitem que esse tráfego ignore o túnel e vá diretamente para o Azure, evitando o "hairpinning". As outras opções estão incorretas porque: A primeira opção sugere uma rota UDR com next hop 'Virtual appliance' apontando para o IP on-premises, o que não é a forma padrão de configurar o tunelamento forçado com o Azure Firewall para um gateway on-premises, e as exceções UDR para tags de serviço não são aplicáveis diretamente ao tunelamento forçado do Firewall. A segunda opção propõe uma UDR nas VNets spoke para o dispositivo on-premises, o que ignora o Azure Firewall para inspeção centralizada, e desabilitar o SNAT do Firewall não resolve o requisito de tunelamento forçado. A quarta opção sugere enviar 0.0.0.0/0 para a Internet e usar o Firewall com 'Next hop type: Virtual appliance' para o dispositivo on-premises, o que é contraditório e não é a maneira correta de implementar o tunelamento forçado para um dispositivo on-premises via ExpressRoute.