Microsoft AZ-700: Rede Híbrida — Guia de estudos
Faz parte do Microsoft Azure Network Engineer AZ-700 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.
Fundamentos de conectividade híbrida e restrições de endereçamento
Conectividade híbrida trata-se de alcançabilidade IP confiável, roteável e segura entre redes virtuais on-premises e do Azure. Ao planejar o endereçamento da rede virtual, lembre-se de que alguns recursos gerenciados pelo Azure dentro de uma sub-rede exigem alocação de endereços contíguos e não conflitantes e, às vezes, endereços reservados específicos: os load balancers do Azure e as sub-redes de gateway devem ser criados propositalmente (a GatewaySubnet deve ter o nome exato e ser dimensionada para acomodar a escala do SKU do gateway), e os endpoints privados e os endpoints de serviço gerenciados pelo Azure exigem endereços retirados da VNet que os hospeda. A sobreposição de prefixos on-premises e do Azure é a armadilha mais comum: intervalos sobrepostos quebram o roteamento e a seleção de rotas BGP, criam roteamento assimétrico e complicam as políticas de firewall. Use segmentos de pelo menos /27–/24 para sub-redes que hospedam firewalls stateful, load balancers ou muitos endpoints privados; reserve uma GatewaySubnet dedicada (/27 ou maior, dependendo do SKU). O DNS é igualmente crítico: endpoints privados usam zonas de DNS privado da plataforma (por exemplo, privatelink.database.windows.net), então encaminhadores condicionais ou o Azure DNS Private Resolver são necessários on-premises para resolver nomes privados do Azure. Os trade-offs de design se concentram na utilização de IP versus resiliência: esquemas IPv4 mais densos economizam espaço de endereço, mas aumentam o risco de colisão e migração, enquanto prefixos maiores e menos eficientes simplificam a expansão futura e as estratégias de anúncio BGP.
SKUs do VPN Gateway, fundamentos do BGP e Local Network Gateways
A escolha do SKU correto do gateway de VPN (VpnGw1–VpnGw5, Basic onde for legado) afeta diretamente a taxa de transferência, as sessões S2S/P2S simultâneas e os recursos disponíveis, como limites de rota ou o modo ativo-ativo. Use gateways baseados em rota para designs híbridos modernos; o modo baseado em política é legado e limita o BGP. O BGP fornece troca dinâmica de prefixos e suporta resiliência de caminho, failover automático e priorização de prefixos — configure o ASN do Azure VPN Gateway (padrão 65515) e corresponda ou faça o peering com o ASN on-premises no objeto Local Network Gateway. O Local Network Gateway armazena o IP público on-premises, o(s) espaço(s) de endereço e, opcionalmente, o IP do peer BGP e o ASN; esquecer de preencher o IP do peer BGP ou usar ASNs incompatíveis impede a propagação de rotas e leva a soluções de contorno com rotas estáticas. Considere os hubs do Azure Virtual WAN para escala multi-site e roteamento de trânsito integrado; os hubs VWAN suportam S2S e P2S em alta escala e se integram com o Azure Firewall e o ExpressRoute. Fique atento à propagação da tabela de rotas: por padrão, algumas topologias hub-spoke ou de virtual appliance suprimem a propagação automática; UDRs explícitos ou anúncios de rota BGP podem ser necessários. Trade-offs: SKUs mais altos e o VWAN aumentam o custo, mas reduzem a sobrecarga de gerenciamento e melhoram a taxa de transferência e a escala de roteamento.
Opções de design Point-to-Site, suporte a clientes e integração com DNS
As escolhas de Point-to-Site (P2S) determinam a compatibilidade do cliente, a autenticação e a escala. O OpenVPN (SSL) é o mais multiplataforma e recomendado para clientes macOS, Linux e móveis; o IKEv2 é leve e funciona bem com clientes nativos do macOS; o SSTP permanece como uma opção para cenários mais antigos apenas com Windows. Os modos de autenticação incluem o Azure Active Directory (recomendado para integração de identidade e acesso condicional), autenticação baseada em certificado e RADIUS para soluções on-premises de MFA ou baseadas em RADIUS. O SKU do Gateway de VPN dita a contagem de túneis P2S e a taxa de transferência; escolha VpnGw2/3 para pools de usuários de médio a grande porte e VpnGw4/5 para uso em larga escala ou sensível à taxa de transferência. Endpoints privados e P2S interagem via DNS: para permitir que clientes P2S resolvam nomes de endpoints privados (zonas privatelink), vincule as zonas de DNS privado à VNet ou use o Azure DNS Private Resolver e encaminhadores condicionais a partir do DNS on-premises ou do cliente. Uma armadilha frequente é esquecer que os clientes P2S normalmente usam o DNS do Azure fornecido pelo gateway apenas quando o cliente envia as configurações de rota e DNS; configurações explícitas de sufixo DNS e encaminhadores evitam problemas de “não é possível resolver o endpoint privado”. Equilibre escalabilidade e custo: a autenticação por certificado tem baixo custo, mas é mais difícil de revogar; o Azure AD oferece controles de segurança modernos, mas adiciona licenciamento/complexidade.
Roteamento de trânsito, tunelamento forçado, inspeção e posicionamento de appliances de segurança
Projetar o trânsito entre múltiplas VNets, ambientes on-premise e appliances de inspeção exige uma aplicação clara dos limites de roteamento e NAT. Forçar o tráfego através do Azure Firewall ou de appliances virtuais requer rotas definidas pelo usuário (UDRs) apontadas para o IP privado do firewall ou o uso do roteamento do hub do Virtual WAN para centralizar a inspeção. Se você precisar de proxy transparente completo ou inspeção de TLS, posicione o appliance em uma sub-rede de inspeção dedicada e garanta que os SKUs do gateway subnet e do firewall suportem o trânsito para a taxa de transferência esperada. Preste atenção ao comportamento do SNAT e às escolhas de SKU de IP público: IPs Públicos Standard e o NAT Gateway são recomendados para um SNAT de saída previsível e regras de segurança; o NAT Gateway combinado com um conjunto de IPs públicos Standard descarrega o SNAT e evita a proliferação de IPs públicos por VM. Uma armadilha comum é o roteamento assimétrico, quando rotas on-premise e UDRs do Azure fazem com que o tráfego de retorno ignore o appliance desejado; garanta que todos os spokes anunciem os prefixos necessários via BGP ou tenham UDRs que direcionem o tráfego para o ponto de inspeção. Desempenho vs. custo: uma topologia hub-spoke com Azure Firewall Premium ou appliances de terceiros de alta taxa de transferência aumenta a proteção e o gerenciamento central, mas eleva o custo e o risco de falha de um único hub, a menos que você implante hubs redundantes ativo-ativo e emparelhe gateways entre regiões.
Problema Prático: Cenário de Caso de Uso
Cenário: A Contoso Ltd tem dois datacenters on-premise (Seattle e Amsterdã) e um ambiente Azure existente com três VNets (VNet-Prod, VNet-Shared, VNet-Dev) em uma única VNet hub (VNet-Hub). Atualmente, eles usam um VPN Gateway VpnGw1 para Seattle e uma conexão site-to-site para um hub do Azure Virtual WAN para Amsterdã. Endpoints privados são usados para o Azure SQL na VNet-Shared.
Desafio: A Contoso precisa de conectividade híbrida resiliente e escalável com roteamento dinâmico (BGP) entre ambos os datacenters e o Azure, suporte P2S confiável para usuários de macOS, resolução de DNS de endpoints privados a partir do ambiente on-premise e inspeção centralizada do tráfego de saída dos spokes através do Azure Firewall.
Abordagem Recomendada:
- Implantar um novo VPN Gateway VpnGw3 baseado em rota na VNet-Hub, configurado como ativo-ativo com BGP habilitado (defina o ASN do gateway explicitamente) e atualizar os objetos do Local Network Gateway com os IPs e ASNs dos pares BGP on-premise; migrar a conexão S2S de Seattle para o novo gateway para suportar maior taxa de transferência e limites de rota.
- Consolidar a conexão de Amsterdã no hub estabelecendo um ExpressRoute ou migrando o hub do VWAN para um emparelhamento de hub com a VNet-Hub; garantir a troca de rotas BGP entre ambos os datacenters para evitar rotas estáticas e habilitar o failover automático.
- Configurar P2S usando o protocolo OpenVPN com autenticação do Azure AD no VpnGw3 para dar suporte a clientes macOS (IKEv2 como fallback) e dimensionar os pools de clientes de acordo com os limites do VpnGw3; publicar um encaminhador condicional no DNS on-premise para encaminhar as zonas privatelink.* para um Azure DNS Private Resolver implantado na VNet-Shared e vinculado às zonas de DNS privado para os endpoints privados.
- Implantar o Azure Firewall (Standard ou Premium, se for necessária inspeção de TLS) na VNet-Hub em configuração ativo-ativo e criar UDRs para as sub-redes spoke que direcionam 0.0.0.0/0 para o IP privado do Firewall; anexar um NAT Gateway com IPs públicos Standard ao firewall ou usar o IP público do Firewall para SNAT explícito e registro de logs em um Log Analytics central.
Justificativa: Usar o VpnGw3 com BGP fornece propagação dinâmica de rotas e taxa de transferência para resiliência multi-site; OpenVPN+Azure AD oferece suporte seguro a usuários de macOS; o encaminhamento de DNS para o Azure DNS Private Resolver garante a resolução de nomes de endpoints privados a partir do ambiente on-premise; centralizar a inspeção em um hub com Azure Firewall e UDRs evita o roteamento assimétrico e simplifica o gerenciamento de políticas, trocando um custo maior por segurança e observabilidade centralizadas.
← Projeto de Azure Virtual Network · Todos os domínios · Azure DNS e Resolução de Nomes →
Pratique estas questões → · Prática cronometrada no ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Passe no seu exame →