Guia para Link Privado e DNS na WAN Virtual do Azure

Azure Private Link
Azure DNS
Azure Firewall
WAN Virtual do Azure

O Azure Private Link permite que os clientes acedam diretamente aos serviços Azure PaaS a partir de redes virtuais privadas sem usar endereçamento IP público. Para cada serviço, você configura um ponto de extremidade privado que usa um endereço IP privado da sua rede. Os clientes podem usar o ponto de extremidade privado para se conectar de forma privada ao serviço.

Os clientes utilizam o nome de domínio totalmente qualificado (FQDN) de um serviço para se ligarem ao serviço. Configuras o teu DNS na rede para traduzir o FQDN do serviço para o endereço IP privado do ponto de extremidade privado.

Seu design de rede e, em particular, sua configuração de DNS, são fatores-chave no suporte à conectividade de ponto final privado para serviços. Este artigo faz parte de uma série de artigos que fornecem orientações para compreender o comportamento do Private Link em ambientes WAN Virtual. São apresentados vários cenários, incluindo exemplos intencionalmente restritos usados para ilustrar desafios comuns de DNS e encaminhamento. Mesmo que nenhum dos cenários corresponda exatamente à sua situação, você deve ser capaz de adaptar os projetos para atender às suas necessidades.

Iniciando a topologia de rede

A topologia de rede inicial é a arquitetura base para todos os cenários desta série. É uma rede hub típica que usa WAN Virtual do Azure.

Diagrama que mostra a arquitetura WAN virtual inicial usada para esta série de artigos.

Figura 1: Iniciando a topologia de rede para todos os cenários de ponto final privado e DNS

Baixe um arquivo Visio desta arquitetura. Esta topologia tem as seguintes características:

  • É uma rede hub-spoke que é implementada com a WAN Virtual do Azure.
  • Existem duas regiões, cada uma com um hub virtual seguro que inclui o Azure Firewall.
  • Cada hub virtual regional seguro tem as seguintes configurações de segurança para conexões de Rede Virtual do Azure:
    • Tráfego de Internet: Protegido por Azure Firewall - Todo o tráfego para a internet passa através do firewall regional do hub.
    • Tráfego privado: Assegurado por Azure Firewall - Todo o tráfego interspoke passa pelo firewall regional do hub.
  • Cada hub virtual regional é protegido com o Firewall do Azure. Os firewalls de hub regional têm as seguintes configurações:
    • Servidores DNS: Padrão (fornecido pelo Azure) - O firewall do hub regional usa explicitamente o DNS do Azure para resolução de FQDN em coleções de regras.
    • Proxy DNS: Ativado - O firewall do hub regional responde a consultas DNS na porta 53. Ele encaminha consultas para o DNS do Azure para valores não armazenados em cache.
    • O firewall registra avaliações de regras e solicitações de proxy DNS em um espaço de trabalho do Log Analytics que está na mesma região. Este registo é um requisito padrão de segurança de rede.
  • Cada spoke utiliza o IP privado do seu firewall regional como servidor DNS. Caso contrário , a avaliação da regra FQDN pode estar fora de sincronia.

Roteamento multi-região

"Routing intent" do hub do WAN Virtual e as políticas de encaminhamento permitem-lhe controlar como o tráfego flui entre os hubs e se esse tráfego é inspecionado pelo Azure Firewall ou por outra solução de segurança.

Por padrão, numa implementação de WAN Virtual multi-hub, o tráfego privado entre hubs não passa através do Azure Firewall. Em vez disso, o Azure utiliza a sua conectividade WAN Virtual gerida de hub a hub, que corre em paralelo aos caminhos de tráfego seguros dentro de cada hub. Isto significa que o tráfego privado em movimento entre hubs não é automaticamente inspecionado.

Se precisar Azure Firewall para inspecionar tráfego privado entre hubs, pode ativar este comportamento configurando uma política de encaminhamento Private Traffic e ativando inspeção inter-hub. Isto obriga o tráfego privado entre hubs a ser encaminhado através do Azure Firewall para inspeção.

Esta configuração é mais avançada e está fora do âmbito desta série.

Adicionando redes spoke

Ao adicionar redes spoke, aplique as restrições definidas na topologia de rede inicial. Cada spoke associa-se à tabela de rotas padrão do seu hub regional, e o Azure Firewall protege tanto o tráfego da internet como o privado. A captura de tela a seguir mostra um exemplo de configuração:

Captura de ecrã da configuração de segurança para as ligações de rede virtual que mostram o tráfego privado e da Internet que a Firewall do Azure protege. Figura 2: Configuração de segurança para conexões de rede virtual no hub virtual

Principais desafios

