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

O Azure Private Link possibilita que os clientes acessem os serviços da plataforma como serviço (PaaS) do 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 da rede. Os clientes podem usar o ponto de extremidade privado para se conectar de forma privada ao serviço.

Os clientes continuam a usar o FQDN (nome de domínio totalmente qualificado) de um serviço para se conectar a ele. Configurar o DNS na rede para resolver 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 de extremidade privado para serviços. Este artigo faz parte de uma série de artigos que fornecem orientações sobre a implementação de vários cenários de Link Privado. 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 é uma arquitetura de rede que serve como ponto de partida para todos os cenários desta série de artigos. A arquitetura é uma rede típica de hub-spoke que usa a WAN Virtual do Azure.

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

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 protegido do Firewall do Azure regional.
Cada hub virtual regional protegido tem as seguintes configurações de segurança para conexões de Rede Virtual do Azure:
- Tráfego da Internet: protegido pelo Firewall do Azure - Todo o tráfego para a Internet flui através do firewall do hub regional.
- Tráfego privado: protegido pelo Firewall do Azure - Todo o tráfego que transita de spoke para spoke flui pelo firewall do hub regional.
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 de hub regional usa explicitamente o DNS do Azure para resolução de FQDN em coleções de regras.
- Proxy DNS: Habilitado - O firewall do hub regional responde a consultas DNS na porta 53. Ele encaminha consultas ao 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. O registro desses eventos é um requisito comum de log de segurança de rede.
Cada spoke de rede virtual conectado tem seu servidor DNS padrão configurado para ser o endereço IP privado do firewall do hub regional. Caso contrário, a avaliação da regra FQDN pode estar fora de sincronia.

Roteamento multirregião

Os hubs de WAN Virtual protegidos têm suporte limitado para conectividade entre hubs quando há vários hubs virtuais protegidos. Essa limitação afeta cenários de vários hubs, intrarregiões e entre regiões. Como tal, a topologia de rede não facilita diretamente a filtragem do tráfego privado entre regiões através do Firewall do Azure. O suporte para esse recurso é fornecido usando a intenção de roteamento do hub de WAN Virtual e as políticas de roteamento. Este recurso está na versão preview no momento.

Para esta série de artigos, a suposição é que o tráfego interno seguro não atravessa vários hubs. O tráfego que deve atravessar vários hubs deve fazê-lo em uma topologia paralela que não filtre o tráfego privado por meio de um hub virtual seguro, mas permita que ele passe em vez disso.

Adicionando redes spoke

Quando você adiciona redes de spoke, elas seguem as restrições definidas na topologia de rede inicial. Especificamente, cada rede spoke está associada à tabela de rotas padrão que está em seu hub regional, e o firewall é configurado para proteger o tráfego privado e da Internet. 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 o uso da WAN Virtual ofereça uma experiência de hub gerenciado, a compensação é que há capacidade limitada de influenciar a configuração do hub virtual ou a capacidade de adicionar mais componentes a ele. Uma topologia hub-spoke tradicional permite isolar cargas de trabalho em spokes enquanto compartilha serviços de rede comuns, como registros DNS, no hub autogerenciado. 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 privado para clientes.

No entanto, não é possível vincular zonas DNS privadas a hubs de WAN Virtual, portanto, qualquer resolução DNS que aconteça dentro do hub não está ciente de zonas privadas. Especificamente, esse é um problema para o Firewall do Azure, o provedor DNS configurado para raios de carga de trabalho, que está usando o DNS para resolução de FQDN.

Quando você usa hubs de WAN Virtual, parece intuitivo vincular zonas DNS privadas às redes virtuais faladas onde as cargas de trabalho esperam resolução DNS. No entanto, como observado na arquitetura, o proxy DNS está habilitado nos firewalls regionais e espera-se que todos os raios usem seu firewall regional como sua fonte DNS. O DNS do Azure é chamado a partir do firewall em vez de da rede da carga de trabalho, portanto, nenhum link de zona DNS privada na rede de carga de trabalho não é usado na resolução.

Observação

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

Dada a complexidade resultante da habilitação do proxy DNS nos firewalls regionais, vamos analisar os motivos para habilitá-lo.

As regras de rede do Firewall do Azure 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 manipulam. Esse recurso requer que o proxy DNS esteja habilitado. Um uso comum é limitar o tráfego NTP (Network Time Protocol) a pontos de extremidade conhecidos, como time.windows.com.
As equipes de segurança podem se beneficiar do registro de solicitações de DNS. O Firewall do Azure tem suporte interno para log de solicitação DNS, portanto, exigir que todos os recursos spoke usem o Firewall do Azure como seu provedor de DNS garante uma ampla cobertura de log.

Para ilustrar os desafios, as seções a seguir descrevem duas configurações. Há um exemplo simples que funciona, e outro mais complexo que não funciona, mas 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 requer o uso de um serviço PAAS por meio de um ponto de extremidade privado. Uma zona DNS privada vinculada à rede virtual tem um registro A que resolve o FQDN do serviço para o endereço IP privado do ponto de extremidade privado. O diagrama a seguir ilustra o fluxo.

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

Baixe um Arquivo Visio dessa arquitetura.

O cliente emite uma solicitação para stgworkload00.blob.core.windows.net.
O DNS do Azure, o servidor DNS configurado para a rede virtual, é consultado para o endereço IP de 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    
```
A zona DNS privada privatelink.blob.core.windows.net está vinculada à Rede Virtual de Carga de Trabalho, portanto, o DNS do Azure incorpora registros da Rede Virtual 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.net, para o IP privado do ponto de extremidade privado, o endereço IP privado 10.1.2.4 é retornado.

A execução do 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, neste caso, é 10.1.2.4.
A solicitação é roteada por meio de Link Privado para a conta de armazenamento.

O design funciona porque 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 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 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.

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

Baixe um Arquivo 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 ao 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 ao 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 comando a seguir 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á fazendo proxy de consultas DNS, podemos registrá-las. Veja a seguir exemplos de logs do 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    
```
O cliente não recebe o endereço IP privado para o ponto de extremidade de Link Privado e não pode estabelecer uma conexão privada com a conta de armazenamento.

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

Cenários

Embora as soluções para esse problema sejam semelhantes, percorrer cenários comuns de carga de trabalho mostra como as soluções atendem aos requisitos de várias situações. 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 de forma simples, com um cliente que acessa um único serviço PaaS regional. Eles ficam cada vez mais complexos, adicionando 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 um substituto para qualquer recurso do Azure que tenha uma NIC exposta em uma rede virtual, como Conjuntos de Dimensionamento de Máquina Virtual, nós do Serviço de Kubernetes do Azure ou qualquer outro serviço que roteie de maneira semelhante.

Importante

A implementação de Link Privado para a conta de Armazenamento do Azure pode diferir de outros serviços de PaaS de maneiras sutis, mas se alinha bem para muitos. Por exemplo, alguns serviços removem registros FQDN enquanto expostos por meio de Link Privado, 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 ir da topologia de rede inicial ao estado final desejado. A solução para cada cenário aproveita o padrão de extensões de hub virtual. Esse padrão aborda como expor serviços compartilhados de maneira isolada e segura, como uma extensão conceitual para um hub regional. 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 PaaS dedicado.

Próximas etapas

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

Guia para Links Privados e DNS na WAN Virtual do Azure