Guest LeandroBarbosa Posted June 25 Posted June 25 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 ir 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: PrivateLink/DNS-Integration-Scenarios at master · dmauser/PrivateLink. Para isso irei configurar encaminhadores no meu DC on-premisses e também no Azure. DNS do Domain Controller on-premises. No meu Domain Controller on-premises estarei criando o Encaminahdor 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. Azure Arc network requirements - Azure Arc 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 a autenticação para o Entra ID, devem ir pela internet via proxy, mas o tráfego para os endpoints privados do ARC não, será preciso definir para o agente do ARC os serviços que devem usar o proxy e os que devem ignorá-lo. Para isto pode-se configurador 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 [iCODE]azcmagent check --location "eastus" --enable-pls-check [/iCODE] É 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 logim e insiro as credenciais. Realizando a verificação de conectividade novamente pelo comando : [iCODE]azcmagent check --location "eastus" --enable-pls-check [/iCODE] É 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 Azure Arc network requirements - Azure Arc PrivateLink/DNS-Integration-Scenarios at master · dmauser/PrivateLink Use Azure Private Link to securely connect servers to Azure Arc - Azure Arc | Microsoft Learn Continue reading... Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.