O Azure Arc facilita o gerenciamento em ambientes híbridos e multi-cloud por meio de um único painel. Com o Azure Arc, é possivel aplicar os recursos de gerenciamento e segurança do Azure aos seus recursos de outras nuvens, e on-premises, como servidores, clusters Kubernetes e serviços de dados.
Gerenciar recursos do Azure Arc em diferentes redes e firewalls pode apresentar alguns desafios como por exemplo precisar expor pontos de extremidade públicos para seus recursos, o que pode aumentar o risco de acesso não autorizado e ataques maliciosos.
Desta forma, o Azure Arc Private Links é uma solução que facilita e segura a conexão entre seus recursos do Azure Arc e o Azure. Com o Azure Arc Private Links, é possiível criar pontos de extremidade privados para seus recursos do Azure Arc dentro de uma rede virtual do Azure e acessá-los usando endereços IP privados e assim evitar expor pontos de extremidade públicos e proteger seus recursos de riscos de rede. Você também pode diminuir a latência e os custos de largura de banda da rede, direcionando o tráfego pela rede principal do Azure.
Ao utilizar extensões de VM que funcionam com os servidores no Azure Arc, como por exemolo : Gerenciamento de Atualizações, Automação do Azure ou o Azure Monitor, esses recursos se conectam a outros recursos do Azure, como o Workspace do Log Analytics, Conta de Automação do Azure, Cofre de Chave do Azure e o Armazenamento de Blobs que também devem ter seus próprios links privados.
No entanto, até o momento deste artigo, existem algumas restrições em que o tráfego ainda precisa ser realizadas para URLS públicas, como por exemplo, para acesso ao Entra ID, Azure Resource Manager, Windows Admin Center e SSH. A figura abaixo apresenta este fluxo de conexão.
Objetivo
O propósito deste artigo é demostrar em um ambiente de laboratório como configurar o Azure ARC com private link e ajustar o agente do azure arc para acessar as urls públicas por meio de um proxy.
O ambiente de laborátorio consiste em:
On-premises
- Servidor Active Directory - Domain Controller (ADDS) : 10.168.101.4
- Servidor (para onboard no arc) com Windows Sever 2022 : VM01
- Proxy Server ( Pfsense/squid) : 192.168.101.1
- VPN Site to Site
Azure
- Vnet Hub com :
- Servidor Active Directory - Domain Controller (ADDS) : 10.10.0.4
- VPN Gateway
Arquitetura do ambiente de laboratório.
Criando o ARC Private Scope
No portal do Azure , pesquise por Azure ARC e selecione “Private link scopes” e depois em “Create”
Insira a subscription , resource goup , região e o nome para o Private link Scope.
Selecione “Create” para criar o Private Endpoint e complete as informações a direita. Utilizarei uma já existente chamada “Vnet-Arc” e Mantenha habilitada a opção de DNS Integration
Valide as informações e depois vai em : “create”.
Valide os recursos criados no RG.
Realizando Link do Private DNS Zone.
Ao acessar a zona de DNS privada que foi criada, é possível ver que o link com a Vnet-Arc já foi feito automaticamente. Como meu servidor de DNS (Controlador de Domínio) está em uma vnet diferente, eu também preciso criar o link com ela.
Integração DNS do Private Endpoint
Para integração de dns com private endpoint existem vários modelos : Azure Private Endpoint DNS integration | Microsoft Learn
No meu caso utilizarei o modelo de integração com custom DNS, pois já tenho um Domain Controller no Azure. Assim, vou usar encaminhadores condicionais, conforme descrito em: https://github.com/dmauser/PrivateLink/tree/master/DNS-Integration-Scenarios#42-custom-dns-server.
Para isso irei configurar encaminhadores no meu DC on-premises e também no Azure.
DNS do Domain Controller on-premises.
No meu Domain Controller on-premises estarei criando o Encaminhador Condicional : his.arc.azure.com e guestconfiguration.azure.com apontando para meu Domain Controller no Azure (10.10.0.4).
DNS do Domain Controller no Azure
No servidor Domain Controller do Azure eu crios os mesmos Contional Forwarders his.arc.azure.com e guestconfiguration.azure.com , porém apontando para o Ip do Azure DNS (168.63.129.16) .
Validando a Resolução de nomes.
Vou testar com nslookup a resolução dos endereços gbl.his.arc.azure.com e gbl.privatelink.his.arc.azure.com, o resultado esperado é o ip 10.13.0.10 conforme abaixo.
A partir do servidor on-premises, o resultado é conforme esperado.
Conectando no ARC
Para fazer o onboarding no ARC vou gerar um o Script de Configuração.
Pesquisar por ARC , na coluna selecione “Machines” , depois em add/create .
Para este lab criarei o script para somente um servidor.
Selecione o Método de conectividade como Private Endpoint e selecione o Link Scope criado anteriormente e “Download and run”
Será apresentado o script para copiar ou fazer o download.
Instalação do Agente no Servidor on-premises.
Conforme Documentação oficial mesmo com private link algumas URLS, públicas ainda precisam ser liberadas.
Após a liberação das URLs no servidor proxy realizei a configuração de proxy settings na máquina onde irei rodar o script, inclusive inserindo as urls do private endpoint para o não uso de proxy.
Porém ao executar o script de onboarding recebi o erro: “The remote server returned an error: (504) Gateway Timeout”
Devido este cenário de "rede dividida", em que algumas URLs, como por exemplo de autenticação no Entra ID, devem ir pela internet via proxy, mas o tráfego para os endpoints privados do ARC não. É necessário configurar o agente do ARC para os serviços que devem usar o proxy.
Para isto pode-se configurar dois parâmetros :
- config set proxy.url : Endereço do Proxy.
- config set proxy.bypass : Valor conforme tabela abaixo da URls privadas
Desta forma, vou fazer a instalação do agente de forma manual direto pelo link https://aka.ms/AzureConnectedMachineAgent , (em um ambiente Entreprise poderia ser via SCCM, Gpo ,Intune, etc.)
Ao realizar um check de conectividade com o comando :
*Altere o parâmetro “location” conforme foi região onde foi criado o private link. No meu caso é EastUS
azcmagent check --location "eastus" --enable-pls-check
É possível observar no resultado que os endpoints privados estão sendo alcançados, porém os públicos não.
No script de onboarding gerado anteriormente vou comentar as linhas que fazem a instalação do agente ( já instalado) e adicionar as linhas a seguir com os parâmetros para o proxy.
& “$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" config set proxy.url "http://192.168.101.1:3128"
& "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" config set proxy.bypass "Arc"
Ao executar novamente o script recebo o prompt para login e insiro as credenciais.
Realizando a verificação de conectividade novamente pelo comando :
azcmagent check --location "eastus" --enable-pls-check
É possível observar que agora todos os endpoints estão alcançáveis. E os endereços públicos estão com o proxy configurado ( set) e realizando o bypass para o endereços privados.
Ao acessar o portal do azure é possível que a máquina está com o status de conectada no ARC.
Referências
- Managing the Azure Connected Machine agent - Azure Arc | Microsoft Learn
- What is IP address 168.63.129.16? | Microsoft Learn
- https://learn.microsoft.com/en-us/azure/azure-arc/network-requirements-consolidated?tabs=azure-cloud#urls
- https://github.com/dmauser/PrivateLink/tree/master/DNS-Integration-Scenarios#42-custom-dns-server
- Use Azure Private Link to securely connect servers to Azure Arc - Azure Arc | Microsoft Learn
Microsoft