A topologia de rede inicial cria desafios para configurar o DNS para pontos de extremidade privados.

Embora a WAN Virtual ofereça uma experiência de hub gerido, a desvantagem é a capacidade limitada de influenciar a configuração do hub virtual ou adicionar componentes a ela. Uma topologia hub-spoke tradicional permite isolar cargas de trabalho nos spokes enquanto partilha serviços de rede comuns, como registos DNS, no hub autogerido. Normalmente, você vincula a zona DNS privada à rede de hub para que o DNS do Azure possa resolver endereços IP de ponto de extremidade privados para clientes.

No entanto, não é possível ligar zonas DNS privadas a hubs WAN Virtual, por isso qualquer resolução DNS dentro do hub não tem conhecimento das zonas privadas. Especificamente, isto cria um problema para o Azure Firewall, que atua como fornecedor de DNS para os spokes de carga de trabalho e utiliza DNS para a resolução de FQDN.

Quando utiliza hubs do WAN Virtual, pode parecer lógico associar zonas DNS privadas às redes virtuais spoke onde as cargas de trabalho dependem da resolução de DNS. No entanto, como referido na arquitetura, o proxy DNS está ativado nos firewalls regionais e todos os spokes devem usar o seu firewall regional como fonte DNS. A consulta DNS do Azure origina-se do firewall no hub, não da rede virtual da carga de trabalho, por isso as ligações DNS privadas na rede spoke não são usadas na resolução.

Como os hubs WAN Virtual não conseguem ligar-se a zonas DNS Privado, a abordagem recomendada para resolução DNS em cenários Private Link é o DNS do Azure Private Resolver implementado numa rede virtual com extensão de hub. Isto permite uma resolução DNS privada escalável e consciente da zona para cargas de trabalho ligadas a hubs WAN Virtual. Artigos de seguimento desta série demonstram como o DNS Private Resolver completa a arquitetura.

Observação

Para configurar o firewall regional como fornecedor DNS do spoke, defina o servidor DNS personalizado na rede virtual spoke para apontar para o IP privado do firewall em vez do valor normal do DNS do Azure.

Dada a complexidade de ativar o proxy DNS nos firewalls regionais, vamos rever as razões para o ativar.

  • As regras de rede do Azure Firewall suportam limites baseados em FQDN para controlar com mais precisão o tráfego de saída que as regras de aplicação não lidam. O proxy DNS deve estar ativado para esta funcionalidade. Um uso comum é limitar o tráfego NTP (Network Time Protocol) a pontos de extremidade conhecidos, como time.windows.com.
  • O registo de pedidos DNS beneficia as equipas de segurança. O Firewall do Azure tem suporte interno para registro de pedidos DNS, portanto, exigir que todos os recursos ligados usem o Firewall do Azure como seu provedor de DNS garante uma cobertura abrangente de registos.

Para ilustrar os desafios, as seções a seguir descrevem duas configurações. Há um exemplo simples que funciona, e um mais complexo que não funciona, mas o seu fracasso é instrutivo.

Cenário de trabalho

O exemplo a seguir é uma configuração básica de ponto de extremidade privado. Uma rede virtual contém um cliente que necessita de um serviço PaaS através de um endpoint privado. Uma zona DNS privada associada à rede virtual tem um registo tipo A que resolve o FQDN do serviço para o endereço IP privado do endpoint privado. O diagrama a seguir ilustra o fluxo.

Diagrama que mostra um ponto de extremidade privado básico e a configuração de DNS.

Figura 3: Uma configuração básica de DNS para pontos de extremidade privados

Baixe um arquivo Visio desta arquitetura.

  1. O cliente emite uma solicitação para stgworkload00.blob.core.windows.net.

  2. O DNS do Azure, o servidor DNS configurado para a rede virtual, é consultado para o endereço IP do stgworkload00.blob.core.windows.net.

    A execução do comando a seguir da máquina virtual (VM) ilustra que a VM está configurada para usar o DNS do Azure (168.63.129.16) como o provedor de DNS.

    resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16

  3. A zona privatelink.blob.core.windows.net DNS privada está vinculada à VNet de Carga de Trabalho, portanto, o DNS do Azure incorpora registos da VNet de Carga de Trabalho em sua resposta.

  4. Como existe um registro A na zona DNS privada que mapeia o FQDN, stgworkload00.privatelink.blob.core.windows.net, para o IP privado do ponto de extremidade privado, o endereço IP privado 10.1.2.4 é retornado.

    Executar o seguinte comando na VM resolve o FQDN da conta de armazenamento para o endereço IP privado do ponto de extremidade privado.

    resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)

  5. O pedido é emitido para o endereço IP privado do endpoint privado, que é 10.1.2.4.

  6. A solicitação é roteada através do Private Link para a conta de armazenamento.

