Laboratório Técnico: Create and configure a local network gateway
Questões
Questão 1 — Múltipla Escolha
Ao criar um local network gateway no Azure para representar um dispositivo VPN on-premises, um administrador precisa decidir quais informações são obrigatórias durante a criação do recurso.
Considerando um cenário onde o dispositivo VPN on-premises possui o IP público 203.0.113.45 e gerencia o prefixo de endereço 10.10.0.0/16, qual conjunto de informações é suficiente e necessário para criar o local network gateway?
A) Nome do recurso, endereço IP do gateway Azure, prefixo de endereço on-premises e região do Azure.
B) Nome do recurso, endereço IP público do dispositivo VPN on-premises, prefixo de endereço on-premises e grupo de recursos.
C) Nome do recurso, chave compartilhada (shared key), prefixo de endereço on-premises e endereço IP público do dispositivo VPN.
D) Nome do recurso, endereço IP público do dispositivo VPN on-premises, ASN do BGP e grupo de recursos.
Questão 2 — Cenário Técnico
Uma equipe de rede configurou uma conexão VPN Site-to-Site entre o Azure e um escritório remoto. O local network gateway foi criado com o prefixo 192.168.1.0/24. Posteriormente, o escritório remoto expandiu sua rede e adicionou o segmento 192.168.2.0/24.
Os usuários do novo segmento não conseguem acessar recursos no Azure. A conexão VPN continua ativa e o tráfego do segmento original funciona normalmente.
Local Network Gateway — estado atual:
Address space: 192.168.1.0/24
Novo segmento on-premises: 192.168.2.0/24
Status da conexão VPN: Connected
Qual é a causa mais provável e a ação correta?
A) A conexão VPN precisa ser recriada para incluir o novo prefixo, pois prefixos não podem ser alterados após a criação.
B) O prefixo 192.168.2.0/24 deve ser adicionado ao address space do local network gateway existente, sem necessidade de recriar a conexão.
C) Um segundo local network gateway deve ser criado exclusivamente para o novo prefixo 192.168.2.0/24.
D) O virtual network gateway precisa ser reconfigurado com o novo prefixo, pois ele é responsável por armazenar os endereços on-premises.
Questão 3 — Verdadeiro ou Falso
Afirmação: quando o BGP está habilitado em uma conexão VPN Site-to-Site, os prefixos de endereço configurados no local network gateway são ignorados pelo Azure e substituídos integralmente pelas rotas anunciadas via BGP pelo dispositivo on-premises.
Verdadeiro ou Falso?
Questão 4 — Cenário Técnico
Um arquiteto precisa configurar uma conexão VPN Site-to-Site entre o Azure e um parceiro de negócios. O dispositivo VPN do parceiro não possui um endereço IP público estático: ele utiliza um endereço IP dinâmico com um FQDN (Fully Qualified Domain Name) fixo, como vpn.parceiro.com.br.
O arquiteto considera as seguintes abordagens para o campo de endereço do local network gateway:
Opção 1: Inserir o IP dinâmico atual do parceiro no campo "IP address"
Opção 2: Inserir o FQDN no campo "FQDN" disponível no local network gateway
Opção 3: Criar o local network gateway sem endereço e configurar BGP apenas
Opção 4: Usar um segundo virtual network gateway no lugar do local network gateway
Qual abordagem é tecnicamente válida e suportada pelo Azure?
A) Opção 1, atualizando manualmente o IP no local network gateway sempre que o endereço do parceiro mudar.
B) Opção 2, pois o local network gateway suporta nativamente o uso de FQDN no lugar do endereço IP público.
C) Opção 3, pois quando BGP está ativo o endereço IP do peer é suficiente e o campo de endereço principal é opcional.
D) Opção 4, pois dispositivos sem IP estático não podem ser representados por um local network gateway.
Questão 5 — Múltipla Escolha
Um administrador precisa configurar BGP em uma conexão VPN Site-to-Site. Ele já criou o local network gateway sem habilitar BGP. Agora deseja adicionar as configurações de BGP ao recurso existente.
Quais informações são obrigatórias para habilitar BGP no local network gateway?
A) ASN (Autonomous System Number) do dispositivo on-premises e o endereço IP do BGP peer on-premises.
B) ASN do dispositivo on-premises, endereço IP do BGP peer e a chave compartilhada (shared key) da conexão.
C) ASN do dispositivo on-premises, endereço IP do BGP peer e os prefixos de endereço que serão anunciados.
D) ASN do dispositivo on-premises e os prefixos de endereço on-premises já configurados no local network gateway.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O local network gateway é um recurso do Azure que representa o dispositivo VPN ou o site on-premises. Para criá-lo, são obrigatórios: um nome, o endereço IP público do dispositivo VPN on-premises (ou seu FQDN), o espaço de endereçamento (prefixos) que ele gerencia, e um grupo de recursos para alocação.
O endereço IP do virtual network gateway do Azure não é informado aqui: o local network gateway descreve o lado remoto (on-premises), não o lado Azure. A shared key é configurada na connection, não no local network gateway. O ASN do BGP só é necessário se BGP for habilitado, e é opcional na criação padrão.
Escolher A, C ou D representa a confusão comum entre quais informações pertencem ao local network gateway versus à connection ou ao virtual network gateway.
Gabarito — Questão 2
Resposta: B
O local network gateway armazena os prefixos de endereço que representam a rede on-premises. Esse espaço de endereçamento pode ser editado a qualquer momento sem necessidade de recriar o recurso ou a conexão. Basta adicionar 192.168.2.0/24 ao address space do local network gateway existente.
A conexão VPN em si não precisa ser interrompida ou recriada para essa alteração. O Azure propagará automaticamente o novo prefixo para o roteamento da conexão após a atualização.
A alternativa A está errada porque prefixos no local network gateway são editáveis. A alternativa C é ineficiente e desnecessária: um único local network gateway pode conter múltiplos prefixos. A alternativa D revela um equívoco fundamental: os prefixos on-premises são gerenciados no local network gateway, nunca no virtual network gateway.
Gabarito — Questão 3
Resposta: Falso
Quando o BGP está habilitado em uma conexão VPN Site-to-Site, os prefixos configurados estaticamente no local network gateway e as rotas aprendidas via BGP coexistem. O Azure não ignora os prefixos estáticos: ele os usa em conjunto com as rotas BGP.
Na prática, quando BGP está ativo, a recomendação da Microsoft é inserir apenas o endereço IP do BGP peer no campo de prefixos do local network gateway (geralmente como /32), mas isso é uma convenção de configuração, não uma substituição automática. As rotas BGP anunciadas pelo dispositivo on-premises complementam o roteamento, mas não apagam os prefixos estáticos definidos no recurso.
Entender essa distinção é importante para evitar roteamento duplicado ou conflitante em ambientes híbridos.
Gabarito — Questão 4
Resposta: B
O Azure suporta nativamente o uso de FQDN no campo de endereço do local network gateway como alternativa ao endereço IP público estático. Essa funcionalidade foi adicionada para suportar cenários onde o dispositivo VPN do parceiro ou do site remoto possui endereço IP dinâmico com DNS fixo.
A alternativa A é funcionalmente possível, mas representa um processo manual sujeito a falhas e não é a abordagem recomendada ou suportada de forma nativa para endereços dinâmicos. A alternativa C está incorreta: BGP exige o endereço IP do peer, não elimina a necessidade de identificar o endpoint remoto. A alternativa D está errada porque o local network gateway foi projetado exatamente para representar dispositivos externos, incluindo aqueles sem IP estático.
Gabarito — Questão 5
Resposta: A
Para habilitar BGP em um local network gateway, o Azure exige apenas dois campos adicionais: o ASN (Autonomous System Number) do dispositivo on-premises e o endereço IP do BGP peer on-premises (geralmente o endereço da interface de loopback ou da interface de túnel do roteador remoto).
A shared key pertence à connection, não ao local network gateway, portanto a alternativa B está incorreta. Os prefixos de endereço (alternativas C e D) são configurados no campo address space do local network gateway e são independentes da configuração BGP: quando BGP está ativo, a prática recomendada é definir o endereço do peer como prefixo /32, mas isso não é um campo da configuração BGP em si. Confundir onde cada informação é configurada é o erro mais frequente neste contexto.