Laboratório Técnico: Implement a site-to-site VPN connection
Questões
Questão 1 — Múltipla Escolha
Uma equipe de rede precisa conectar a infraestrutura on-premises a uma VNet no Azure usando uma conexão site-to-site VPN. O dispositivo VPN local suporta apenas IKEv1 e o gateway do Azure foi provisionado com o SKU VpnGw1.
Qual afirmação descreve corretamente o comportamento esperado nesse cenário?
A) A conexão será estabelecida normalmente, pois o SKU VpnGw1 suporta IKEv1 e IKEv2 por padrão.
B) A conexão falhará porque o SKU VpnGw1 suporta apenas IKEv2.
C) A conexão será estabelecida, mas com largura de banda limitada a 100 Mbps por usar IKEv1.
D) A conexão exigirá a criação de um segundo gateway com SKU Basic para compatibilidade com IKEv1.
Questão 2 — Cenário Técnico
Um engenheiro configurou uma conexão site-to-site VPN entre uma VNet do Azure e um data center on-premises. Após o provisionamento, o status da conexão no portal aparece como "Connected", mas as VMs na VNet não conseguem se comunicar com os servidores on-premises.
Considere a configuração abaixo do Local Network Gateway:
Local Network Gateway
Name: lng-datacenter
IP Address: 203.0.113.10
Address Space: 10.10.0.0/16
E a configuração da sub-rede on-premises real:
Servidores on-premises: 192.168.5.0/24
Gateway do dispositivo VPN: 203.0.113.10
Qual é a causa mais provável da falha de comunicação?
A) O IP público do dispositivo VPN on-premises está incorreto no Local Network Gateway.
B) O espaço de endereços configurado no Local Network Gateway não corresponde à sub-rede real dos servidores on-premises.
C) A VNet do Azure não possui uma rota estática apontando para o gateway local.
D) O SKU do Virtual Network Gateway não suporta o volume de tráfego entre as redes.
Questão 3 — Verdadeiro ou Falso
Afirmação: Em uma conexão site-to-site VPN no Azure, é possível usar o mesmo Virtual Network Gateway tanto para conexões site-to-site quanto para conexões ponto-a-site simultaneamente, desde que o gateway não seja do SKU Basic.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Uma empresa possui dois escritórios remotos, cada um com seu próprio dispositivo VPN, e deseja conectá-los à mesma VNet do Azure. O engenheiro responsável criou dois Local Network Gateways distintos e está tentando criar a segunda conexão site-to-site a partir do mesmo Virtual Network Gateway.
Após criar a primeira conexão com sucesso, ao tentar criar a segunda, o engenheiro observa que a operação falha com a seguinte mensagem:
The virtual network gateway does not support multiple connections
with the same local network gateway IP address.
Os dois escritórios possuem IPs públicos distintos. Qual é a causa mais provável do erro?
A) O SKU do Virtual Network Gateway não suporta múltiplas conexões site-to-site.
B) O tipo de VPN do gateway está configurado como Policy-Based, que permite apenas uma única conexão.
C) Os dois Local Network Gateways estão configurados com o mesmo espaço de endereços, gerando conflito de roteamento.
D) A segunda conexão requer um segundo Virtual Network Gateway em uma sub-rede dedicada diferente.
Questão 5 — Múltipla Escolha
Ao provisionar um Virtual Network Gateway para uma conexão site-to-site VPN, o engenheiro precisa criar uma sub-rede específica na VNet. Qual das opções abaixo descreve corretamente os requisitos obrigatórios dessa sub-rede?
A) A sub-rede deve ser nomeada GatewaySubnet e pode ter qualquer tamanho de prefixo, incluindo /29.
B) A sub-rede deve ser nomeada GatewaySubnet e recomenda-se o uso de /27 ou maior para suportar configurações com alta disponibilidade e coexistência com outros gateways.
C) A sub-rede pode ter qualquer nome, mas deve ser dedicada exclusivamente ao gateway e usar o prefixo /28.
D) A sub-rede deve ser nomeada AzureGatewaySubnet e ter tamanho mínimo de /27.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: A
O SKU VpnGw1 e todos os SKUs da família VpnGw suportam tanto IKEv1 quanto IKEv2. A restrição de suporte apenas a IKEv2 existe somente nos SKUs Basic da geração mais antiga, e mesmo assim em cenários específicos. Portanto, um dispositivo on-premises que suporta apenas IKEv1 consegue estabelecer a conexão com um gateway VpnGw1 normalmente.
O principal equívoco representado pelos distratores é confundir a limitação do SKU Basic com os SKUs de produção da família VpnGw. A alternativa C introduz uma limitação de throughput inexistente associada ao protocolo IKEv1, o que não tem base técnica. A alternativa D inverte a lógica: o SKU Basic é o mais limitado, não o mais compatível.
Gabarito — Questão 2
Resposta: B
O status "Connected" indica que o túnel VPN (fase IKE) foi estabelecido com sucesso entre os dois endpoints. No entanto, a comunicação de dados depende do roteamento correto dentro do túnel. O Local Network Gateway define quais prefixos de rede on-premises o Azure considera acessíveis por aquela conexão.
No cenário apresentado, o Address Space do Local Network Gateway está configurado como 10.10.0.0/16, mas os servidores reais estão em 192.168.5.0/24. O Azure não enviará tráfego destinado a 192.168.5.0/24 pelo túnel porque esse prefixo não está declarado no Local Network Gateway. O resultado é um túnel ativo, mas sem roteamento efetivo para os hosts corretos.
A alternativa A está errada porque o IP do dispositivo VPN está correto. A alternativa C está errada porque o Azure injeta rotas automaticamente via gateway, sem necessidade de rotas estáticas manuais na VNet. A alternativa D está errada porque o problema é de configuração, não de capacidade.
Gabarito — Questão 3
Resposta: Verdadeiro
Um Virtual Network Gateway no Azure suporta conexões site-to-site e ponto-a-site simultaneamente. Essa coexistência é uma funcionalidade nativa e documentada, permitindo que escritórios remotos (site-to-site) e usuários individuais (ponto-a-site) se conectem à mesma VNet pelo mesmo gateway.
A restrição real está no SKU Basic: ele não suporta conexões ponto-a-site baseadas em certificado RADIUS ou Microsoft Entra ID, e tem limitações gerais que o tornam inadequado para ambientes de produção. SKUs como VpnGw1 em diante suportam plenamente a coexistência dos dois tipos de conexão. Confundir "não suportado no Basic" com "não suportado em geral" é o equívoco mais comum nesse tema.
Gabarito — Questão 4
Resposta: B
Quando o tipo de VPN do Virtual Network Gateway é Policy-Based, o gateway suporta apenas uma única conexão site-to-site. VPNs baseadas em política usam listas de acesso estáticas para definir o tráfego que entra no túnel, o que arquiteturalmente impede múltiplas conexões simultâneas.
Para conectar múltiplos sites ao mesmo gateway, o tipo de VPN deve ser Route-Based. Gateways Route-Based usam roteamento dinâmico ou estático para direcionar tráfego pelos túneis, suportando múltiplas conexões simultâneas sem conflito.
A alternativa A está errada porque o problema não é o SKU, mas o tipo de VPN. A alternativa C está errada porque a mensagem de erro não menciona conflito de espaço de endereços, e os IPs dos gateways são distintos. A alternativa D está errada porque múltiplas conexões site-to-site a partir do mesmo gateway são plenamente suportadas em modo Route-Based.
Gabarito — Questão 5
Resposta: B
O nome GatewaySubnet é obrigatório e exato: o Azure identifica essa sub-rede pelo nome para associar ao Virtual Network Gateway. Nenhum outro nome é aceito.
Quanto ao tamanho, o prefixo /29 é tecnicamente aceito pelo portal, mas é inadequado para ambientes que exigem alta disponibilidade (active-active) ou coexistência com outros gateways como o ExpressRoute Gateway, pois esses cenários demandam mais endereços IP dentro da sub-rede. A Microsoft recomenda explicitamente /27 ou maior para evitar restrições futuras.
A alternativa A está parcialmente correta no nome, mas o /29 é desencorajado e pode inviabilizar configurações avançadas. A alternativa C está errada no nome: qualquer nome diferente de GatewaySubnet fará o provisionamento falhar. A alternativa D está errada no nome: AzureGatewaySubnet não é aceito pelo Azure.