Este design funciona porque o serviço DNS do Azure:

  • É o servidor DNS configurado para a rede virtual.
  • Está ciente da zona DNS privada vinculada.
  • Resolve consultas DNS usando os valores da zona.

Cenário não operacional

O exemplo a seguir é uma tentativa ingênua de usar pontos de extremidade privados na topologia de rede inicial. Não é possível vincular uma zona DNS privada a um hub WAN virtual. Portanto, quando os clientes são configurados para usar o firewall como seu servidor DNS, as solicitações DNS são encaminhadas para o DNS do Azure de dentro do hub virtual, que não tem uma zona DNS privada vinculada. O DNS do Azure não sabe como resolver a consulta a não ser fornecendo o padrão, que é o endereço IP público.

O diagrama que mostra a configuração de DNS em uma zona DNS privada não funciona porque o Firewall do Azure tem o Proxy DNS habilitado.

Figura 4: Uma tentativa ingênua de usar pontos de extremidade privados na topologia de rede inicial

Baixe um arquivo Visio desta arquitetura.

  1. O cliente emite uma solicitação para stgworkload00.blob.core.windows.net.

    A execução do comando a seguir da VM ilustra que a VM está configurada para usar o firewall do hub virtual como o provedor de DNS.

    resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132

  2. O firewall tem o Proxy DNS habilitado com a configuração padrão para encaminhar solicitações para o DNS do Azure. A solicitação é encaminhada para o DNS do Azure.

  3. O DNS do Azure não consegue converter stgworkload00.blob.core.windows.net no endereço IP privado do ponto de extremidade privado porque:

    1. Uma zona DNS privada não pode ser vinculada a um hub WAN Virtual.
    2. O DNS do Azure não está ciente de uma zona DNS privada vinculada à rede virtual de carga de trabalho, porque o servidor DNS configurado para a rede virtual de carga de trabalho é o Firewall do Azure.

    O DNS do Azure responde com o endereço IP público da conta de armazenamento.

    A execução do seguinte comando da VM resolve o FQDN da conta de armazenamento para o IP público da conta de armazenamento.

    resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)

    Como o Firewall do Azure está a atuar como proxy para as consultas DNS, podemos registar essas consultas. A seguir estão exemplos de logs de Proxy DNS do Firewall do Azure.

    DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s

  4. O cliente não recebe o endereço IP privado para o ponto de extremidade Private Link e não pode estabelecer uma conexão privada com a conta de armazenamento.

Este comportamento é esperado. É o problema que os cenários abordam.

Cenários

As soluções para este problema são semelhantes, mas ao analisar cenários comuns de carga de trabalho, cada solução responde a requisitos diferentes. A maioria dos cenários consiste em um cliente que acessa um ou mais serviços PaaS em um ponto de extremidade privado. Seguem a topologia inicial da rede, mas diferem nos requisitos de carga de trabalho. Os cenários começam com um cliente que acede a um único serviço PaaS regional. Tornam-se progressivamente mais complexas e acrescentam maior visibilidade da rede, regiões e serviços PaaS.

Na maioria dos cenários, o cliente é implementado como uma VM e o serviço PaaS que o cliente acessa é uma conta de armazenamento. Você deve considerar as VMs como um substituto para qualquer recurso do Azure que tenha uma NIC exposta em uma rede virtual, como Conjuntos de Escala de Máquinas Virtuais, nós do Serviço de Kubernetes do Azure ou qualquer outro serviço que roteie de maneira semelhante.

Importante

A implementação do Private Link para a conta Armazenamento do Azure pode diferir de outros serviços PaaS de forma subtil, mas alinha-se bem com muitos outros serviços. Por exemplo, alguns serviços removem registros FQDN enquanto expostos por meio do Private Link, o que pode resultar em comportamentos diferentes, mas essas diferenças geralmente não são um fator nas soluções para esses cenários.

Cada cenário começa com o estado final desejado e detalha a configuração necessária para passar da topologia inicial da rede ao estado final desejado. A solução utiliza o padrão de extensões hub virtual, que expõe serviços partilhados como uma extensão segura de um hub regional, juntamente com DNS do Azure Private Resolver para resolução DNS de endpoints privados em ambientes WAN Virtual. A tabela a seguir contém links para o padrão de extensão de hub virtual e os cenários.

Guia Descrição
Região única, PaaS dedicado Uma carga de trabalho em uma única região acessa um recurso de PaaS dedicado.

Próximos passos

Leia o cenário de recursos de PaaS dedicado de uma única região