Guia para Links Privados e DNS na WAN Virtual do Azure

Link Privado do Azure

DNS do Azure

Firewall do Azure

WAN Virtual do Azure

Link Privado do Azure permite que os clientes acessem serviços de PaaS Azure diretamente de redes virtuais privadas sem usar o endereçamento IP público. Para cada serviço, você configura um ponto de extremidade privado que usa um endereço IP privado de sua rede. Em seguida, os clientes podem usar o ponto de extremidade privado para se conectarem privadamente ao serviço.

Os clientes usam o FQDN (nome de domínio totalmente qualificado) de um serviço para se conectar ao serviço. Configure o DNS em sua rede para resolver o FQDN do serviço para o endereço IP privado do endpoint privado.

Seu design de rede e, em particular, sua configuração de DNS, são fatores-chave para dar suporte à conectividade de ponto de extremidade privado aos serviços. Este artigo é parte de uma série de artigos que fornecem orientação sobre como entender o comportamento do Link Privado em ambientes de WAN Virtual. Vários cenários são apresentados, incluindo exemplos intencionalmente restritos usados para ilustrar desafios comuns de DNS e roteamento. Mesmo que nenhum dos cenários corresponda exatamente à sua situação, você deverá ser capaz de adaptar os designs para atender às suas necessidades.

Topologia de rede inicial

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

Figura 1: Topologia de rede inicial para todos os cenários de ponto de extremidade privado e DNS

Baixe um arquivo Visio dessa arquitetura. Essa topologia tem as seguintes características:

É uma rede hub-spoke que é implementada com a WAN Virtual do Azure.
Há duas regiões, cada uma com um hub virtual seguro que inclui Firewall do Azure.
Cada hub virtual regional protegido tem as seguintes configurações de segurança para conexões de Rede Virtual do Azure:
- Internet traffic: Secured by Firewall do Azure - Todo o tráfego para a Internet flui pelo firewall do hub regional.
- Tráfego privado: Protegido pelo Firewall do Azure - Todo o tráfego entre as conexões spokes flui através do firewall do hub regional.
Cada hub virtual regional é protegido com o Firewall do Azure. Os firewalls do 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 FQDN em coleções de regras.
- Proxy DNS: habilitado – o firewall do hub regional responde às consultas DNS na porta 53. Ele encaminha consultas para o DNS do Azure para valores não armazenados em cache.
- O firewall registra as avaliações de regras e as solicitações de proxy DNS em um workspace do Log Analytics que está na mesma região. Esse registro em log é um requisito de segurança de rede padrão.
Cada spoke usa o IP privado do firewall regional como servidor DNS. Caso contrário , a avaliação da regra FQDN pode estar fora de sincronia.

Roteamento Multirregional

Intenção de roteamento e políticas de roteamento do hub no WAN Virtual permitem controlar como o tráfego flui entre hubs e se esse tráfego é inspecionado pelo Firewall do Azure ou por outra solução de segurança.

Por padrão, em uma implantação de WAN Virtual de vários hubs, o tráfego privado inter-hub não passa por Firewall do Azure. Em vez disso, o Azure usa a conectividade interna gerenciada pela WAN Virtual de hub para hub, que funciona em paralelo às vias de tráfego seguras dentro de cada hub. Isso significa que o tráfego privado que se move entre hubs não é inspecionado automaticamente.

Se precisar do Firewall do Azure para inspecionar o tráfego privado entre hubs, você poderá habilitar esse comportamento configurando uma política de roteamento de tráfego privado e ativando a inspeção entre hubs. Isso força o tráfego privado entre os hubs a ser encaminhado por meio de Firewall do Azure para inspeção.

Essa configuração é mais avançada e está fora do escopo desta série.

Adicionando redes spoke

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

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 WAN Virtual forneça uma experiência de hub gerenciado, a compensação é uma capacidade limitada de influenciar a configuração do hub virtual ou adicionar componentes a ela. Uma topologia de hub-spoke tradicional permite que você isole cargas de trabalho nos spokes enquanto compartilha serviços de rede comuns, como registros DNS, no hub auto-gerenciado. Normalmente, você vincula a zona DNS privada à rede do hub para que o DNS do Azure possa resolver endereços IP de ponto de extremidade privado para clientes.

No entanto, não é possível vincular zonas DNS privadas a hubs WAN Virtual, portanto, qualquer resolução DNS dentro do hub não está ciente das zonas privadas. Isso cria especificamente um problema para o Firewall do Azure, que serve como o provedor DNS para spokes de workload e usa DNS para resolução FQDN.

Quando você usa os hubs de WAN virtual, pode parecer intuitivo vincular zonas DNS privadas às redes virtuais do tipo spoke em que as cargas de trabalho esperam resolução de DNS. No entanto, conforme observado na arquitetura, o proxy DNS está habilitado nos firewalls regionais e todos os nós de rede devem usar o firewall regional como fonte DNS. A consulta DNS do Azure se origina do firewall no hub, não da rede virtual de carga de trabalho, portanto, os links de zona DNS privados na rede spoke não são usados na resolução.

