Laboratório de Troubleshooting: Configure Forced Tunneling
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações reporta que, após uma janela de manutenção realizada na madrugada anterior, as VMs na AppSubnet de uma VNet em produção perderam acesso à internet. O ambiente usa forced tunneling: uma route table com a rota 0.0.0.0/0 → VirtualNetworkGateway está associada à AppSubnet. O gateway VPN do tipo VpnGw2 está em estado Succeeded no portal. A conexão Site-to-Site com o datacenter on-premises também aparece como Connected.
Durante a manutenção, as seguintes ações foram realizadas:
- Atualização do firmware do appliance VPN on-premises
- Redimensionamento do gateway de
VpnGw1paraVpnGw2 - Adição de uma nova subnet
DbSubnetà VNet
O time on-premises confirma que o firewall corporativo está operacional e permitindo saída para a internet normalmente. Um engenheiro executa o seguinte comando a partir de uma das VMs afetadas:
curl -I https://www.microsoft.com
# Resultado: curl: (6) Could not resolve host: www.microsoft.com
Adicionalmente, o seguinte teste é realizado:
ping 8.8.8.8
# Resultado: Request timeout for icmp_seq 0
Qual é a causa raiz da perda de acesso à internet nas VMs da AppSubnet?
A) O redimensionamento do gateway VPN recriou o recurso, desassociando a route table da AppSubnet durante o processo.
B) O firewall on-premises está bloqueando o tráfego de saída apesar de reportar estado operacional, pois a atualização de firmware pode ter redefinido as regras de ACL.
C) A adição da DbSubnet alterou o espaço de endereçamento da VNet e invalidou as rotas existentes na route table associada à AppSubnet.
D) O redimensionamento do gateway VPN interrompeu temporariamente o túnel e, após a reconexão, o BGP não reanunciou a rota 0.0.0.0/0 ao on-premises, fazendo com que o tráfego de retorno não encontre caminho de volta.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: a route table com a rota de forced tunneling foi inadvertidamente desassociada da AppSubnet durante uma operação de automação via Terraform. O state file do Terraform não reflete o estado atual do Azure, pois a pipeline foi executada com uma versão desatualizada do módulo de rede.
O ambiente é de produção crítica. As VMs na AppSubnet estão ativamente processando transações financeiras. A política de segurança exige que nenhuma VM nessa subnet tenha acesso direto à internet sem passar pelo firewall on-premises. O time de segurança está monitorando o incidente em tempo real.
Atualmente, sem a route table associada, as VMs estão usando a rota de sistema padrão do Azure e acessando a internet diretamente, violando a política de segurança.
Qual é a ação correta a tomar neste momento?
A) Executar terraform apply com o módulo atualizado para restaurar o estado desejado e reassociar a route table automaticamente.
B) Reassociar manualmente a route table à AppSubnet via portal ou CLI imediatamente, sem aguardar a correção do Terraform, para restaurar a conformidade de segurança.
C) Remover todas as rotas de sistema padrão da AppSubnet para bloquear o acesso à internet enquanto a correção via Terraform é preparada.
D) Isolar a AppSubnet aplicando um NSG de bloqueio total de saída enquanto a pipeline do Terraform é corrigida e reexecutada.
Cenário 3 — Causa Raiz
Um engenheiro implantou forced tunneling em uma VNet nova seguindo exatamente a documentação interna da empresa. A configuração foi aplicada via CLI conforme abaixo:
az network route-table create \
--name ForcedTunnelRT \
--resource-group NetRG \
--location eastus
az network route-table route create \
--route-table-name ForcedTunnelRT \
--resource-group NetRG \
--name DefaultToGateway \
--address-prefix 0.0.0.0/0 \
--next-hop-type VirtualNetworkGateway
az network vnet subnet update \
--name WorkloadSubnet \
--vnet-name ProdVNet \
--resource-group NetRG \
--route-table ForcedTunnelRT
O gateway VPN foi provisionado há três semanas e está em estado Succeeded. A conexão Site-to-Site com o on-premises também está Connected. O time on-premises confirma que o roteamento de retorno está correto.
Após a implantação, o engenheiro testa a conectividade a partir de uma VM na WorkloadSubnet:
# Teste 1: Acesso a recurso on-premises
ping 192.168.10.5
# Resultado: 64 bytes from 192.168.10.5: icmp_seq=1 ttl=62 time=18.4 ms
# Teste 2: Acesso à internet pelo caminho esperado (via on-premises)
curl -I https://ifconfig.me
# Resultado: HTTP/1.1 200 OK
# O IP retornado é o IP público do datacenter on-premises (correto)
# Teste 3: Acesso ao Azure Storage pelo endpoint público
curl -I https://mystorageaccount.blob.core.windows.net/container/file.txt
# Resultado: curl: (7) Failed to connect to mystorageaccount.blob.core.windows.net
O time de aplicação reporta que o Teste 3 funcionava perfeitamente antes da configuração do forced tunneling. O SKU do gateway VPN é VpnGw1. A VNet não possui Service Endpoints nem Private Endpoints configurados para o Storage Account.
Qual é a causa raiz da falha no Teste 3?
A) O SKU VpnGw1 não suporta o volume de tráfego necessário para rotear simultaneamente tráfego on-premises e tráfego para serviços PaaS, causando descarte de pacotes.
B) O firewall on-premises está bloqueando o tráfego destinado ao endpoint público do Storage Account, pois esse tráfego agora passa pelo túnel VPN antes de sair para a internet.
C) A rota 0.0.0.0/0 configurada na route table está redirecionando pelo gateway VPN todo o tráfego destinado ao IP público do Storage Account, que antes seguia diretamente pela rota de sistema padrão do Azure.
D) O Storage Account tem um firewall de rede configurado que passou a bloquear o IP de origem das VMs após a mudança de roteamento.
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte chamado: "VMs na FrontendSubnet não conseguem acessar a internet. O ambiente deveria ter forced tunneling ativo, mas o tráfego não está chegando ao on-premises."
Os seguintes passos de investigação estão disponíveis, mas fora de ordem:
- Passo P: Verificar no portal se a route table com a rota
0.0.0.0/0 → VirtualNetworkGatewayestá associada àFrontendSubnet - Passo Q: Acessar uma VM na
FrontendSubnete executarcurl https://ifconfig.mepara observar se o IP retornado é o IP público do Azure ou o IP do datacenter on-premises - Passo R: Verificar o estado da conexão Site-to-Site no gateway VPN (status
ConnectedouDisconnected) - Passo S: Confirmar com o time on-premises se o firewall está recebendo tráfego da VNet e permitindo saída para a internet
- Passo T: Verificar no portal se o gateway VPN está provisionado e em estado
Succeeded
Qual é a sequência correta de investigação para diagnosticar esse problema de forma progressiva e eficiente?
A) Q → P → T → R → S B) T → R → P → Q → S C) P → T → Q → S → R D) R → T → S → P → Q
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: A
O redimensionamento de um gateway VPN no Azure não é uma operação in-place: o recurso é destruído e recriado com o novo SKU. Durante esse processo, todas as associações dependentes, incluindo referências ao gateway como next hop em route tables, permanecem intactas na route table em si, mas a associação da route table à subnet pode ser mantida. O ponto crítico é que o redimensionamento do gateway gera um novo Resource ID para o recurso, e dependendo do mecanismo de automação usado, isso pode causar a desassociação.
No entanto, a pista determinante no enunciado é que o estado do gateway e da conexão aparecem como Succeeded e Connected, respectivamente. Isso elimina hipóteses relacionadas ao túnel em si. O sintoma de resolução DNS falhando (Could not resolve host) indica que o tráfego não está chegando a nenhum resolvedor, seja on-premises ou internet, sugerindo que a rota não está sendo aplicada e as VMs ficaram sem rota de saída funcional.
A informação irrelevante no cenário é a adição da DbSubnet: adicionar uma subnet a uma VNet não afeta route tables associadas a outras subnets nem invalida rotas existentes.
O distrator mais perigoso é o B. Culpar o firewall on-premises é um erro clássico de diagnóstico que desloca a investigação para fora do ambiente Azure, atrasando a identificação da causa real. Se o tráfego não sai da VM, o firewall on-premises nunca o veria, independentemente de seu estado.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é dupla: produção em operação e violação ativa de política de segurança. A reassociação manual da route table via portal ou CLI é a única ação que resolve a violação imediatamente, sem risco de efeito colateral e sem depender de ferramentas com estado desatualizado.
A alternativa A é tecnicamente correta em condições normais, mas é perigosa aqui: executar terraform apply com um módulo desatualizado e um state file divergente em um ambiente de produção crítico pode causar destruição ou modificação de recursos além da route table, ampliando o incidente.
A alternativa D representa um erro de raciocínio comum: aplicar um NSG de bloqueio total de saída interromperia as transações financeiras em andamento, causando impacto direto ao negócio que pode ser maior do que a violação de segurança temporária que está sendo monitorada.
A alternativa C é tecnicamente inválida: rotas de sistema do Azure não podem ser removidas diretamente; elas só são sobrescritas por UDRs, que é exatamente o mecanismo que falhou.
Gabarito — Cenário 3
Resposta: C
A configuração do forced tunneling está correta e funcionando como esperado. Os testes 1 e 2 confirmam que o tráfego on-premises e o tráfego de internet estão sendo roteados corretamente pelo túnel VPN. O problema com o Teste 3 é uma consequência direta e esperada do forced tunneling: a rota 0.0.0.0/0 captura todo o tráfego que não corresponde a uma rota mais específica, incluindo o tráfego destinado ao IP público do Storage Account.
Antes do forced tunneling, esse tráfego usava a rota de sistema padrão 0.0.0.0/0 → Internet e saía diretamente para a rede Microsoft pelo backbone do Azure. Após o forced tunneling, o tráfego é enviado ao on-premises, e o firewall corporativo, dependendo de sua configuração, pode estar bloqueando requisições ao endpoint do Storage Account, ou a latência adicional causa timeout.
A informação irrelevante propositalmente incluída é o SKU VpnGw1: a limitação de throughput do gateway não tem relação com o sintoma específico observado, que é uma falha de conexão, não degradação de performance.
O distrator mais perigoso é o D. Embora firewalls de rede em Storage Accounts sejam uma causa real de bloqueio, o enunciado informa que o Teste 3 funcionava antes da mudança de roteamento, o que elimina o firewall do Storage como causa nova, pois nada nele foi alterado.
Gabarito — Cenário 4
Resposta: B
A sequência correta é T → R → P → Q → S, que segue a lógica de diagnóstico progressivo do componente mais fundamental ao mais periférico.
O primeiro passo obrigatório é verificar se o gateway VPN existe e está provisionado (T), pois sem ele nenhum next hop VirtualNetworkGateway em uma UDR tem destino resolvível. Com o gateway confirmado, verifica-se o estado do túnel (R): se a conexão está Disconnected, o tráfego chegará ao gateway mas não terá caminho para o on-premises. Confirmado que a infraestrutura está de pé, verifica-se se a route table está corretamente associada à subnet (P), pois sem essa associação o forced tunneling simplesmente não se aplica. O passo Q (teste de saída da VM) valida na prática o comportamento observado pelo usuário após confirmar que a configuração deveria estar correta. O passo S (confirmação com o time on-premises) é o último porque só faz sentido verificar o que acontece no firewall corporativo depois de confirmar que o tráfego está efetivamente chegando até lá.
A sequência A começa pelo sintoma (Q) antes de qualquer diagnóstico de infraestrutura, o que pode confirmar o problema mas não aponta a causa. A sequência D começa pelo estado do túnel (R) sem antes verificar se o gateway existe, o que é um atalho que pode confundir um estado Disconnected com ausência de gateway.
Árvore de Troubleshooting: Configure Forced Tunneling
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou verificação) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Diante de um problema real, comece pelo nó raiz em azul escuro e responda cada pergunta diagnóstica com base no que você consegue observar no portal, na CLI ou nos logs. Siga o ramo correspondente ao estado observado. Nós em laranja indicam que é necessário coletar mais informação antes de prosseguir. Ao atingir um nó vermelho, a causa está identificada; o nó verde imediatamente abaixo indica a ação corretiva. Não salte perguntas: a árvore foi desenhada para eliminar hipóteses na ordem mais eficiente, do componente mais fundamental ao mais periférico.