Aqui vamos abordar alguns conceitos que não foram abordados na primeira parte do artigo mas são importantes durante o desenvolvimento da seção de hands on:
IP Público;
IP Privado;
Rede hub-spoke.
IP Privado
Os IPs privados permitem a comunicação entre os recursos no Azure como interfaces de rede, balanceadores de carga, gateways de aplicativos, etc. sem o uso de um endereço de IP público.
O Azure atribui endereços IP privados aos seus recursos do intervalo de endereços da sub-rede da rede virtual na qual se encontra o recurso.
O Azure reserva os quatro primeiros endereços de cada intervalo de endereços da sub-rede. Os endereços não podem ser atribuídos aos recursos. Por exemplo, se o intervalo de endereços da sub-rede for 10.0.0.0/16, os endereços 10.0.0.0-10.0.0.3 e 10.0.255.255 não estarão disponíveis. Endereços IP no intervalo de endereços da sub-rede só podem ser atribuídos a um recurso por vez.
Há dois métodos para fornecer um endereço IP privado: alocação dinâmica e alocação estática.
Na alocação dinâmica o Azure atribui o próximo endereço IP disponível não atribuído ou não reservado no intervalo de endereços da sub-rede. Embora esse seja normalmente o próximo endereço sequencialmente disponível, não há garantia de que o endereço será o próximo no intervalo (por exemplo, se os endereços 10.0.0.4-10.0.0.9 já estiverem atribuídos a outros recursos, o próximo endereço IP atribuído provavelmente será 10.0.0.10, mas poderá ser qualquer endereço entre 10.0.0.10 e 10.0.0.254) Se um endereço IP privado específico for necessário para um recurso, você deverá usar um endereço IP privado estático.
Ainda, na alocação dinâmica, dinâmico é o método de alocação padrão. IPs dinâmicos serão liberados se uma interface de rede for:
Excluída;
Reatribuída a uma sub-rede diferente dentro da mesma rede virtual;
Se o método de alocação for alterado para estático e um endereço IP diferente for especificado.
Por padrão, o Azure atribui o endereço anterior atribuído dinamicamente como o endereço estático quando você altera o método de alocação de dinâmico.
Na alocação estática, você seleciona e atribui qualquer endereço IP não atribuído ou não reservado no intervalo de endereços da sub-rede. Por exemplo, se o intervalo de endereços de uma sub-rede for 10.0.0.0/16 e os endereços 10.0.0.4-10.0.0.9 forem atribuídos a outros recursos é possível atribuir qualquer endereço entre 10.0.0.1 e 10.0.255.254. Os endereços estáticos só são liberados se um adaptador de rede é excluído.
O Azure também atribui o IP estático quando o método de alocação é alterado. Uma nova atribuição de IP ocorre mesmo que o endereço não seja o próximo disponível na sub-rede. O endereço muda quando a interface de rede é atribuída a uma sub-rede diferente.
No contexto das máquinas virtuais, um ou mais endereços IP privados são atribuídos a um ou mais adaptadores de rede, sendo possível especificar o método de alocação como dinâmico ou estático para um endereço IP privado.
Como os demais recursos, os limites sobre o endereçamento IP são encontrados no conjunto completo de limites de rede no Azure e os limites são por região e por assinatura.
IP Público
Um prefixo de endereço IP público é um intervalo estático e reservado de endereços IP públicos. Esse endereço IP é exclusivo para cada região; ao definir um prefixo de endereço IP público, os endereços IP públicos associados são atribuídos de um pool para uma região do Azure.
Em uma região com Zonas de Disponibilidade, os prefixos de endereço IP público podem ser criados com redundância de zona ou ser associados a uma zona de disponibilidade específica.
Os seguintes tamanhos de prefixo IP público estão disponíveis:
/28 (IPv4) ou /124 (IPv6) = 16 endereços;
/29 (IPv4) ou /125 (IPv6) = 8 endereços;
/30 (IPv4) ou /126 (IPv6) = 4 endereços;
/31 (IPv4) ou /127 (IPv6) = 2 endereços.
Um endereço IP público é um recurso configurável; ao atribuir um endereço IP público a um recurso do Azure, as seguintes operações são habilitadas:
A comunicação de entrada da Internet com o recurso, como VMs, Gateways de Aplicativo, Balanceadores de Carga, Gateways de VPN do Azure entre outros;
Conectividade de saída à Internet usando um endereço IP previsível.
O Azure fornece um IP de acesso de saída padrão para VMs que não receberam um endereço IP público ou que estão no pool de back-end de um balanceador de carga do Azure básico interno. O mecanismo de IP de acesso de saída padrão fornece um endereço IP de saída que não é configurável.
O IP de acesso de saída padrão é desabilitado quando um dos seguintes eventos acontece:
Um endereço IP público é atribuído à VM;
A VM é colocada no pool de back-end de um balanceador de carga padrão, com ou sem regras de saída;
Um recurso da Gateway da NAT do Azure é atribuído à sub-rede da VM.
As VMs criadas por conjuntos de dimensionamento de máquinas virtuais no modo de orquestração flexível não têm acesso de saída padrão.
Ainda sobre VMs, os endereços IP públicos estão disponíveis em dois SKUs: padrão e básico. A seleção do SKU determina os recursos do endereço IP. Nesse sentido, a alteração de um endereço IP público deve ser feita sempre via Portal do Azure para evitar problemas de conectividade.
A rede hub-spoke no Azure é uma topologia de rede que ajuda a gerenciar eficientemente os requisitos comuns de comunicação ou segurança. A figura abaixo fornece um exemplo de uma topologia de rede hub and spoke:
Exemplo de uma arquitetura destacando os componentes hub and spoke (referência: Microsoft)
Os componentes principais dessa arquitetura são:
Rede virtual hub: É a rede central que hospeda serviços compartilhados. As cargas de trabalho hospedadas nas redes virtuais spoke podem usar esses serviços. A rede virtual de hub é o ponto central de conectividade para redes entre locais;
Redes virtuais spoke: As redes virtuais spoke isolam e gerenciam cargas de trabalho separadamente em cada raio. Cada carga de trabalho pode incluir várias camadas, com várias sub-redes conectadas por meio de balanceadores de carga do Azure.
Conectividade da rede virtual: Essa arquitetura conecta redes virtuais usando conexões de emparelhamento (peering) ou grupos conectados. Conexões de emparelhamento e grupos conectados são conexões não transitivas e de baixa latência entre redes virtuais.
Frequentemente, o hub contém os componentes de serviço comuns consumidos pelos spokes. Exemplos de serviços centrais comuns são:
Um serviço DNS resolve a nomenclatura da carga de trabalho nos spokes, a fim de acessar recursos locais e na Internet, se o DNS do Azure não for usado;
Uma infraestrutura de chave pública implementa o logon único para cargas de trabalho;
O fluxo de tráfego TCP e UDP é controlado entre as zonas da rede de spoke e a Internet;
Controle de fluxo entre os spokes e o local;
O fluxo é controlado entre um spoke e outro, se necessário.
É possível minimizar a redundância, simplificar o gerenciamento e reduzir o custo geral usando a infraestrutura de hub compartilhado para dar suporte a vários spokes.
A função de cada spoke pode ser a de hospedar diferentes tipos de cargas de trabalho. Eles também fornecem uma abordagem modular para implantações repetíveis das mesmas cargas de trabalho como por exemplo separar ambientes desenvolvimento/teste, teste de aceitação do usuário, homologação e produção, entre outros.
Os spokes também podem separar e habilitar diferentes grupos na sua organização. Um exemplo são os grupos Azure DevOps. Um spoke é possível implantar uma carga de trabalho básica ou cargas de trabalho complexas de várias camadas com controle de tráfego entre as camadas.
O Gateway de Aplicativo mostrado no diagrama acima pode viver no spoke com o aplicativo que está servindo para melhor gerenciamento e escala. No entanto, a política corporativa pode ditar que você coloque o Gateway de Aplicativo no Hub para gerenciamento centralizado e diferenciação de imposto.
Hands on: Configurando uma rede HUB-SPOKE
1. A proposta
Nosso hands on foi baseado na aula Configurando Redes hub-spoke no Azure disponível no canal do Raphael (abaixo):
Se você ainda não recebe as notificações do canal, corre lá e se inscreva agora para não ficar de fora dos conteúdos gratuitos semanais e eventos da TFTEC Cloud: Raphael Andrade – YouTube
As referências utilizadas estão disponíveis na última seção do artigo.
Nesse laboratório estaremos utilizando uma assinatura do tipo student (com algumas limitações maiores que uma conta trial). Na forma como ele é apresentado no artigo ele pode ser utilizado com esse tipo de assinatura ou com uma assinatura do tipo trial (para saber como criar sua conta gratuita no Azure acesse nosso artigo: https://www.tftec.com.br/2024/04/15/criando-uma-conta-gratuita-no-azure/. ).
Para execução de qualquer laboratório, sempre sugerimos:
Verificar as quotas e créditos da assinatura que será utilizada;
Verificar quais recursos estão alocados na assinatura;
Programar o desligamento automático de recurso como máquinas virtuais;
Ao término do laboratório, deletar todos os recursos utilizados.
A cota de vCPUs é um dos limites que devemos ficar atentos. No laboratório descrito no artigo conseguimos fazer a execução a partir de uma assinatura com cotas inferiores ao descrito no video (figura abaixo):
Fique à vontade para utilizar o tipo de assinatura que desejar.
2. Criação e configuração do grupo de recursos (RG) e redes virtuais (VNets)
A nossa abordagem será desenvolvida em sua maioria utilizando o Portal Azure.
2.1 O primeiro passo é criarmos nosso RG:
1. Dentro do Portal Azure, caso não apareça Grupo de recursos (RG), busque na barra de Pesquisar recursos:
2. O grupo de recursos deve ser configurado conforme o vídeo do Raphael. Após o nome e região, avançamos para as tags (marcações):
3. Utilizamos as tags conforme o vídeo e ao final clicamos em Avançar para validarmos e executarmos o provisionamento e concluirmos a criação do nosso rg-live:
2.2 Criação das VNets
Agora partimos para criação das redes virtuais (VNET) acessando o ícone do recurso ou pela barra de pesquisa:
2.2.1 Vnet-hub
A primeira rede a ser criada é a nossa vnet-hub:
1. Na aba básico temos a seguinte configuração:
2. Na parte de segurança deixaremos o default que se apresenta:
3. E para os IPs, conforme indicado no vídeo, fazemos:
4. Editando a sub-rede (sem esquecer de clicar em salvar após inserir os endereços):
5. Após clicar em Próximo, colocamos as mesmas tags, revisamos e executamos o provisionamento:
6. Após a implantação bem sucedida do recurso, voltamos para criação de redes virtuais para prosseguirmos com a criação da vnet-spoke01. Os passos são exatamente os mesmos.
2.2.2. VNet spoke número 1
Seguindo a arquitetura do video, mantemos no mesmo RG, rg-live:
2. Deixando o default na aba Segurança, configuramos os endereços de IP:
3. Editando a sub-rede da mesma forma que anteriormente:
5. Prosseguimos para as tags e depois da validação, a implantação do recurso:
2.2.3 VNet spoke número 2
Agora seguimos para criação da terceira e última Vnet, a vnet-spoke 02:
2. Prosseguindo com os mesmos passos: configuração dos endereços de rede e sub-rede:
3. Após salvar, prosseguimos apra as demais abas:
Aba Marcas(TAG): o mesmo par das duas anteriores; ENV-LIVE;
Aba Segurança: opções de dafault;
Aba Revisar + Criar: após a validação, executamos a criação.
Ao final da criação das três redes devemos chegar no seguinte resultado:
Para a criação de VMs via Portal podemos partir sempre da seguinte forma:
2.3.1 VM Windows número 1 (HUB)
Na criação dessa VM vamos utilizar uma imagem de Windows Server 2022:
2. Nome da VM será vm-hub 01 (HUB da arquitetura).
3.Atenção especial aqui para nome de usuário e senha (abaixo sugestões para laborátório):
nome de usuário: admin.rapha
senha:Tftecprime@2024
E não esquecendo de marcar a opção de exclusão de IP e NIC quando a VM for excluída:
4. Na aba Discos, utilizamos as configurações mínimas por conta dos custos:
5. Sendo a VM do HUB, devemos utilizar sua respectiva rede conforme configurado abaixo:
Em Grupo de segurança de rede do adaptador de rede, devemos escolher Básico já que não foi configurado o NSG separadamente/manualmente.
6. No Gerenciamento sugerimos desmarcar algumas opções caso venham marcadas (para não consumir recursos que não são nosso foco de estudo nesse momento) e habilitar somente o desligamento automático da VM:
7. Monitoramento e Avançado podemos deixar as opções default.
8. Após inserir as tags, prosseguimos para validação e executamos a criação do recurso:
Com a criação bem sucedida podemos ir para próxima VM:
2.3.2 VM número 1 – SPOKE
As etapas são as mesmas das descritas anteriormente. Aqui vamos trabalhar novamente com um SO Windows.
Nosso SO será novamente o Windows Server 2022:
2. Nossa sugestão é utilizar as mesmas credenciais (senha e usuário) da VM anterior:
3. Em Rede utilizamos a rede respectiva para SPOKE:
4. Para Gerenciamento, Monitoramento, Avançado e Marcas mantemos o que foi estabelecido para a VM anterior. Ao final, realizamos a validação e procedemos com a implantação:
Com a VM provisionada com sucesso podemos seguir para nossa última VM utilizando o botão Criar outra VM:
2.3.3 VM número 2 para SPOKE
O diferencial aqui é a utilização de um SO Linux. As demais etapas seguem como foi feito para a criação das VMs anteriores:
1.Escolhemos o SO Ubuntu Server para a vm-spoke02:
2. Em virtude da cota limite de vCPUs foi necessário fazer um ajuste para 1 vCPU:
3. Após a adequação da cota de vCPUs, definimos usuário e senha. O nome de usuário não aceita ponto final então utilizamos conforme indicado abaixo:
4. Agora configuramos a rede com a vnet-spoke02:
E o detalhe da porta:
E prosseguimos para a aba Discos.
5. Dentro das limitações de configuração compatíveis com o processador escolhido, definimos a seguinte configuração de Disco:
6. Prosseguimos com as configurações default para Monitoramento e Avançado.
7. Após adicionar as tags criamos a nossa VM:
2.4 Visualização dos recursos criados e rotas
2.4.1 Visualizador de recursos
O Visualizador de Recursos é uma boa ferramenta para verificarmos a nossa arquitetura:
1. Seleciona-se o RG:
2. Em seguida acessamos o menu Visualizador de Recursos:
3. Dessa forma conseguimos ter uma visão razoável dos recursos:
2.4.2. Rotas
Para facilitar o entendimento, podemos ilustrar o conceito da rede Hub-Spoke no diagrama abaixo:
Nessa arquitetura a VM hub centraliza a comunicação organizando a conectividade e evitando a criação de conexões paralelas (representado pelo ponto de interrogação vermelho sobre a linha pontilhada).
Aqui não testaremos a ausência de conectividade entre hub e spoke via comando ping como demonstrado no vídeo. Vamos acessar os registros de rota via Portal Azure:
Para a vm-hub01, acessamos os registros a partir daConfigurações de Rede, clicando no Adaptador de Rede:
2. E finalmente acessando os registros no menu Obter Rotas:
Percorrendo os registros, como foi demonstrado no vídeo e na figura acima, não conseguimos encontrar a rota que faça a conexão spoke-spoke (ilustrada no diagrama com o ponto de exclamação) nem a hub-spoke.
Isso se dá pleo fato de ainda não ter sido configurado o emparelhamento/peering.
2.5 Configurando o peering
Para a configuração do Emparelhamento/Peering, devemos:
No Portal, acessamos Redes virtuais:
2. Em seguida econtramos a vnet-hub acessamos o menu Emparelhamentos:
3. Configuramos o nome, do HUB para o spoke e adicionamos:
No detalhe a relação entre hub-spoke:
4. Após clicar em adicionar conseguimos observar o status:
5. E agora, após conecatarmos nossas VMs (via RDP ou SSH) testamos a conexão entre a vm-spoke01 (spoke) e vm-hub (hub):
Ou seja, a comunicação entre os IPs privados está estabelecida como foi proposto!
6. Quando, a vm-spoke02 tenta conectar diretamente a vm-spoke01, a conexão não ocorre. No entanto, quando a vm-spoke02 faz o teste de ping com a vm-hub, a comunicação ocorre:
7. Podemos confirmar o teste consultando a Tabela de Rotas:
Verificamos o registro adicionado após a configuração do peering.
Considerações finais
Essa topologia é amplamente utilizada em soluções empresariais no Azure e é uma das melhores práticas para implementação de cenários de redes em cloud. Ela permite a centralização de recursos, como firewalls ou serviços compartilhados, e proporciona ao departamento de TI uma maneira eficiente de impor políticas de segurança em uma localização central.