Como os hubs WAN Virtual não podem se vincular a zonas de DNS privado, a abordagem recomendada para resolução de DNS em cenários de Link Privado é o DNS do Azure Private Resolver implantado em uma rede virtual que estende o hub. Isso permite uma resolução DNS privada escalonável e com reconhecimento de zona para cargas de trabalho conectadas a hubs de WAN Virtual. Os artigos de acompanhamento nesta série demonstram como o Resolvedor Privado de DNS completa a arquitetura.

Observação

Para configurar o firewall regional para ser o provedor DNS do spoke, configure o servidor DNS personalizado na rede virtual do spoke para apontar para o IP privado do firewall, em vez do valor padrão do DNS do Azure.

Dada a complexidade de habilitar o proxy DNS nos firewalls regionais, vamos examinar os motivos para habilitá-lo.

Firewall do Azure regras de rede dão suporte a limites baseados em FQDN para controlar com mais precisão o tráfego de saída que as regras de aplicativo não lidam. O proxy DNS deve ser habilitado para esse recurso. Um uso comum é limitar o tráfego NTP (Protocolo de Tempo de Rede) a pontos de extremidade conhecidos, como time.windows.com.
O registro em log de solicitações DNS beneficia as equipes de segurança. O Firewall do Azure tem suporte interno para registro em log de solicitações DNS, portanto, exigir que todos os recursos spoke usem o Firewall do Azure como provedor DNS garante uma ampla cobertura de registro em log.

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 sua falha é instrutiva.

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 requer um serviço PaaS por meio de um ponto de extremidade privado. Uma zona DNS privada vinculada à rede virtual possui um registro A que associa o FQDN do serviço ao endereço IP privado do ponto de extremidade privado. O diagrama a seguir ilustra o fluxo.

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

Baixe um arquivo do Visio dessa arquitetura.

O cliente emite uma solicitação para stgworkload00.blob.core.windows.net.
O DNS do Azure, servidor DNS configurado para a rede virtual, é consultado sobre o endereço IP de stgworkload00.blob.core.windows.net.

Executar o comando a seguir da VM (máquina virtual) ilustra que a VM está configurada para usar o DNS do Azure (168.63.129.16) como o provedor DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
A zona DNS privada privatelink.blob.core.windows.net está vinculada à VNet de Carga de Trabalho, portanto, o DNS do Azure incorpora registros da VNet de Carga de Trabalho em sua resposta.
Como existe um registro A na zona DNS privada que mapeia o FQDN, stgworkload00.privatelink.blob.core.windows.netpara o IP privado do ponto de extremidade privado, o endereço IP privado 10.1.2.4 é retornado.

Executar o comando a seguir da 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)
```
A solicitação é emitida para o endereço IP privado do ponto de extremidade privado, que é 10.1.2.4.
A solicitação é roteada por meio do Link Privado para a conta de armazenamento.

Esse design funciona porque 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 de não funcionamento

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 de WAN Virtual. Portanto, quando os clientes são configurados para usar o firewall como 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 além de fornecer o padrão, que é o endereço IP público.

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

Baixe um arquivo do Visio dessa arquitetura.

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 DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
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.
O DNS do Azure não pode resolver stgworkload00.blob.core.windows.net para o endereço IP privado do ponto de extremidade privado porque:
1. Uma zona DNS privada não pode ser vinculada a um hub de WAN Virtual.
2. O DNS do Azure não está ciente de uma zona DNS privada vinculada à rede virtual de carga de trabalho, pois o servidor DNS configurado para a rede virtual da carga de trabalho é o Firewall do Azure.
O DNS do Azure responde com o endereço IP público da conta de armazenamento.

Executando o comando a seguir na VM, traduz o FQDN da conta de armazenamento para o IP público da mesma.
```
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á fazendo proxy de consultas DNS, podemos registrar essas consultas. Veja a seguir os logs de proxy DNS do Firewall do Azure de exemplo.
```
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    
```
O cliente não recebe o endereço IP privado do ponto de extremidade do Link Privado e não pode estabelecer uma conexão privada com a conta de armazenamento.

Esse comportamento é esperado. É o problema que os cenários resolvem.

Cenários

As soluções para esse problema são semelhantes, mas examinar cenários comuns de carga de trabalho mostra como cada solução atende a requisitos diferentes. A maioria dos cenários consiste em um cliente que acessa um ou mais serviços de PaaS em um ponto de extremidade privado. Eles aderem à topologia de rede inicial, mas diferem em seus requisitos de carga de trabalho. Os cenários começam com um cliente que acessa um único serviço de PaaS regional. Eles se tornam incrementalmente mais complexos e adicionam mais visibilidade de rede, regiões e serviços de 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 uma representação 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 opere de forma semelhante.

Importante

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

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

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

Próximas etapas

Ler o cenário de recurso de PaaS dedicado de região única

Comentários

Esta página foi útil?