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 Link Privado do Azure possibilita que os clientes acessem os serviços de PaaS (plataforma como serviço) 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 maneira privada ao serviço.

Os clientes continuam usando o FQDN (nome de domínio totalmente qualificado) de um serviço para se conectar a ele. Você configura 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, principalmente, sua configuração de DNS, são fatores-chave no suporte à conectividade do ponto de extremidade privado com os serviços. Este artigo faz parte de uma série de artigos que fornecem diretrizes 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 designs 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 hub-spoke típica que usa a WAN Virtual do Azure.

Figura 1: Topologia de rede inicial 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 seguro do Firewall do Azure regional.
Cada hub virtual regional seguro 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 através do firewall do hub regional.
Cada hub virtual regional é protegido com o Firewall do Azure. Os firewalls de hub regionais 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: 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 workspace 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 de FQDN pode estar fora de sincronia.

Roteamento de várias regiões

Os hubs de WAN Virtual seguros têm suporte limitado para conectividade entre hubs quando há vários hubs virtuais seguros. 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 por meio 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 é de que o tráfego interno seguro não percorra vários hubs. O tráfego que deve percorrer 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.

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 da 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 se compartilha serviços de rede comuns, como registros DNS, no hub autogerenciado. Normalmente, você vincula a zona DNS privada à rede 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 reconhece as zonas privadas. Especificamente, esse é um problema para o Firewall do Azure, o provedor DNS configurado para spokes 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 spoke onde as cargas de trabalho esperam resolução DNS. No entanto, como observado na arquitetura, o proxy DNS está habilitado nos firewalls regionais e é esperado que todos os spokes usem seu firewall regional como fonte DNS. O DNS do Azure é chamado a partir do firewall,e não da rede da carga de trabalho, portanto, nenhum link de zona DNS privada na rede de carga de trabalho é usado na resolução.

Observação

Para configurar o firewall regional para ser o provedor DNS do spoke, defina o servidor DNS personalizado na rede virtual spoke para apontar para o IP privado do firewall, e não para o 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 controlam. Esse recurso requer que o proxy DNS esteja habilitado. Um uso comum é limitar o tráfego NT a pontos de extremidade conhecidos, como time.windows.com.
As equipes de segurança podem se beneficiar do registro de solicitações 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 o provedor 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 sua falha é instrutiva.

Cenário funcional

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 stgworkload00.blob.core.windows.net.

A execução do comando a seguir na 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 associa o FQDN stgworkload00.privatelink.blob.core.windows.net, ao IP privado do ponto de extremidade privado, o endereço IP privado 10.1.2.4 é exibido.

A execução do comando a seguir 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)
```
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.
Reconhece a zona DNS privada vinculada.
Resolve consultas DNS usando os valores da zona.

Cenário não funcional

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 da WAN Virtual. Portanto, quando os clientes são configurados para usar o firewall como o 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 na 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 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 da WAN Virtual.
2. O DNS do Azure não reconhece uma zona DNS privada vinculada à rede virtual de carga de trabalho, pois 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 na 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á atuando como proxy das 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. Esse é o problema abordado pelos cenários.

Cenários

Embora as soluções para esse problema sejam semelhantes, analisar 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 por um ponto de extremidade privado. Eles adotam a 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 de PaaS regional. Eles vão ficando 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 de 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á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 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 a 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

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

Compartilhar via

Guia para Links Privados e DNS na WAN Virtual do Azure